Résumé
Twitter
Work Blog
Guestbook
Login

Securing Atlas Method Calls

Share |
<= Previous Post | Next Post =>

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.

A Short AJAX Vulnerability Example

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.");

Securing Atlas for ASP.NET

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.

  1. First, follow the Atlas walkthrough "Creating a Declarative Web Application with ASP.NET 'Atlas'". *I suggest using a new project and not an existing one for this example.
  2. Now, modify the file "Declarative.aspx" to contain some code with Forms Authentication controls by copying and pasting my example code.
  3. Next, run the ASP.NET Configuration tool on your website (menu: "Website->ASP.NET Configuration").
  4. Select the "Security" tab and choose "Select authentication type" and then select "From the internet".
  5. Now, return to the security home page and "Enable Roles"
  6. Click "Create or Manage roles" and create a new role called "AtlasSecurityTest".
  7. Return to the security home page and create a new user, checking the checkbox next to the new role "AtlasSecurityTest" and verify that the checkbox "Active User" is checked.
  8. Close the ASP.NET configuration web browser.
  9. Return to Visual Studio and edit the file "HelloWorldService.cs" (or whatever language extension you are using).
  10. Add the namespace "System.Security.Permissions" at the top of the file.
  11. Finally, add a permission attribute to the web service method "HelloWorld" as follows (in C#):
  12. [PrincipalPermissionAttribute(SecurityAction.Demand, Role="AtlasSecurityTest")]
    public string HelloWorld(String query)
  13. Close the web service file and open "Default.aspx"
  14. Save your project and run it (F5)
  15. When "Default.aspx" appears in a web browser, attempt to enter some text in "Search For" and click "Search"... Nothing should happen.
  16. Now, login using the user account you created earlier and perform another search. Voila! Instant, integrated method security for Atlas! Savor the sweetness of .NET code security.

Web.config settings that affect permissions

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!

Share |
<= Previous Post | Next Post =>

Comments

Submit New Comment

*Your e-mail is not shared with others. If provided, I simply use it as a method of contacting you about your comment(s) on this website. If you have a direct question, simply contact me.

*Cannot contain HTML and NO SPAM!

Thanks for the info. It was exactly what I was looking for. Now I can proceed with Atlas development without worrying about security.