on https://msdn.microsoft.com/en-us/magazine/gg490350.aspx

The rules are available on codeplex at https://fxcopaspnetsecurity.codeplex.com/

One of the new proposal I’ve stumble upon is the Strict Transport Security proposal which is being sponsored by Paypal and currently supported by the Google Chrome browser. The spec is still under review and the latest version is available at https://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html .

The proposal is quite simple and aims at forcing the browser to only connect over SSL by redirecting HTTP traffic to HTTPS at the browser level so that no connection is made over HTTP. This is implemented by adding a server component that provides the browser with a connection policy and by a browser component which enforce the policy provided by the server.

I’ve seen a lot of applications force connection over HTTPS by simply detecting the connection over HTTP and returning a 302 redirect to the client to the HTTPS site but this specification improves this logic by telling the browser to automatically replace the HTTP location on the client side so that no “unsafe” connections are made.

I believe that the Strict Transport Security proposal is a step in the right direction but I’m not sure about its acceptance. I also have some concerns about requiring the initially connection over HTTP and allowing the browser to connect back to HTTP once the policy expires. I believe that group policy might be a better approach there for certain high profile sites but only time will tell.

After reading the specification, I realize that implementing the server processing is quite simple under ASP.NET and decided to implement a quick STS HTTP Module for ASP.NET and make it available.

-          https://www.asp.net/(S(ywiyuluxr3qb2dfva1z5lgeg))/learn/whitepapers/request-validation/

-          https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6

Some of the questions I’ve been asked repeatedly are:

1.      How to detect when this is occurring and?

When ASP.NET detects that XSS is occurring it throws an HttpRequestValidationException which can be caught in the Application_Error handler.

void Application_Error(object sender, EventArgs e)

{

    // Code that runs when an unhandled error occurs

    Exception lastError;

    lastError = Server.GetLastError();

    // If the last exception is HttpRequestValidationException

    // we log it and signout the user

    if (lastError is HttpRequestValidationException)

    {

        // Log information about the attack

        LogXssAttack();

        Server.ClearError();

    }

}

2.      What could potentially be done about it?

One of the option that can be quite annoying for attackers trying to scan the application for XSS is to log them off automatically when HttpRequestValidationException.

void Application_Error(object sender, EventArgs e)

{

    // Code that runs when an unhandled error occurs

    Exception lastError;

    lastError = Server.GetLastError();

    // If the last exception is HttpRequestValidationException

    // we log it and signout the user

    if (lastError is HttpRequestValidationException)

    {

        // Log the attack

        LogXssAttack();

        // If the user is authenticated we:

        // - log the user out

        // - invalidate his session

        // - redirect him to the login page

        if (Request.IsAuthenticated)

        {

            FormsAuthentication.SignOut();

            Session.Abandon();

            FormsAuthentication.RedirectToLoginPage();

        }

        Server.ClearError();

    }

}

public static void SafeRedirect(HttpResponse response, string rawRelativeUrl)

{

    Uri tmpUrl;

    // we use the default action of redirecting to

    // the root if the url is not defined

    if (response == null)

    {

        throw new ArgumentNullException("response");

    }

    if (rawRelativeUrl == null)

    {

        throw new ArgumentNullException("rawRelativeUrl");

    }

    if (rawRelativeUrl.Trim().Length == 0)

    {

        throw new ArithmeticException("rawRelativeUrl must not be empty");

    }

    // this method will parse the string into a url so we can make

    // sure it is a relative.  This protects against open redirects

    if (Uri.TryCreate(rawRelativeUrl, UriKind.Relative, out tmpUrl))

        response.Redirect(rawRelativeUrl);

}

Looking at the code, we can see that each parameter is validated and it makes use of the System.Uri class and only redirect if the rawRelativeUrl is relative. The issue with this code is that it doesn’t handle scheme relative paths. Scheme relative paths are basically a relative url that doesn’t include the scheme section. For example //www.microsoft.com is a scheme relative url that will redirect to {base scheme}//www.microsoft.com.

This means that if the application is hosted under https://www.mysite.com and the rawRelativeUrl is //www.microsoft.com, it will allow the redirect and the browser will be directed to https://www.microsoft.com. This is actually what SafeRedirect is trying to protect against.

To remediate the issue, the code needs to handle the scheme relative url case by rejecting rawRelativeUrl if it begins with the double forward slash ‘//’.

public static void SafeRedirect(HttpResponse response, string rawRelativeUrl)

{

    Uri tmpUrl;

    // we use the default action of redirecting to the root if the url is not defined

    if (response == null)

    {

        throw new ArgumentNullException("response");

    }

    if (rawRelativeUrl == null)

    {

        throw new ArgumentNullException("rawRelativeUrl");

    }

    if (rawRelativeUrl.Trim().Length == 0)

    {

        throw new ArithmeticException("rawRelativeUrl must not be empty");

    }

    // Reject scheme relative url

    if (rawRelativeUrl.StartsWith("//"))

        throw new ArgumentException("scheme relative url is not allow", "rawRelativeUrl");

    // this method will parse the string into a url so we can make

    // sure it is a relative.  This protects against open redirects

    if (Uri.TryCreate(rawRelativeUrl, UriKind.Relative, out tmpUrl))

        response.Redirect(rawRelativeUrl);

}

Installation

1. Copy MVCAntiforgeryTokenChecker.dll in your FxCop rule folder. By default it's under c:\Program Files\Microsoft FxCop 1.36\Rules
2. Launch FxCop and the rule is "AntiforgeryToken used" under "ASP.NET MVC Security" group.

MVCAntiforgeryTokenChecker.zip

Installation

1.  Unzip and select the appropriate rule for the fxcop release you are using
• For Visual Studio Team System 2005 select the fxcop 1.35 version and place it in C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules
• For Visual Studio Team System 2008 select the fxcop 1.36 version and place it in C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules
2. The rule can be enabled under the "ASP.NET Security" section and it's called "ViewStateUserKey used"

Update

I've been working with projects using ASP.NET MVC and made some update to the rule to ignore classes inheriting from ViewPage since MVC doesn't use ViewState.

ViewStateUserKey-1.2.zip

The document was targeted to ASP.NET 2.0 developers who were interested to know which control doesn't offer encoding to mitigate against XSS problems. The document is also very useful during code review and I've decided to quickly plug it into FxCop so it can quickly spot areas that should be reviewed.

The rule will load the control encoding information stored in asp_controls.xml and will apply the following logic:

• If properties that don't offer encoding are used, it will be listed in the FxCop result
• If it finds a property that offers encoding but that property is bound to html attribute, it will spot it to make sure that users cannot inject things like javascript: or other handlers
• In the future, it will only show cases where the attribute can be executed. I'm currently looking to potentially integrate the rule with the script mapping project from WASC.

This will give a detailed list of items to review. The aim is not to automatically detect XSS but to identify spots in the code that should be reviewed.

Installation

1. Simply unzip the files and put them in the FxCop Rules folder (C:\Program Files\Microsoft FxCop 1.36\Rules)
2. Launch FxCop
3. The rule can be selected from the Rules tab under the Html Review section

HtmlControlSpotter.zip

Side note

I was made aware that the initial content was provided as part of the companion content for the excellent book Hunting for Security bugs available at https://www.microsoft.com/mspress/companion/0-7356-2187-X/. The file attached to this is indeed base on the same content since I received it internally by the author's team. I found some slight issues and made some changes. I recommend the file I provide until the book companio content gets updated.

asp.net_control_encoding.htm