Co-Sponsored by:   Latest Features  • Conflict Resolution  • Cause and Effect  • Why Are You Still Single?  • Future Features of ASP.NET  • WCF Proxies: To Cache or Not to Cache? Article Rating Rate this article on a scale from 0 to 5 5 Best 4   3   2   1   0 Worst Email Tell a friend about this article!

Troubleshooting Tips

LANGUAGES: All

ASP.NET VERSIONS: All

Surviving validateRequest

Safe by Default Comes at a Cost

By Don Kiely

The Web is 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’s surprising how many sites and other online resources have vulnerabilities that have been known and well understood for a long time. That’s one of the reasons why 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 been bitten in the butt by its default setting of true for validateRequest.

validateRequest is a nice feature that tells ASP.NET whether to examine all data from the browser for potentially malicious input — particularly anything that looks like HTML or scripting that form the basis for many types of attacks, such as cross-site scripting. By introducing validateRequest and setting it to true by default, Microsoft has very effectively put a halt to some of the most common Web site attacks. But with such efficiency comes some costs.

The first problem with validateRequest comes when you run an ASP.NET 1.0 application on a server with 1.1 installed. In many circumstances — painfully many — you’ll get an exception of “A potentially dangerous Request.Form value was detected from the client” when it detects unencoded input. This breaks the application, something that Microsoft strives not to do too often. In this case it is justified. If you don’t catch these kinds of attacks, your servers could be under a hacker’s control without your knowledge. Fixing the app requires that you painstakingly visit each page in your application and do whatever it takes to protect it from attack.

You have several options for eliminating the exception message, both in 1.0 apps you’re migrating and 1.1 apps you’re building now. The first option — and by far the worst choice, taken alone — is to disable validateRequest. You can do this for a single page by setting it to false in the page directive:

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

With this setting, ASP.NET won’t examine the data coming from the browser; it will simply pass it on and process it like it did in version 1.0. You can also set it to false for the entire application by including it in the pages element in the <system.web> section of your web.config file:

<system.web>

  <pages validateRequest="false" />

</system.web>

You can also change this same setting in machine.config to turn validation off for all applications on that server.

Setting validateRequest to false stops the “potentially dangerous” message, but opens your apps to attacks. If you take this step, you must take responsibility for protecting your app from attack. There are several ways to accomplish this:

• HTML encode all input from the browser. This is pretty easy to accomplish, because the Server object has HtmlEncode and HtmlDecode methods. Encode all text input because it’s quite easy to send bogus HTTP posts and gets.
• Use ASP.NET server validation controls rigorously. In particular, use the regular expression validator to prevent illegal characters wherever you can. Be careful, however, of trying to prevent only characters known to be used in attacks, such as < and >, because then you won’t be protected against new attacks.
• Don’t use only client-side validation. Again, it is far too easy to send bogus data, bypassing those client-side protections.
• Always encode tests that you display back to the user. This will help prevent cross-site scripting attacks.

Another problem with validateRequest set to true is that it is a rather broad and stupid protection, erring on the side of catching too much rather than letting something dangerous slide by. So the practical reality is that it is fine for basic apps that don’t gather much input from the browser, or perhaps for most pages in your app. But you’ll still have to get your hands dirty for more interactive pages, because you’ll want to turn it off for those pages and sanitize all input as thoroughly as possible.

Check out Microsoft’s Knowledge Base article 821343 PRB: You Receive an Error Message When You Deploy an ASP.NET 1.0 Application on a Server with ASP.NET 1.1 for more information and references. And visit the ASP.NET forums at http://www.asp.net if you have questions or comments.

Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, AK. E-mail him at mailto:donkiely@computer.org.