Eglasius

Using cookies to control return page after login on asp.net mvc 3

2011-09-18T15:48:00.001-07:00

Default behavior and the scenario

On asp.net in general, when an user tries to access a page that requires the user to login first, it is fairly common to use the built in support to return to that page after the user logins.

When an user tries to access the page and an authorization made by the code determines the user doesn’t have access, a 401 is returned by that code. When that happens the FormsAuthenticationModule intercepts it and instead redirects the user to the login page configured in the asp.net config.

When the redirect to the login page is sent, it includes a returnUrl query string parameter. On a successful the user is sent back to that url. If no return url is indicated, the user is sent to a default url after authentication.

The above works fine, if the scenario fits well with the site.

One consideration is with the use of register and forgot password options, in which case extra code needs to be put in place if you want the user to be redirected to the url visited when the process started. A similar case is if the user visits any other page linked there, like a faq or about page and then hitting the login option you almost certainly have in your master page/layout.

Another consideration comes with the user of ajax based login forms accessible anywhere on the site. Depending on the site, the user might be on a page where you don’t want it redirect to. You still might want it redirected to a page the user visited before doing some action, like in a client’s scenario, a specific deal page.

The cookie based approach

One way to handle the above scenario is by storing the returnUrl in a cookie. By doing so the user can visit other pages (like the register/forgot password options), and the redirect will go to the last relevant page. Additionally you can control which actions are considered relevant pages, in case the user uses the login option in your master page/layout in any random page they happen to be at.

To set the cookie in an unauthorized access scenario, one could use a module based approach just like the FormsAuthenticationModule. In our case, we instead introduced an AuthorizeWithReturnCookieAttribute, and replaced the use of [Authorize] with [AuthorizeWithReturnCookie].

 public class AuthorizeWithReturnCookieAttribute : AuthorizeAttribute  
{  
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)  
    {  
        var ctx = filterContext.HttpContext;  
        NavigationCookies.SetReturnAfterAuthenticationUrl(ctx, ctx.Request.RawUrl);  
        base.HandleUnauthorizedRequest(filterContext);  
    }  
} 

To set the cookie when a relevant page was visisted, we introduced a separate attribute ReturnAfterAuthenticationAttribute. Unlike the authorize attribute, this one is used on public pages, we want the user redirected back to if the login option in the master page/layout is used.

 public class ReturnAfterAuthenticationAttribute : ActionFilterAttribute  
{  
    public const string ViewDataIgnoreKey = "IgnoreReturnAfterAuthentication";  
    public override void OnActionExecuted(ActionExecutedContext filterContext)  
    {  
        var ctx = filterContext.HttpContext;  
        if ((bool?)filterContext.Controller.ViewData[ViewDataIgnoreKey] == true) return;  
        if (ctx.User.Identity.IsAuthenticated) return;  
        if (filterContext.HttpContext.Request.HttpMethod != "GET") return;  
        NavigationCookies.SetReturnAfterAuthenticationUrl(ctx, ctx.Request.RawUrl);  
    }  
} 

There are a few more things going on in the above attribute.

We can avoid it being set based on logic executed in the action method, by setting true on the corresponding value in ViewData. In retrospective ctx.Items is probably the right place for it.
No point in setting the cookie if the user is already authenticated.
Post requests are not tracked.

For a more complete sample, the modified logon and register methods of the asp.net mvc template below. It still supports the returnUrl and gives it precendence (not what we did in our case, as we only use the cookie one).

 [HttpPost]  
public ActionResult LogOn(LogOnModel model, string returnUrl)  
{  
    if (ModelState.IsValid)  
    {  
        if (Membership.ValidateUser(model.UserName, model.Password))  
            return SetAuthCookieAndRedirect(model.UserName, model.RememberMe, returnUrl);  
        ModelState.AddModelError("", "The user name or password provided is incorrect.");  
    }  
    // If we got this far, something failed, redisplay form  
    return View(model);  
} 

 [HttpPost]  
