Welcome to William's ekasi

I presented two sessions at TechEd Africa this year:

1. Hack-Proofing your Microsoft ASP.NET Web Forms and MVC Applications
2. What code-database Gap? Introducing Project Juneau

You can download the slide-decks and code samples for each of the sessions bellow.

Hack-Proofing

Slide Deck

Code Samples

Additional Info:

• I cover SQL Injection in more detail in a post here.
• CSRF is covered in more details here.

Juneau

Slide Deck

Sample Database

Feel free to download and use as you wish!

ASP.Net MVC includes a Html helper method called AntiForgeryToken.

The AntiForgeryToken is intended to prevent cross site request forgery (CSRF – pronounced Sea-Surf) attacks.  CSRF attacks rely on the fact that the user’s credentials are stored in cookies and are still valid.

While the user’s credentials are still valid at site X, the CSRF attacker will trick the browser to performing actions at site X while the user is browsing a different site.

Example:

William is logged into CodePlex.  The authentication cookie for CodePlex is kept for a really long time and whenever the browser performs requests for CodePlex, the cookie is sent down to the site and CodePlex trusts that William is trying to do something on the forums.

So now our requirements are met:

1. The authentication token is stored in the browser’s cookie
2. The authentication token is still valid

So how did William get exploited?  Well, it didn’t happen on CodePlex.  William also frequents another forum: The Justin Bieber fanclub forum.  One of the threads William was visiting had a lot of <img /> tags in it.  The source of these tags weren’t all images though.  One of the tags looked like this:

And this is where it happened.

The browser saw a request to CodePlex and passed Williams credentials along to CodePlex.  CodePlex said “Ah, you’re William.  He’s cool, we trust him.  Let’s delete everything from OpenPOS like he asked”.

And without even knowing it, William had deleted OpenPOS from CodePlex.

Note: Yes, I know there is no “DeleteEverything” on CodePlex projects.

Prevention:

Preventing this type of attack is incredibly simple in ASP.Net MVC.  There’s a Html helper method called “AntiForgeryToken()” which generates a token.

The Action method on Controller is then decorated with the ValidateAntiForgeryToken attribute.

And that’s it. We’re secured.  But how does this work?

The token that is generated is stored in a hidden form element which is sent down to the browser as part of the markup (similar to the ViewState).  Then, the token is encrypted and that encrypted value is stored in a cookie sent to the user.

With this set up, each time the form is submitted the cookies value and the hidden form elements values are compared.  If they don’t match, we can assume the request isn’t coming from a valid source and we get a nice error page.

Should this type of error be handled gracefully by your application? I don’t think so. This type of error would result from the values not matching which can either only come from a CSRF attack or the server’s machine key changing during an IIS reset (you do have a machine key defined in your web.config, don’t you?).