When creating a web application that accepts input from users one important step to ensure that you application is secure, is assigning a maximum length to user input. Keep in mind that input length validation is just the tip of a very large iceberg when it comes to web application security, but it is a good first step. It's safe to say that if someone is trying to put in 1200 characters for their first name that something fishy is going on.
As much as I love ASP.NET I've found that it can easily lull some programmers into a false sense of security when it comes to input length validation. To demonstrate what I am talking about I have put together a small application that will show how simple it is to pass longer than expected input to an application that would appear (to the uninformed programmer at least) to limit input length.
To begin I have created the basic aspx page below. Notice the MaxLength attribute that is highlighted in red:
This is where our security troubles often begin.... It seems like this MaxLength is telling us that it won't let anything over 9 characters get passed to our beloved server. Don't believe it! IT'S LYING!!! To understand why the MaxLength attribute dosn't do everything it claims it does lets go ahead and run out application and take a look at the rendered HTML:
As you can see, our seemingly invincible asp:TextBox control has been rendered as a standard html input with a maxlength of 9. This is bad because this on the client's side, so the client can change whatever they would like and send it back to the server. To show you what i'm talking about I am going to make use of a neat application called Burp Suite. Burp Suite is a collection of tools that can be used for attacking web applications. If you are at all interested in web security I recommend you download it and check out some of it's features. For the porpouse of this post we will be using Burp Proxy, which is a HTTP Proxy server that allows you to intercept, inspect and modify the raw http traffic being passed in both directions.
First I will go to the webpage with the vulnerability without intercepting anything. I attempt to add more than 9 characters and, as advertised, I am not able to.
Now I will begin capturing http traffic and submit the search text to the server. This is where things get interesting... Notice the red box in the image below:
So at this point burp suite has captured this HTTP request, showed me what params are in it (as well as letting me look at and mess with a whole lot of other info in the request). It is basically in a holding state at this point until I have modified what I want and decide to forward it to the server. So next I will change the value of tb_SearchBox and forward the request. See below:
As you can see i've added what ever I wanted to the value of tb_SearchBox and this will now be passed to the server when I click the "forward" button.
Alright... so now that we have an idea of why this is a vulnerability how do we fix it? The answer is by adding server side input validation. I've found that the simplest way to do this is to compare the text length to the MaxLength of the TextBox control. If the former is longer than the latter then your website is under attack. Period. What you do at that point is up to you but I recommend at a minimum doing what the comments in the IF statement from the image below suggest.
I hope this helps to make your website just a little more secure. Remember, always be wary of built in ASP.NET validation and when in doubt, go ahead and check it on the server side.