public ActionResult Register(RegisterModel model)  
{  
    if (ModelState.IsValid)  
    {  
        // Attempt to register the user  
        MembershipCreateStatus createStatus;  
        Membership.CreateUser(model.UserName, model.Password, model.Email, null, null, true, null, out createStatus);  
  
        if (createStatus == MembershipCreateStatus.Success)  
            return SetAuthCookieAndRedirect(model.UserName);  
        ModelState.AddModelError("", ErrorCodeToString(createStatus));  
    }  
    // If we got this far, something failed, redisplay form  
    return View(model);  
} 

 ActionResult SetAuthCookieAndRedirect(string userName, bool createPersistentCookie=false, string returnUrl=null)  
{  
    FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);  
    var url = IsValidReturnUrl(returnUrl) ?  
        returnUrl :  
        NavigationCookies.GetReturnAfterAuthenticationUrl(Request);  
    if (string.IsNullOrEmpty(url)) return RedirectToAction("Index", "Home");  
    return new RedirectResult(url);  
}  
private bool IsValidReturnUrl(string returnUrl)  
{  
    return Url.IsLocalUrl(returnUrl) && returnUrl.Length > 1 && returnUrl.StartsWith("/")  
           && !returnUrl.StartsWith("//") && !returnUrl.StartsWith("/\\");  
} 

The NavigationCookies class just sets/gets the cookie:

 public class NavigationCookies  
{  
    private const string ReturnAfterAuthenticationKey = "ReturnAfterAuthentication";  
    public static void SetReturnAfterAuthenticationUrl(HttpContextBase context, string url)  
    {  
        url = VirtualPathUtility.ToAbsolute(url, context.Request.ApplicationPath);  
        var cookie = context.Response.Cookies[ReturnAfterAuthenticationKey];  
        cookie.Expires = DateTime.Now.AddDays(1);  
        cookie.Value = url;  
    }  
    public static string GetReturnAfterAuthenticationUrl(HttpRequestBase request)  
    {  
        var cookie = request.Cookies["ReturnAfterAuthentication"];  
        if (cookie == null || cookie.Expires > DateTime.Now) return String.Empty;  
        return cookie.Value;  
    }  
} 

I added a full sample that uses the asp.net mvc 3 template to the following github repository: https://github.com/eglasius/Cookie-Based-ReturnUrl-After-Authentication-Sample. You can download a zip file of it directly at: https://github.com/eglasius/Cookie-Based-ReturnUrl-After-Authentication-Sample/zipball/master.

Adding sharing buttons for all your blogger posts

2010-10-18T23:00:00.000-07:00

The layout I’ll show in this blog post includes sites that are related to software development, but this can be easily be modified by removing them or replacing them with other services appropriate to the specific particular blog.

Open your blogger dashboard and select the design option for your blog. Use the Download Full Template option in Edit HTML to save a copy of your current template. This is important to make sure you can go back to your current template if anything goes wrong.

In the Edit Template section select Expand Widget Templates. Search for post-footer-line in the textbox that contains your template. These corresponds to the lines with the built-in blogger sharing options and labels. I used post-footer-line-3 (was empty) and added another one (post-footer-line-4).

Following the html to share on DZone, DotNetShoutout, DotNetKicks, Hacker News, Digg, Reddit, Google Buzz and Yahoo Buzz:

