KeepItLocked.net

ASP.NET ValidateRequest is a security mechanism designed to prevent cross-site scripting attacks in ASP.NET applications. It looks at data in the HTTP request parameters, and issues an error if it finds anything that is "suspicious". And, for the most part, it works fine. But, like many security technologies, there are two big problems - false positives and false negatives. First off, let's take a look at how ValidateRequest works. Using the .NET Reflector tool, we can see the attack detection algorithm in the IsDangerousString method of the CrossSiteScriptingValidation class, which is the crux of the ValidateRequest functionality:

This method looks for either a less than or ampersand character in the string. If one exists, it first checks to make sure it is not the last character (I'm not entirely sure why, but it seems this would only allow fairly benign strings). Then, if the offending character is a less than character, the method checks if the next character is a letter, an exclamation point, or a forward slash. If so, it is considered dangerous. Also, if the offending character was an ampersand, and the next character is a hash mark, the string is considered dangerous. This algorithm iterates through the string, stopping at each instance of one of these symbols.

Now that we have a good idea how this functionality works, let's examine why it isn't always ideal.

False Positives

ValidateRequest looks for anything that resembles HTML that code be used to execute script. Unfortunately, the detection technique can be a bit trigger-happy. Some strings that appear to be malicious are perfectly normal and expected. Examples:

1. Rich text controls often use HTML characters for markup.
2. XML in AJAX calls has been known to trip the ValidateRequest error.

Many people advise turning ValidateRequest off at the first sign of problems. The first Google hit for ValidateRequest is a link to an article from 2004 titled "Surviving ValidateRequest" discussing why it's not always in a developer's best interest to use the mechanism (although it does discuss the threats and countermeasures regarding cross-site scripting in the article as well). Here's a quote:

"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."

OK, fair enough, simply disable ValidateRequest when it causes problems, and figure out how to prevent XSS by yourself in those cases. But something so strict that it chokes on regular input has got to prevent all bad input, right?

False Negatives

No one claims that ValidateRequest is perfectly effective in stopping cross-site scripting attacks. But what does it miss? From a recent blog post:

"ValidateRequest may miss some crafty inputs."

Well, what are these "crafty" values? One is mentioned in the article - an exploit which is mentioned in the Microsoft Security Bulletin MS07-040.

There is another, perhaps more common (and still unpatched) form of XSS which isn't stopped by ValidateRequest. It is known as HTML Attribute-Based Cross Site Scripting, according to Jeremiah Grossman. The attacker uses an HTML attribute to insert an event handler that causes a script to run.

ValidateRequest doesn't even attempt to look for this - there are no angle brackets required.

For example, take the following ASP.NET code:

This code is used to display a page which renders a link to an article on Wikipedia.

We can enter this value:

This will cause the following HTML to be rendered:

This will cause script to execute when the person moves their mouse over the link:

So we have caused cross-site scripting in spite of ValidateRequest being enabled. This is due to the fact that not all cross-site scripting attacks require the use of less than or ampersand characters. For example, consider what would happen if a parameter value was echoed directly in JavaScript (this can happen in AJAX apps). The results can be scary!

ValidateRequest is not a panacea. Instead, consider augmenting the functionality with stronger protection afforded by the Anti XSS library, and as always, implement and enforce strict validation.

In ASP.NET 2.0, the Protected Configuration functionality can be used to automatically encrypt and decrypt sections of the Web.config file. This is useful for keeping sensitive data like connection strings and cryptographic keys secret from internal personnel who require access to other areas of the configuration file.

Web.config files contain application level configuration, and they are often deployed with the code, from development/testing/staging environments to production environments. Because secrets like connection string should be different in production, the Web.config file has to be modified. However, another piece of functionality, the configSource attribute or the appSettings element, allows configuration sections in Web.config to be located in external files.

These two functionalities work just fine together. This makes deployment easier because secrets can be stored statically and encrypted on each machine, or just the production machine, plus the Web.config file doesn't need to be modified each time.

Example

connectionStrings section in Web.config (staging and production) refers to external source

Staging connection string defined in connectionString.config (staging)

Production connection string defined in connectionString.config (production)

Encrypt the connectionStrings section for the application (production) using aspnet_regiis

Encrypted connectionStrings setting connectionStrings.config (production)

Now, the Web.config file can be deployed without overwriting the connectionStrings attribute, and the production database password is encrypted! It's the best of both worlds - security and convenience playing nicely. Just remember not to deploy the connectionString.config file.

A vast amount of server-side development is J2EE. Huge, multi-national corporations run on it exclusively. But, it wasn't always that way….

Back in the early days of Java, the client-side Applet was king. The partnership with Netscape thrust the Java onto the world stage. Early press releases all focused on the web experience provided by Applets.

But there was this pesky security issue - due to the fact that Java Applets are distributed and run through a browser, they can encounter some nasty code on the web. In order to deal with evil code, Applets are run in a Sandbox with limited permission. However, Applet developers said that this Sandbox was too restrictive. No access to the file system, or the clipboard, or native code, or really anything useful.

So, in Java 1.1, you could digitally sign applets so that they were trusted. This would give the Applet full permission, and theoretically users would manage their own trusted key store.

In Java 2, Sun added Certificate Authorities to the Applet specification, so that anyone with enough money to pony up could create a universally trusted Applet. This was tempered by the fact that now the user could create a policy to restrict these signed Applets to a specific set of permissions. So signed Applets ask for permission to run, and are granted AllPermissions, unless there is a specific client-side policy for that Applet, which takes precedence. But no one likes configuring security policies, do they? Remember, this is the unwashed masses of browser users, and they don't know a Java policy file from a can of Shinola.

Enter the Java Plugin, which now handles Applets for most browsers. In the previous 1.3 version of the Plugin, Applets signed with invalid certificates (self-signed or expired) would simply fail to load. If the signing certificate was valid, the user got a dialog box asking whether to run the Applet.

In the Java Plugin 1.4, the behavior was changed to load Applets even with invalid certificates. The only difference between Applets with valid signatures and invalid signatures is the warning messages.

Applets signed with an invalid certificate:

Applets signed with a valid certificate:

To me, this represents a tremendous over-simplification. Signed Applets now basically use the same, all-or-nothing security model as standard executables!

The error message for an unsigned .exe file (in IE7):

At least this has a red shield (bad) rather than an orange shield (maybe bad)!

Nowadays, in addition to the huge amount of server-side Java development, there is Java on mobile devices, smart cards, and entire operating systems in Java. But the original thing that made Java tick – the Applet – is becoming less and less relevant every day, and I can't help thinking it's due to the fatally flawed security model which has now almost completely lost its teeth.

References

Java Technology: The Early Years: http://java.sun.com/features/1998/05/birthday.html

Java 2 Platform Security: http://www.informit.com/articles/article.aspx?p=433382&seqNum=2

Using JDK 1.1 Signed Applets with Java Plugin: http://java.sun.com/products/plugin/1.2/docs/signed.html

Java Security, Evolution and Concepts: http://java.sun.com/products/plugin/1.2/docs/signed.html

Reading articles, browsing marketing materials, and listening to presentations about application security, you hear variations on a theme:

"Input validation is absolutely critical to application security, and most application risks involve tainted input at some level." – OWASP

While I don't think authors overstate the importance of problems stemming from invalid data, I have noticed these discussions gloss over two key points.

1. Input validation is only part of the problem. Output validation is important as well.
2. Validation (in the general sense) has two distinct concerns: validation and sanitization.

Input validation is only part of the problem. Output validation is important as well.

All data input from an untrusted source should be validated. If you enter a blog comment, I want to make sure it isn't empty, it is less than 500 words, and it isn't spam and won't get my readers RickRolled. However, as that data is output from the web application, it should be validated as well. Here's why:

Think about cross-site scripting – we really want to prevent tainted data from exiting the system to the rendered web page on the client. This occurs when the data is output, not input. SQL injection is also tainted data exiting the system (through a SQL query) and parameterized queries are output validation. And since these different validation rules might process the same data (say, a blog comment that is reflected in a subsequent page for approval and then stored to the database), it makes more sense to validate the data upon exit, rather than on entrance.

It's like international air travel – you pass through customs at your arrival airport (output), because at your departure airport (input), they don't know the rules for what's allowed and what isn't.

Thus, I propose that "Data Validation" be used in favor of "Input Validation" as a more accurate (although less precise) term to include input and output validation.

Validation (in the general sense) has two distinct concerns: validation and sanitization.

Validation is a Boolean operation which gives a yes or no answer to the question "Is this data acceptable in the current context?"

Sanitization (which includes encoding, escaping, and stripping) refers to transforming data in some manner so as to make it acceptable in the current context.

These two approaches can be used independently or in concert and the correct way to perform these operations from a security perspective is highly dependent on the context in which they are used.

So validation is (usually) both validation and sanitization.

Another issue which might be brought up in the subject of validation is canonicalization, which is a separate issue that warrants its own future blog post.

Just some food for thought when designing validation mechanisms – it's not all yes or no decisions, and it's not all at the front door.