Last week Microsoft published the 5th revision to the SDL. You can get it here: http://www.microsoft.com/security/sdl/default.aspx.
Of note, there are additions for .NET -- specifically ASP.NET and the MVC Framework.
Two key things I noticed initially were the addition of System.Web.UI.Page.ViewStateUserKey,
and ValidateAntiForgeryToken Attribute in MVC.
Both have existed for a while, but they are now added to requirements for final testing.
ViewStateUserKey is page-specific identifier for a user. Sort of a viewstate
session. It’s used to prevent forging of Form data from other pages, or in fancy
terms it prevents Cross-site Request Forgery attacks.
Imagine a web form that has a couple fields on it – sensitive fields, say money transfer
fields: account to, amount, transaction date, etc. You need to log in, fill
in the details, and click submit. That submit POST’s the data back to the server,
and the server processes it. The only validation that goes on is whether the
viewstate hasn’t been tampered with.
Okay, so now consider that you are still logged in to that site, and someone sends
you a link to a funny picture of a cat. Yay, kittehs! Anyway, on that
page is a simple set of hidden form tags with malicious data in it. Something
like their account number, and an obscene number for cash transfer. On page
logged in, the server accepts it. Sneaky.
The reason this worked is because the viewstate was never modified. It could
be the same viewstate across multiple sessions. Therefore, the way you fix this
to add a session identifier to the viewstate through the ViewStateUserKey. Be
forewarned, you need to do this in Page_Init, otherwise it’ll throw an exception.
The easiest way to accomplish this is:
void Page_Init (object sender, EventArgs e)
ViewStateUserKey = Session.SessionID;
Oddly simple. I wonder why this isn’t default in the newer versions of ASP.NET?
Next up is the ValidateAntiForgeryToken attribute.
In MVC, you add this attribute to all POST action methods. This attribute requires
all POST’ed forms have a token associated with each request. Each token is session
specific, so if it’s an old or other-session token, the POST will fail. So given
that, you need to add the token to the page. To do that you use the Html.AntiForgeryToken() helper
to add the token to the form.
It prevents the same type of attack as the ViewStateUserKey, albeit in a much simpler