<div class='post-footer-line post-footer-line-3'>
	<b:if cond='data:blog.pageType == &quot;item&quot;'>
	 <span style='top: 5px; position:relative; '>
		 <script type='text/javascript'> 
			var dzone_url = '<data:post.url/>';
			var dzone_title = '<data:post.title/>'; 
			var dzone_style = '2'; 
		 </script>
		 <script language='javascript' src='http://widgets.dzone.com/links/widgets/zoneit.js'/>
	 </span>
	 <a expr:href='&quot;http://dotnetshoutout.com/Submit?url=&quot; + data:post.url + &quot;&amp;title=&quot; + data:post.title' expr:id='data:widget.instanceId + &quot;_shoutit&quot;' rel='nofollow' rev='vote-for'> <img alt='Shout it' expr:src='&quot;http://dotnetshoutout.com/image.axd?url=&quot; + data:post.url' style='border:0px; top: 2px; position:relative;'/></a>
	 <a expr:href='&quot;http://www.dotnetkicks.com/submit/?url=&quot; + data:post.url + &quot;&amp;title=&quot; + data:post.title' expr:id='data:widget.instanceId + &quot;_kickit&quot;' rel='nofollow'><img alt='Submit this story to DotNetKicks' expr:src='&quot;http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=&quot; + data:post.url'/></a>
		<a expr:href='&quot;http://news.ycombinator.com/submitlink?u=&quot; + data:post.url + &quot;&amp;t=&quot; + data:post.title' rel='nofollow'><img src='http://ycombinator.com/images/y18.gif' title='Submit to Hacker News'/></a>
	</b:if>
</div>
<div class='post-footer-line post-footer-line-4'>
	<b:if cond='data:blog.pageType == &quot;item&quot;'>
		<script type='text/javascript'>
			(function() {
			var s = document.createElement('SCRIPT'), s1 = document.getElementsByTagName('SCRIPT')[0];
			s.type = 'text/javascript';
			s.async = true;
			s.src = 'http://widgets.digg.com/buttons.js';
			s1.parentNode.insertBefore(s, s1);
			})();
		</script>
		<span style='top: 7px; position:relative; margin-right: 5px;'>
			<a class='DiggThisButton DiggCompact'/>
		</span>
		<script>
			reddit_url='<data:post.url/>';
			reddit_title='<data:post.title/>';
		</script>
		<span style='top: 10px; position:relative; margin-right: 5px;'>
			<script language='javascript' src='http://reddit.com/button.js?t=1'/>
		</span>
		<a class='google-buzz-button' data-button-style='small-count' href='http://www.google.com/buzz/post' rel='nofollow' title='Post to Google Buzz'/>
		<script src='http://www.google.com/buzz/api/button.js' type='text/javascript'/>
		<script type='text/javascript'>
			yahooBuzzArticleHeadline = '<data:post.title/>';
			yahooBuzzArticleSummary = '<data:post.title/>';
			yahooBuzzArticleCategory = 'science';
			yahooBuzzArticleType = 'text';
			yahooBuzzArticleId = <data:post.url/>;
		</script>
		<span style='display: inline-block;'>
			<script badgetype='text-votes' src='http://d.yimg.com/ds/badge2.js' type='text/javascript'/>
		</span>
	</b:if>
</div>

Special blogger if at lines 2 and 17 make sure we only display the various share options on the actual post pages. Some of the share code above uses the current page’s URL, so if we wanted to share options in the list of blog posts in the home page of the blog we would need to use alternate sharing code and move the general script files to the blog template.

Spans with relative positioning at lines 3, 27, 34 were added to align the corresponding share buttons.

The span at line 46 makes sure the Yahoo Buzz button code is contained in a block element. This fixes an issue on IE, where the image shows way above the rest of the text.

The line 42 sets the Yahoo Buzz category to science, you might want to use a different category.

Below some blog posts used as referenced for some of the share code:

Disambiguating a method during a .net library upgrade

2010-10-17T23:00:00.001-07:00

One scenario I had recently, involved a method that was named in such a way that it wasn’t clear the effect it would have given the context. Of course, it came to attention because it was used expecting a different behavior. The upside is that it was detected during a focused integration test, so it was revealed very early in the involved scenario.

As the library is used in more than one project, this raised the question if the code could have been used in such way in any of the other projects. We decided on changing it so we could tell if this was the case during the build of any project that used the library.

Below code sample outlines the approach we used to update the library so developers involved review the usages to the now clearly named alternatives.

