Surviving validateRequest

TroubleshootingTips

LANGUAGES: All

ASP.NET VERSIONS: All

SurvivingvalidateRequest

Safeby Default Comes at a Cost

By Don Kiely

The Webis the last vestige of the wild, wild west, where the law what there is of it is overwhelmed by outlaws toting six shooters. That s old news, but it ssurprising how many sites and other online resources have vulnerabilities thathave been known and well understood for a long time. That s one of the reasonswhy Microsoft is moving to a safe by default model for many of its products.And if you ve moved to version 1.1 of the .NET Framework, you ve probably beenbitten in the butt by its default setting of true for validateRequest.

validateRequest is a nice feature that tellsASP.NET whether to examine all data from the browser for potentially maliciousinput particularly anything that looks like HTML or scripting that form thebasis for many types of attacks, such as cross-site scripting. By introducing validateRequestand setting it to true by default, Microsoft has very effectively put ahalt to some of the most common Web site attacks. But with such efficiencycomes some costs.

Thefirst problem with validateRequest comes when you run an ASP.NET 1.0application on a server with 1.1 installed. In many circumstances painfullymany you ll get an exception of A potentially dangerous Request.Form valuewas detected from the client when it detects unencoded input. This breaks theapplication, something that Microsoft strives not to do too often. In this caseit is justified. If you don t catch these kinds of attacks, your servers couldbe under a hacker s control without your knowledge. Fixing the app requiresthat you painstakingly visit each page in your application and do whatever ittakes to protect it from attack.

You haveseveral options for eliminating the exception message, both in 1.0 apps you remigrating and 1.1 apps you re building now. The first option and by far theworst choice, taken alone is to disable validateRequest. You can dothis for a single page by setting it to false in the page directive:

<%@ Page ...validateRequest="false" %>

Withthis setting, ASP.NET won t examine the data coming from the browser; it willsimply pass it on and process it like it did in version 1.0. You can also setit to false for the entire application by including it in the pageselement in the section of your web.config file:

You canalso change this same setting in machine.config to turn validation off for allapplications on that server.

Setting validateRequestto false stops the potentially dangerous message, but opens your appsto attacks. If you take this step, you must take responsibility for protectingyour app from attack. There are several ways to accomplish this:

Anotherproblem with validateRequest set to true is that it is a ratherbroad and stupid protection, erring on the side of catching too much ratherthan letting something dangerous slide by. So the practical reality is that itis fine for basic apps that don t gather much input from the browser, orperhaps for most pages in your app. But you ll still have to get your handsdirty for more interactive pages, because you ll want to turn it off for thosepages and sanitize all input as thoroughly as possible.

Checkout Microsoft s Knowledge Base article 821343 PRB: YouReceive an Error Message When You Deploy an ASP.NET 1.0 Application on a Serverwith ASP.NET 1.1 for more information and references. And visit the ASP.NETforums at http://www.asp.net if you havequestions or comments.

Don Kiely is senior technology consultantfor Information Insights, a business and technology consultancy in Fairbanks,AK. E-mail him at mailto:[email protected].