More powerful RequestValidator

Question

I've recently learned and tested that following xss attack can be launched against my site - in fiddle composer change POST request so that any text field will contain this:

<%u0008script>alert(1);<%u0008/script>

Than any label containing this value (not encoded) will execute alert(1). The proper solution is as always properly encode all outputs. But I've also modified RequestValidator:

protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex) {
  if (requestValidationSource == RequestValidationSource.Form) {
    if (value.IndexOf("<\bscript") >= 0) {
      validationFailureIndex = -1;
      return false;
    }
  }

  return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
}

Then I though - someone must have been through this already, is there any open source override for RequestValidator that will be

1) at least as powerful as native ASP.NET version

2) will handle also this xss

3) can handle even more

?

Answer 1

This is precisely one of the reasons we (the ASP.NET team) are winding down request validation and will eventually remove it from the product. It may have been good when it was introduced 10 years ago, but in 2014 it's not sufficient to stop real-world XSS attacks. Instead, the developer should validate all input according to his business logic, and he should appropriately encode all output in a manner safe for the underlying transport. See http://www.asp.net/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet,-and-what-to-do-instead#validation for more information.

Answer 2

.NET 4.5 added the AntiXSS library which protects from such attacks and can replace the default implementation of HtmlEncode etc. by allowing only safe characters. The list of characters for HtmlEncode appears in the method's documentation.

Note that what you encountered is not a request validation problem, much less a bug in .NET. What is invalid input in your case may be valid input in another scenario, eg a forum post editor like SO's.

The actual problem is a content encoding issue: the content wasn't rendered in a safe manner that would prevent the browser from interpreting it as script.