[Obsolete("Use ActionA or ActionB", true)]
public static void ActionThatWasntClearIfItDidAorB()
{
    ActionA();
}
public static void ActionA()
{
    // original code
}
public static void ActionB()
{
    // alternative code
}

Adding reCAPTCHA with JavaScript

2010-10-15T23:00:00.000-07:00

In some dynamic interfaces, you may not want to load reCAPTCHA with the initial page loaded. In others you can’t because it would expire by the time the user uses that piece of the UI.

In the above scenarios you can add reCAPTCHA just when you need it.

First include the recaptcha script:

<script type="text/javascript" src='http://www.google.com/recaptcha/api/js/recaptcha_ajax.js'></script>

If the page is served over https make sure to use that in the above url. Alternatively do it dynamically, like in asp.net MVC you can do:

<script type="text/javascript" src='<%= Request.Url.Scheme + 
"://www.google.com/recaptcha/api/js/recaptcha_ajax.js" %>'></script>

Add an empty div where you’ll want the reCAPTCHA to appear in the HTML.
In the corresponding JavaScript action, do:

Recaptcha.create(theRecaptchaPublicKey, targetDiv);

If you are using jQuery, one way is to retrieve it based on a css class like:

$('#someContainer .captcha').each(function () {
    Recaptcha.create(theRecaptchaPublicKey, this);
});

Adding reCAPTCHA to asp.net MVC

2010-10-14T23:00:00.000-07:00

These are just a few steps, as the latest reCAPTCHA library has all the pieces you need for asp.net MVC:

Go to Get reCAPTCHA, which gives you the public and private keys you need to use reCAPTCHA with your site
Download the latest .net library at: http://code.google.com/p/recaptcha/downloads/list. Currently: dotnet-1.0.4.0
Add <%= Html.GenerateCaptcha()%> to the form you want to protect with the reCAPTCHA. Naturally you have to add the namespace for the extension to be recognized, some of the options:
- Add the namespace to the web.config:
```
<pages>
      <namespaces>
...
        <add namespace="Recaptcha" />
```
- Add the namespace at the view:
```
<%@ Import Namespace="Recaptcha" %>
```
- Add your own extension method that wraps it. I changed the signature to return MvcHtmlString to prevent double encoding when using it with “<%:” instead of “<%=”
```
public static MvcHtmlString GenerateCaptcha(this HtmlHelper htmlHelper)
{
    var html = Recaptcha.RecaptchaControlMvc.GenerateCaptcha(htmlHelper);
    return MvcHtmlString.Create(html);
}
```

Add the RecaptchaControlMvc.CaptchaValidator attribute to your controller. Also add parameters named captchaIsValid and captchaErrorMessage. Just like:

[RecaptchaControlMvc.CaptchaValidator]
public ActionResult MyMethod(Something else, bool captchaValid, string captchaErrorMessage)
{
// do something if (!captchaValid)
}

Configure your keys. Some options:
- Add to appsettings in the web.config, with entries named: RecaptchaPublicKey and RecaptchaPrivateKey
- Set at Application Start:
```
RecaptchaControlMvc.PrivateKey = privKey;
RecaptchaControlMvc.PublicKey = pubKey;
```

Protecting asp.net machine keys and connection strings

2010-10-13T23:00:00.001-07:00

Last month I blogged about how the asp.net padding oracle vulnerability related to getting different levels of access to the application, where part of it involved gaining access to unprotected machine keys at the web.config of the affected sites.

While the Microsoft’s patch that closes the vulnerability is already on Windows Update and other distribution channels, it doesn’t mean we shouldn’t pay attention to keeping important access information of our application out of harms way.

Protecting config sections

One way to protect machine keys, connection strings and other sensitive information in the web.config is to use protected sections. Check Microsoft’s Walkthrough: Encrypting Configuration Information Using Protected Configuration, for steps to use them in your application. By using this approach, the information is no longer in clear text in the web.config, and is encrypted with a key that’s not anywhere in the web site’s folder.

