After seeing the popularity of the AJAX methodology grow and new support technologies popping up left and right, I wondered what the implications on security were. We have discussed this at length at OWASP.org and everyone agrees... There are no new security threats posed by the implementation of AJAX other than possible bugs in the frameworks and implementing web browsers. However, solutions using AJAX are at great risk of falling prey to well known application vulnerabilities by failing to provide adequate security precautions around their exposed methods.
Let's say I own Eric-Bay.com and my users trade thousands of items an hour. Our team decides that AJAX is a worthy investment in our user's experience with our website. So, we begin to expose really cool AJAX utilities to our members first, but we release an acceptance test to 1,000 people. We're really smart, so we put these test participants into a security group called "AJAX Testers" and we make the visibility of our AJAX utilities dependant on users who are assigned to this security role and are authenticated. All good, right? WRONG!
Since AJAX exposes server-side methods directly from client-side code, we must also check the security role within the server method. If we were not careful, a user with access to the AJAX method could share the call with another user who might not have access (and possibly should not). If the user were technically adept, they could make the call manually and be granted access to the method. There are many ways to secure your methods. The quickest and most language-independant way of securing AJAX server-side methods is to perform a role check at the beginning of the method and throw an exception:
if (!User.IsInRole("MySecureMethodUsers"))
throw new Exception("You do not have access to this method.");
The following short tutorial assumes you are familiar with Atlas, an AJAX framework for ASP.NET applications. (However, there are ports for the client-side code to other languages as well.)
For my more advanced audience who already know Atlas and .NET code security, simply skip to step #11.
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="AtlasSecurityTest")]
public string HelloWorld(String query)
Amer Gerzic commented "Thanks for this tip! However, there is a little catch, which actually makes sense. It cost me an hour to realize that my forms authorization used option cookieless="UseUri". You have to remove this option from web.config file in order to make permissions work." Thanks for the your tip Amer!
Thanks for the info. It was exactly what I was looking for. Now I can proceed with Atlas development without worrying about security.