Html injection is a serious security problem – it’s so serious Microsoft has decided it’s better to crush a web site that may potentially be attacked (even unsuccessfully) than to let it proceed – this is like executing someone on the spot because you suspect someone else may be planning to rob him.
So, what is HTML injection?
Web pages are basically text with embedded formatting instructions, for example if I wand to show the word bold in a bold font the web page will contain the text <b>bold</b> where <b> is the instruction to turn bold on and </b> is the instruction to turn it off again.
Because it’s all just text the web browser can’t tell if I wanted to say “turn on bold” or “less-than b grater-than” (maybe I’m writing about math) so everything that is enclosed in angle brackets is considered a command, if I want to show the less-than sign I have to write a special “show less-than” instruction, the text for it is < all the show-something instructions begin with an ampersand and don’t contain angle brackets.
The process of taking text and replacing all the could-be-mistaken-for-instruction characters and with just-show-the-character instruction is called encoding.
If, in my web application, I let a user type something into a box and that user types something that contains valid instructions and then I show it on a page without encoding it first the browser will consider it an instruction and will do whatever that instruction tells it to do.
This is relatively harmless when we talk about turning bold on and off – but there are instructions that tell the browser to do things, for example change whatever is shown on the current page, send data to the server, open a popup window or navigate to another page.
So, if we had a bank web site that includes instant messaging functionality and the content of the messages are not properly encoded I could write a message that when you view it – without you doing anything – will cause the browser to silently tell the bank to transfer your money to my account (and this will come from your browser and will look to the bank like you requested it).
This is a really serious security problem, it’s also hard to solve because the minute you let users type in the less-than sign into your application it only take one place you forgot to encode to open a vulnerability.
Microsoft, being very security minded, decided that they will solve it and took the only option available to them – don’t let anyone type less-than into web forms – and because they can’t just send people to remove the less-than key from every keyboard on earth they simply crush any ASP.net web app that is unlikely enough to be on the receiving end of a less-than sign.
When ever someone types something that looks like it could be an HTML injection attack ASP.net will crush with the following exception:
System.Web.HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected from the client
(this should have been called System.Web.WeThinkItsBetterToCrushYourAppThanToTrustYouException)
So, how do we stop this guard who is protecting us by pointing a gun to our head so he can kill us before anyone does something bad to us?
In .net 2 and up to .net 3.5 you just have to open your web.config file and add
validateRequest="false" to your pages element (inside
In .net 4 Microsoft changed request validation to be more aggressive and to turn it off you first have to tell it to work like it did in .net 2 first by adding
<httpRuntime requestValidationMode="2.0" /> to your web config (also inside
In MVC 3 Microsoft added yet another layer of “protection” and you also have to add the
[ValidateInput(false)] on action methods and
[AllowHtml] on model properties.
And who knows how they will add more validation in the next version, I suggest calling the magic configuration setting to turn it off PleaseDontCrushMyProgram
posted @ Wednesday, February 15, 2012 1:36 PM