Machine’s level web.config

If the server isn’t shared with third party applications, another option is to configure the machine key at the machine level’s web.config. This is another way the machine key wouldn’t have been exposed in the event access to the site’s folder was gained, like in the recent vulnerability.

For .net 4, look it at: %systemroot%\Microsoft.NET\Framework\v4.0.30319\Config\. Note that for .net 3 and 3.5, it uses the same config than the 2.0 framework.

NuPack Visual Studio Add Package References Crash and TypeLoadException

2010-10-12T22:14:00.001-07:00

This is about a couple issues I found just after deciding to give NuPack a go, and what to do if you see them.

Add Package References - unloaded projects

After installing, I tried the Add Package References on an existing small solution. There it crashed. This wasn’t the same scenario described at Yet Another Debugging Tale – Visual Studio Disappearing, since the classic Solution Explorer was used and at least I got the closing notification during the crash.

A quick look at the solution I had opened revealed the likely cause: a couple projects in the solution that could not be loaded. So I quickly confirmed it, removed those projects and tried again, problem gone. Bug reported.

Package Manager Console reports TypeLoadException

When opening the console you see the below:

System.TypeLoadException: Could not load type 'System.Management.Automation.Runspaces.InitialSessionState' from assembly 'System.Management.Automation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at NuPackConsole.Host.PowerShell.Implementation.PowerShellHostProvider.CreateHost(IConsole console)
   at NuPackConsole.Implementation.PowerConsole.HostInfo.get_WpfConsole()
   at NuPackConsole.Implementation.PowerConsoleToolWindow.get_WpfConsole()System.InvalidOperationException: Can't start ConsoleDispatcher. Host is null.
   at NuPackConsole.Implementation.Console.ConsoleDispatcher.Start()
   at NuPackConsole.Implementation.PowerConsoleToolWindow.MoveFocus(FrameworkElement consolePane)

The trace is a big tell here, since it mentions PowerShell right there. Searched and installed Power Shell, and I had an operational console. Specifically I used: Windows Management Framework Core package which contains PowerShell 2.

Migrating CentOS servers from Linode to Amazon EC2, or what I did at the end

2010-10-03T21:46:00.001-07:00

The guys at 619Cloud have built an interesting script to migrate Linux servers across cloud providers. Although it was created specifically for CentOS 5.X servers, the mechanisms it uses are simple enough that should work with most Linux distributions.

The script is very simple, as it mainly uses rsync to efficiently copy everything (excluding some special folders) over SSH to the target server. Because of this, the kernel version of the target server must be the same, as otherwise you could have unexpected issues.

Some bits related to the journey:

You can use rsync with the .pem key files you get when setting the new EC2 box. In fact you can use the following rsync option to set any other SSH parameters: --rsh "ssh –i pathToPemFile".
Make sure you do chmod 400 to the key file, otherwise SSH will reject using it.
You can use scp if you just need to copy a couple small files. From a Windows box you can use pscp from Putty.
If you do use the script / rsync to copy from root, make sure you don’t have any network locations mounted in the file system. Ignore this and you’ll get a lot more than you asked for. Alternatively you can explicitly exclude them, like the script does for some system dirs.

I tried using the script on a migration from Linode to Amazon Elastic Compute Cloud (EC2) and ran into issues where the newly created target boxes would lock down. It could have been because of not using the same kernel version (there wasn’t a matching ami), because of Amazon’s kernel modifications or maybe something as simple as network/firewall related configurations on the box that prevented it to work on the new environment.

After being faced with the above, I decided it was time to avoid the issue altogether and try a different approach. This is what I did at the end after I had an EC2 box (with ebs) that I was having trouble getting up, but already had all the data I needed (from the use of the script):

Stopped the EC2 instance
Detached the ebs volume
Launched a new EC2 instance
Attached the ebs volume
Moved the data out of the ebs volume, as I didn’t want all the rest of the system or application files it contained
Quickly installed the services we had in the original box and pointed them to/imported the original data

