Good morning class!
Pop quiz: How many of you do proper input validation in your ASP.NET site, WebForms, MVC, or otherwise?
Some Background
There is an axiom in computer science: never trust user input because it's guaranteed to contain invalid data at some point.
In security we have a similar axiom: never trust user input because it's guaranteed to contain invalid data at some point, and your code is bound to contain a security vulnerability somewhere, somehow. Granted, it doesn't flow as well as the former, but the point still stands.
The solution to this problem is conceptually simple: validate, validate, validate. Every single piece of input that is received from a user should be validated.
Of course when anyone says something is a simple concept it's bound to be stupidly complex to get the implementation right. Unfortunately proper validation is not immune to this problem. Why?
The Problem
Our applications are driven by user data. Without data our applications would be pretty useless. This data is usually pretty domain-specific too so everything we receive should have particular structures, and there's a pretty good chance that a few of these structures are so specific to the organization that there is no well-defined standard. By that I mean it becomes pretty difficult to validate certain data structures if they are custom designed and potentially highly-complex.
So we have this problem. First, if we don't validate that the stuff we are given is clean, our application starts behaving oddly and that limits the usefulness of the application. Second, if we don't validate that the stuff we are given is clean, and there is a bug in the code, we have a potential vulnerability that could wreak havoc for the users.
The Solution
The solution as stated above is to validate all the input, both from a business perspective and from a security perspective. We want it to go something like this:
In this post we are going to look at the best way to validate the security of incoming data within ASP.NET. This requires looking into how ASP.NET processes input from the user.
When ASP.NET receives something from the user it can come from four different vectors:
- Within the Query String (?foo=bar)
- Within the Form (via a POST)
- Within a cookie
- Within the server variables (a collection generated from HTTP headers and internal server configuration)
These vectors drive ASP.NET, and you can potentially compromise an application by maliciously modifying any of them.
Pop quiz: How many of you check whether custom cookies exist before trying to use them? Almost everyone, good. Now, how many of you validate that the data within the cookies is, well, valid before using them?
What about checking your HTTP headers?
The Bypass
Luckily ASP.NET has some out-of-the-box behaviors that protect the application from malicious input. Unfortunately ASP.NET isn't very forgiving when it comes to validation. It doesn't distinguish between quasi-good input and bad input, so anything containing an angle bracket causes a YSoD.
The defacto fix to this is to do one of two things:
- Disable validation in the page declaration within WebForms, or stick a [ValidateInput(false)] attribute on an MVC controller
- Set <pages validateRequest="false"> in web.config
What this will do is tell ASP.NET to basically skip validating the four vectors and let anything in. It was assumed that you would do validation on your own.
Raise your hand if you think this is a bad idea. Okay, keep your hands up if you've never done this for a production application. At this point almost everyone should have put their hands down. I did.
The reason we do this is because as I said before, ASP.NET isn't very forgiving when it comes to validation. It's all or nothing.
What's worse, as ASP.NET got older it started becoming pickier about what it let in so you had more reasons for disabling validation. In .NET 4 validation occurs at a much earlier point. It's a major breaking change:
The request validation feature in ASP.NET provides a certain level of default protection against cross-site scripting (XSS) attacks. In previous versions of ASP.NET, request validation was enabled by default. However, it applied only to ASP.NET pages (.aspx files and their class files) and only when those pages were executing.
In ASP.NET 4, by default, request validation is enabled for all requests, because it is enabled before the BeginRequest phase of an HTTP request. As a result, request validation applies to requests for all ASP.NET resources, not just .aspx page requests. This includes requests such as Web service calls and custom HTTP handlers. Request validation is also active when custom HTTP modules are reading the contents of an HTTP request.
Since backwards compatibility is so important, a configuration attribute was also added to tell ASP.NET to revert to the 2.0 validation mode meaning that it occurs later in the request lifecycle like in ASP.NET 2.0:
<httpRuntime requestValidationMode="2.0" />
If you do a search online for request validation almost everyone comes back with this solution. In fact, it became a well known solution with the Windows Identity Foundation in ASP.NET 4.0 because when you do a federated sign on, WIF receives the token as a chunk of XML. The validator doesn't approve because of the angle brackets. If you set the validation mode to 2.0, the validator checks after the request passes through all HttpModules, which is how WIF consumes that token via the WSFederationAuthenticationModule.
The Proper Solution
So we have the problem. We also have built in functionality that solves our problem, but the way it does it kind of sucks (it's not a bad solution, but it's also not extensible). We want a way that doesn't suck.
In earlier versions of ASP.NET the best solution was to disable validation and within a HttpModule check every vector for potentially malicious input. The benefit here is that you have control over what is malicious and what is not. You would write something along these lines:
public class ValidatorHttpModule : IHttpModule
{
public void Dispose() { }
public void Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(context_BeginRequest);
}
void context_BeginRequest(object sender, EventArgs e)
{
HttpApplication context = (HttpApplication)sender;
foreach (var q in context.Request.QueryString)
{
if (CheckQueryString(q))
{
throw new SecurityException("Bad validation");
}
}
foreach (var f in context.Request.Form)
{
if (CheckForm(f))
{
throw new SecurityException("Bad validation");
}
}
foreach (var c in context.Request.Cookies)
{
if (CheckCookie(c))
{
throw new SecurityException("Bad validation");
}
}
foreach (var s in context.Request.ServerVariables)
{
if (CheckServerVariable(s))
{
throw new SecurityException("Bad validation");
}
}
}
// <snip />
}
The downside to this approach though is that you are stuck with pretty clunky validation logic. It executes on every single request, which may not always be necessary. You are also forced to execute the code in order of whenever your HttpModule is initialized. It won't necessarily execute first, so it won't necessarily protect all parts of your application. Protection from an attack that doesn't protect everything from that particular attack isn't very useful. <Cynicism>Half-assed protection is only good when you have half an ass.</Cynicism>
What we want is something that executes before everything else. In our HttpModule we are validating on BeginRequest, but we want to validate before BeginRequest.
The way we do this is with a custom RequestValidator. On a side note, this post may qualify as having the longest introduction ever. In any case, this custom RequestValidator is set within the httpRuntime tag within the web.config:
<httpRuntime requestValidationType="Syfuhs.Web.Security.CustomRequestValidator" />
We create a custom request validator by creating a class with a base class of System.Web.Util.RequestValidator. Then we override the IsValidRequestString method.
This method allows us to find out where the input is coming from, e.g. from a Form or from a cookie etc. This validator is called on each value within the four collections above, but only when a value exists. It saves us the trouble of going over everything in each request. Within an HttpModule we could certainly build out the same functionality by checking contents of each collection, but this saves us the hassle of writing the boilerplate code. It also provides us a way of describing the problem in detail because we can pass an index location of where the problem exists. So if we find a problem at character 173 we can pass that value back to the caller and ASP.NET will throw an exception describing that index. This is how we get such a detailed exception from WIF:
A Potentially Dangerous Request.Form Value Was Detected from the Client (wresult="<t:RequestSecurityTo...")
Our validator class ends up looking like:
public class MyCustomRequestValidator : RequestValidator
{
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
{
validationFailureIndex = 0;
switch (requestValidationSource)
{
case RequestValidationSource.Cookies:
return ValidateCookie(collectionKey, value, out validationFailureIndex);
break;
case RequestValidationSource.Form:
return ValidateFormValue(collectionKey, value, out validationFailureIndex);
break;
// <snip />
}
return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
}
// <snip />
}
Each application has different validation requirements so I've just mocked up how you would create a custom validator.
If you use this design you can easily validate all inputs across the application, and you don't have to turn off validation.
So once again, pop quiz: How many of you do proper input validation?