February 23, 2011 - 22:41 UTC When building a ajax based application, you want to protect any POST request against CSRF attacks. If you are using jQuery, then jQuery provides a lot of convenience methods for ajax calls ($.get(), $.post(), $.getJSON() etc.) and it would be a shame if you would have to duplicate adding CSRF tokens to all your ajax calls manually or by going back to $.ajax(), because the convenience method didn't support the way you wanted to add the token. But jQuery, being the customizable framework it is, of course allows you to add these kinds of things through events.
[...]

April 5, 2010 - 12:02 UTC Unrestricted crossdomain.xml and clientaccesspolicy.xml files can be abused by malicious RIAs - or MalaRIAs - to perform actions on behalf of the user. For this PoC (proof of concept) I setup a malicious RIA to act as a proxy by comibining it with a server side application. This would allow the attacker to use the combined solution as a proxy and surf web sites with unrestricted cross domain policies through the victim's browser.

[...]

March 22, 2010 - 13:59 UTC

In an IdP/SP (Identity Provider/Service Provider) Single Sign-On scenario, you might also want to have Single Sign-Out, meaning you can log out of all SPs with a single click.

[...]

March 1, 2010 - 19:37 UTC To allow a Silverlight application to fetch data across domains, Silverlight employs a security policy in called clientaccesspolicy.xml. The policy allows a server admin to specify whether or not a Silverlight application running on a given domain is allowed to connect to the server to read data on behalf of the user. Unfortunately some people specify an unrestricted clientaccesspolicy.xml, which allows any server to make requests on behalf of the user, and thus allows a malicious Silverlight application to steal user data or perform actions on behalf of the user.
[...]

February 21, 2010 - 21:36 UTC Most web browsers implement the Same Origin Policy which limits how javascript etc. can interact across domains. Without this policy an attacker could setup a site, and if tricked into visiting it, the attacker could read data from all your logged in sessions (gmail, banking etc.) and perform actions against those sites on your behalf. This policy was seen as a bit to restrictive for flash/flex/silverlight which may need to read data from other domains. Adobe introduced the cross domain policy to address this concern. Unfortunately a lot of sites are not paying attention to what this policy really means.
[...]

May 29, 2007 - 22:13 UTC There are several ways to implement XSRF protection. In this implementation I'll use a combination of Viewstate and session to check the validity of a request.
[...]

May 12, 2007 - 15:47 UTC There has been a lot of writing about Cross-site request forgeries (XSRF/CSRF) lately. I've read numerous articles on how this could be used to capture home routers or create false online-banking transactions. In this post I'll discuss some techniques for protecting your website against XSRF.
[...]