Preventing double submit on multi button forms with jquery

2010-09-30T02:12:00.000-07:00

Note that this is just a fast feedback mechanism, it shouldn't replace server side logic to prevent double submits. This is specially true if the operations can’t be easily reverted or there would be associated costs to reversing the operation.

With that out of the way, lets get right to the code:

   1: $(document).ready(function () {

   2:     $('form').submit(function (e) {

   3:         var theForm = $(this);

   4:         var isValid = doSomeFormValidations(theForm);

   5:         if (!isValid) return false;

   6:         setTimeout(function () {

   7:             var btn = theForm.find('input[type="submit"]');

   8:             btn.attr('disabled', 'disabled');

   9:             btn.val('Processing');

  10:          }, 10);

  11:         return true;

  12:     });

  13: });

Replace doSomeFormValidations with your own logic and you are good to go. There are other alternatives you might already be using, like having the button disabled until all validations passes. The important bit there is to make sure it’ll only disable the buttons if all validations passed.

Now lets go over some pieces and why those are relevant to it working with multi button forms.

return true/false in the submit body: true moves forward with the submit, while false cancels it.
- An alternative to this is returning false, unbinding our submit function and explicitly calling theForm.submit(). While this seems to work in the multiple button scenario, we are playing with fire here. We are relying on jquery or the underlying browser events/functions to send that last clicked button’s value. This is an implicit assumption we would be making, and it's usually based on works on my machine.
Disabling the submit buttons & adding a processing message for the user:
- No delay: has the undesired side effect that the button’s value isn't sent with the request in some browsers. Additionally it can even prevent the submit if it were disabled on the button’s click instead of the form’s submit. This is not totally unexpected as we are disabling the button. In fact, disabling any other input element (textboxes, select, etc.) can cause that data not to be sent to the server just like with our selected button’s value.
- Delay: By adding an insignificant delay, we let the rest of the submit behavior do its thing, so all the values in the form are sent in the request, including the selected button’s value. After those values are grabbed by the submit, we can disable controls and change values without affecting what will be sent to the server.
Don’t call use an id/name of ‘submit’ in your buttons. While not shown in the above code, this is important as it could cause conflicts with the submit events.

I want to stress out what I just mentioned in the no delay bullet. Just disabling any input of the form right away, will prevent the value from being sent to the server in some browsers.

This can easily get you into a situation where you can't figure out why the button pressed isn't being sent to the server, specially if you are working on an already built third party site. So if you are missing any input, first use a developer tool to inspect the elements and then go through the scripts, it's very likely somewhere in there.

You can tweak the above function to fit your needs, like display a different message, hide part of the UI, take actions if it'll timeout.

asp.net padding oracle: impact on asp.net MVC and PHP

2010-09-24T14:43:00.001-07:00

2 days ago, I wrote about how the padding oracle vulnerability related to getting various levels of access in ASP.NET.

Let’s see how all the items I mentioned on my earlier post relate to ASP.NET MVC (and some news):

View State: We don’t use it
Session cookies: Unrelated to the attack
Authentication cookies: These are signed, so you have to actually get the keys to be able to get around it. Additionally, by using the Microsoft workaround, we make sure we don’t expose information on the decryption with it
Custom encryption using the machine key. This is susceptible, make sure that if you are receiving anything unexpected out of the Decrypt call you throw an error / just like if it the Decrypt call had failed. That along with the Microsoft workaround will prevent decryption information being exposed. See Understanding Padding Oracle Attacks for more information on why that matters. For best results, consider if you can avoid sending it to the client altogether, or sign/validate the data
WebResource.axd and ScriptResource.axd: These built-in are a huge problem in this vulnerability, but as we don’t use them, we disable them (see the side note below)
HtmlHelper.AntiForgeryToken: uses the machinekey to encrypt the cookie but uses it with mac to make sure it hasn’t been modified. Not a problem if you use the Microsoft workaround / don’t disclose details on the error.
I might be missing some, so pay attention to any other feature that uses encryption/decryption.

