Posts Tagged ‘ASP.NET’

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

November 23rd, 2009 by Chris Weber

Casaba had the opportunity to contribute to a new Microsoft paper regarding ASP.NET MVC security. It's online through the SDL pages, and here's the paper's direct link. A short summary of the paper follows.

The SDL preaches 'secure by default'. When Windows Live moved to ASP.Net MVC, they used that opportunity to build mitigations into the framework that prevent developers from making accidental errors which result in security flaws. Specifically, they targeted these three security issues – XSRF, Open redirects and JSON hijacking.

For XSRF, the mitigation was that all HTTP requests are checked for a canary by default except for HTTP GET requests. Developers can also opt-out specific pages or functionality. This automatic ‘on-by-default’ canary checking prevents accidental errors which lead to XSRF.

For Open redirects, Windows Live added a wrapper around the Redirect result in ASP.Net MVC which checks a list of approved domains. This way when a developer called Redirect and forgot to ensure it was safe, the wrapper would cover them automatically.

For JSON hijacking, they ensure that the JSON result included a canary check by default. This prevented developers from being able to return JSON without a canary, thus preventing JSON hijacking.

Tags: ,
Posted in Code Review, Development | No Comments »

useUnsafeHeaderParsing = what?

June 5th, 2008 by Chris Weber

As software security people we usually like input restrictions to be tight. With .Net's HttpWebRequestElement.UseUnsafeHeaderParsing Property you can loosen up the way HTTP requests get parsed.

Setting this property ignores validation errors that occur during HTTP parsing. The documentation from MSDN makes it pretty clear. When this property is set to 'true' then many HTTP RFC violations will be relaxed and ignored.

When this property is set to false, the following validations are performed during HTTP parsing:

* In end-of-line code, use CRLF; using CR or LF alone is not allowed.
* Headers names should not have spaces in them.
* If multiple status lines exist, all additional status lines are treated as malformed header name/value pairs.
* The status line must have a status description, in addition to a status code.
* Header names cannot have non-ASCII chars in them. This validation is performed whether this property is set to true or false.

When a protocol violation occurs, a WebException exception is thrown with the status set to ServerProtocolViolation. If the UseUnsafeHeaderParsing property is set to true, validation errors are ignored.

Setting this property to true has security implications, so it should only be done if backward compatibility with a server is required.

Let's keep an eye out for this option when it's set either programmatically or through web.config.


<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing=”true” />
</settings>
</system.net>
</configuration>

Tags: ,
Posted in Code Review, Security Testing | No Comments »

Using ASP.Net session handling with secure sites (set the secure flag)

February 4th, 2008 by Samuel Bucholtz

One of the common problems we see with many web applications is reliance on ASP.Net sessionID without understanding the security ramifications. ASP.Net provides web developers with a powerful means of tracking user state and identity with very little coding. Rather than creating your own custom authentication cookie, handling the trickiness of forms auth or mapping your cookie to a Windows identity, password policy implementation, not to mention creating server objects to store the state for a given user, ASP.net does it all for you.

ASP.Net offers two methods of tracking session state- URL or cookie. URL based methods are used in cases where it is expected that some users will have disabled cookies and still need a server-side session to track state. This has become less common as more and more of the web relies on cookies. In addition the URLs look ugly and are considered unacceptableby many usability gurus.

The second method is a cookie sent as a header to the server. This cookie is sent over HTTP or HTTPS and is used by ASP.net to link an incoming request to the server-side state. So you are running your site on SSL, where is the problem? By default, the SessionID is just a cookie the browser sends it when making any response to the domain. If you go to https://yourapp/application, you will be sent a cookie over SSL that I cannot see. If I e-mail you a link to click for http://yourapp/application, I will see the cookie sent over HTTP as long as your server responds on port 80.

What you want to do is set the 'secure' flag on the cookie. You have many options for doing this: adsutil set w3svc/1/AspKeepSessionIDSecure 1 will tell ASP.net to mark the session cookie as Secure. When a cookie is marked as secure it will not be sent by the web browser unless the connection to the server is over https. You must be aware that the user will now have no session state if they browse to the site using http your application will need to redirect http requests to https in order to access the session state.

Is the ASP.Net session ID the only cookie I can protect in this way? No. You can use a web.config configuration to customize the security of all your cookies (http://msdn2.microsoft.com/en-us/library/ms228262.aspx). You will also be able to set cookies to be HttpOnly which adds its own element of security and is supported by newer browsers.

Finally, you can set both the secure flag and the HttpOnly flag for any other cookies you set programmatically through ASP.Net with http://msdn2.microsoft.com/en-us/library/ms228262.aspx.

A few other things to remember-

ASP.Net sessions expire after 20 minutes UNLESS a new request is seen. Otherwise they can remain until the server is recycled.

SessionIDs can be reused. When stored as a cookie the sessionID will go to any machine hosting the same parent domain. They will NOT have the server-side state though unless some clustering or back-end logic handles sharing state across servers. If you want to ensure that reuse does not happen, rather than using Session.Abandon you must overwrite the ASP.Net session cookie with an empty cookie value. To properly end a session or force a user to start a new one use Session.Abandon.

For more information checkout – http://msdn2.microsoft.com/en-us/library/ms972969.aspx

Tags: ,
Posted in Development, Security Testing | No Comments »

ViewStateUserKey to prevent XSRF (CSRF or cross-site request forgery) in ASP.NET

September 30th, 2006 by Chris Weber

ViewStateUserKey has been around for many years and is an easy solution to prevent the infamous XSRF or cross-site request forgery class of attack.

It’s documented:

http://msdn2.microsoft.com/en-us/library/system.web.ui.page.viewstateuserkey.aspx

ViewStateUserKey mitigates XSRF by including a unique identifier in the user’s request.

This protection mechanism has been available for many years when Microsoft identified the one-click attack, now more commonly referred to as XSRF.

Tags: ,
Posted in Development, Security Testing | No Comments »