Whitepaper Review - Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC

As part of a security team that cares deeply about the well being of Windows Live, I was extremely pleased to review a paper written by web application security specialists for whom I have deep respect.
Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC was written by a powerhouse team whose talent speaks for itself, including Casaba's Chris Weber; his Watcher was discussed in November's toolsmith.

First, I am an unabashed SDL fanboy. Any work that accentuates SDL principles is off to a great start in my book: security by default being paramount.
Second, of this paper's three subtopics (CSRF, open redirects, JSON hijacking), two (CSRF, open redirects) consistently count as pet peeves for me.
As for JSON hijacking, the best explanation available is also offered by one of the paper's authors, Phil Haack: JSON Hijacking.

"ASP.NET MVC provides a new Model-View-Controller framework on top of the existing ASP.NET 3.5 runtime. This framework enables developers to easily take advantage of the MVC architectural pattern to build Web applications."

When Windows Live moved to ASP.Net MVC it presented the opportunity to build mitigations into the framework that prevent developers from making accidental errors that could result in security flaws. Specifically, they targeted the three above mentioned web application security flaws – CSRF, open redirects, and JSON hijacking.

Highlights (thanks to Deepak Manohar):
CSRF is mitigated via ASP.Net MVC in that, by default, all HTTP requests are checked for a canary except for HTTP GET requests, or requests that developers specifically request not to be checked (keep an eye on those developers :-)).
"To defend a Web site against XSRF attacks, ASP.NET MVC provides AntiForgeryToken helpers. These consist of a ValidateAntiForgeryToken attribute, which the developer can attach to controller classes or methods, and the Html.AntiForgeryToken() method. The Windows Live team implemented a modified version of this approach."

To protect against open redirects, the Windows Live "could have added a new SafeRedirectResult class that checked the list of allowed Web sites and required all developers to use new class. However, a given developer might not know about this rule and might use the RedirectResult object manually. If this code was not caught by performing a code review and testing, it could result in a security bug. Thus, the team did not create a new class opting instead to change the behavior of the default class."

To protect against JSON hijacking, enter the WLXSecurityAttribute: "The WLXSecurity custom filter attribute is a class that implements the IActionFilter interface. This interface defines two methods called OnActionExecuting and OnActionExecuted. The OnActionExecuting method runs just before an action executes, and the OnActionExecuted method runs when the action has completed. OnActionExecuted is checked for an action result with a content type set to JSON or JavaScript; if matched, the result is checked to ensure that canary validation has been applied. The canary validation is typically included as part of the form post when using POST actions, but it can also be part of the query string."
Any action requiring canary checking where a canary is not provided with the request results in an exception: no data interchange for you!

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC is a recommended read, specifically for those of you managing developers or aiding them in securing their code.

Give it a read, and by all means feel free to provide feedback via comments.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)