Additionally, use security best practices all around, don’t send sensitive data to the client, don’t assume anything you sent to the browser hasn’t been tampered, keep your connection strings safe, have a firewall that further prevents external access, act as if the web.config could be read from outside (protected sections or any other measure).

Beyond the ASP.NET features: You don’t need to be using anything at all of the ASP.NET platform, to be vulnerable in an IIS install that has ASP.NET enabled. If the framework is 3.5 SP1 or above, this means access to any special file in the site’s folder (including your aspx/php files, config files, embedded data files). Here is a blog post more specific to PHP in IIS: ASP.NET vulnerability affecting PHP sites on IIS.

ASP.NET MVC is impacted by the above as well. The access to any file issue, is caused by the built-in handlers I mentioned above: WebResource.axd and ScriptResource.axd. Exactly which handler config you need to disable depends on the IIS version / mode (classic vs. integrated) and the version, I don’t have a compiled list, but you can find the list of handlers added in the machine web.config (.NET Framework in the Windows folder) for the classic mode or the IIS applicationHost.config for integrated mode. It’s a good exercise to take a look at those anyway.

Removing the handlers means the attacker can no longer get to the special files (including web.config) in your site. That said, you still want to prevent the attacker from gaining ground into your site’s encryption/decryption protections related to the machine key. So, regardless of what we discussed above, go and apply the Microsoft workaround.

asp.net padding oracle: how it relates to getting the web.config, forging authentication cookies and reading other sensitive data

2010-09-22T15:05:00.001-07:00

This ASP.NET security vulnerability is certainly very serious: (2416728) Vulnerability in ASP.NET Could Allow Information Disclosure. Scott Guthrie from Microsoft has a couple good blog posts about it. Those links contain information about the current workaround. Important Update: Microsoft published the patch, make sure to use that instead of the workaround – Scott blogged the details here.

When successful, the attacker can decrypt any value sent to the client encrypted with the ASP.NET key. Examples of these are authentication cookies and encrypted View State (this last one is not necessarily encrypted to begin with depending on the configuration).

Having the ability to decrypt any value, also gives the attacker the ability to re-encrypt a modified version of the data. It’s not without restrictions, as the mechanism that allows to do so requires a piece of garbage data the attacker can’t control to end somewhere in the message. The attacker controls where in the message the garbage appears, depending on the message the garbage can be put in a location that is irrelevant or have a side effect the attacker doesn’t care about. The size of the garbage matches the block size, so we are talking 16 bytes for a 128 bit encryption.

It’s important to note that at this stage the attacker doesn’t hold the actual keys. This is important, as it means the attacker can’t get through signed values. Even if the ability to re-encrypt were related to the signing of the values, the attacker will still end with garbage somewhere in the message, making it very hard to produce a valid signature.

So far the attacker gets any sensitive information stored in all those encrypted values sent to the client. So let’s take a look at some scenarios:

