Preventing double submit on multi button forms with jquery

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

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

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).