Ability to view all view state data.
- By default the data isn’t really encrypted, so it’s usually not new you can get to that data.
- When following best practices there isn’t anything in there that matters, and also the app shouldn’t rely on it being tamper proof.
- Above said, if it’s configured to validate the View State using HMAC, it prevents the attacker at this stage from posting modified View State.
- While there may not be sensitive information in the View State, it could still be the padding oracle the attacker needs.
Ability to read session cookies.
- This is totally unrelated to the attack since these cookies contain an encoded value generated by a random cryptographic provider (so it can’t be predicted). In other words, these cookies aren’t encrypted at all.
- For extra protection, you can store a value you can relate to the authentication in the session and check authentication vs. session to make sure the user owns that session. Of course that won’t work if the feature works for anonymous users, although you could emit a special ticket for those users if it’s important to protect the session.
Ability to read the authentication cookie.
- This just allows the user to see the username, and how the rest of the structure of the ticket is created.
- As the authentication ticket in the cookie is signed, the attacker can’t forge other user’s cookie with the padding oracle attack so far.
- If the attacker sniffed an authentication cookie/ticket, then the account was already compromised, regardless of this attack.
- As the authentication cookies are always sent in each request, the only way to really protect them would be to have all requests that send the cookie back through https. See the “Cookie hijacking” section in http://en.wikipedia.org/wiki/HTTP_cookie
Any custom use of encryption using machine key in the site.
- The data will be able to be decrypted after the successful attack.
- It could also be attacked directly if no measures that consider padding oracle exposure are taken. Even with the Microsoft workaround mentioned in the advisory, the code might suffer from the issue / by not dealing with the invalid data as it were a failed decryption.
WebResource.axd – here gets uglier:
- This feature is used by ASP.NET to allow serving embedded resources. An example of these would be embedded CSS files that belong to a custom control and are embedded for ease of distribution.
- This special handler only uses decryption to receive which embedded resource it will use. This means the attacker can forge valid requests / putting some garbage in an irrelevant part of the message.
- The request includes which assembly the resource is in, so the attacker has gained the ability to access any embedded resource in any assembly accessible to the application.
ScriptResource.axd – the real deal:
- This feature is related to serving combined script files into one (js), which might belong to multiple controls, but it’s not restricted to it. That’s what it’s supposed to be for, but I can’t confirm if it has other intended users.
- It works just like WebResource.axd, only encryption / no signing.
- Its scope is beyond just serving embedded resources, it also serves files.
- The files served aren’t restricted to be JavaScript files, so it can serve any file.
- The above means the attacker has gained the ability to access any file accessible to the application. It’s not restricted to only js files, and doesn’t take any special action to block special files. One of such files is the web.config.
- ASP.NET normally uses the handlers configuration to determine which files are not accessible, so web.config is configured with an access forbidden handler. This specific mechanism isn’t used by ScriptResource.axd.

The workaround to prevent the attack from reaching this stage is at the beginning.

It’s obvious that gaining access to the web.config is very serious in ASP.NET (not dismissing all the rest of the accesses so far). The file is considered by many as something specially protected by ASP.NET that shouldn’t ever be exposed from the ASP.NET application. Sure it’s a wrong assumption, but it’s a common one. Not assuming is secured means extra complexity, like using encrypted values and having the key elsewhere in the server / with the corresponding configurations, permissions and then dealing with deploying that in web farms scenarios.

While special access info might be exposed in the web.config, there could be other measures in place that prevent doing something with it. Things like the database not being accessible from outside, other pieces being behind a firewall, extra measures to get in, etc. All that said, it eases the attacker’s job a lot on preparing an attack at those levels.

Something that sometimes happens with web.config, specially on web farms scenario / or hosted scenarios, is that other keys like the machinekey ends up being set in the web.config. Clearly, the consequences with the current vulnerability in the wild are catastrophic. Once the attacker gains access to those keys, the ability to sign is gained, which means any request can be forged, signed or not; can now forge an authentication cookie. At least with the default forms authentication implementation, there is a question about it here: is-there-a-different-way-to-do-asp-net-forms-authentication-thats-already-built.

The DotNetNuke was an ASP.NET application that they picked as a demonstration of the size of the issue. The default install generates machinekey at the site level, so by using the oracle padding attack, they get to forge an authentication user of an admin. What is worst is that they combined the new access the admin account gives them with a separate vulnerability/attack and can manage to get up to System privilege on the target server.

If you haven’t after seeing the links at the top, go and apply the workaround to your applications now. If you want to know about what a padding oracle attack is, check out: Understanding Padding Oracle Attacks. If you are in ASP.NET MVC, Sharepoint or anything else that’s hosted in ASP.NET, yes you are vulnerable if you don’t have the workaround in place (or good equivalent).