Showing posts with label ASP. Show all posts
Showing posts with label ASP. Show all posts

Wednesday, May 4, 2011

ASP.NET 4.0, MVC and request validation

By Alejandro Villarreal

If you’ve ever dealt with the front-end part of application development in ASP.NET, you might have encountered the following error at some point:

A potentially dangerous Request.QueryString value was detected from the client

This happens when the user submits a value (either in a form or in the query string) that the ASP.NET Framework considers dangerous, in the sense that it might be an HTML/script injection attack.

Sometimes it is necessary to turn that feature off (see here and here on how to do it). It might be the case that you expect the user to provide valid XML/HTML, and thus you don’t want the Framework to abort the request with an Exception. As explained in the links I mentioned before, this can be done by disabling this validation completely in the Web.Config file or on a per-page basis (when working with WebForms), or disabling it for a controller or specific controller actions (when working with MVC).

Since I’m currently working on an application that uses the MVC Framework, this post focuses on the problem I had while trying to disable request validation for specific controller actions.

According to this post by Stephen Walther (and several others), the only thing you need to do is to add the ValidateInput attribute to your ActionMethod, like this:

[ValidateInput(false)]
public ActionResult MyActionMethod(string myParameter)
{
// Method implementation goes here...
}

Seems simple enough… but it just wouldn’t work for me! I kept receiving the “potentially dangerous” error when making a request to the URL that triggered “MyActionMethod”, when “myParameter” included an HTML tag. The method wasn’t even being activated.

After a bit of research I stumbled upon this post, which had the solution. The key was this:

So the MVC team gave us the [ValidateInput(false)] attribute to disable this annoying feature. But just setting it on an action will also fail, you still have to set one more setting at the web.config for this to work (if you are working with asp.net 4)

Oh, I am working with ASP.NET 4! So I had to add this to my Web.Config file:


...

...

As explained in the article (and originally in this whitepaper that explains the breaking changes in ASP.NET 4), previous versions of the Framework only performed request validation for ASP.NET pages (.aspx files and their class files), while version 4 performs it for all requests, before their BeginRequest phase. In my particular scenario, this means that the attributes in the controller don’t even have a chance to act, since the Framework has already decided that the request will be aborted. And that’s why reverting the validation behavior to that in version 2.0 of the Framework (through that additional line in the config file) makes everything work as expected again.

This made me think on how is it that we can prevent request validation on MVC-based applications developed under Framework 4.0 without resorting to that behavior, but couldn’t find any documentation on it. Hopefully Microsoft did think about this and we’ll soon start seeing solutions to that problem…

Asp.net 4.0: To allow capture of html tags inside a textbox

By David E.

On rare occasions inside our web application it is necessary to allow the user to enter some content in html format. In previous versions this was possible, and it was the responsibility of the programmer to validate those labels to prevent a user from entering malicious code to our application.

With ASP.net 4.0 the information will now be validated automatically. If a user tries to add html tags to a web application, the result will be an exception. This validation feature can be disabled with a simple statement of the web.config file.

The first thing to do in Visual Studio 2010 is to create a new web application, then we can add a new web form and then create the basic controls that capture html tags and a button that causes a postback from the site.

<asp:TextBox ID="txtComments" runat="server" Rows="4" TextMode="MultiLine" ClientIDMode="Static" Width="400px">asp:TextBox>

<asp:Button ID="btnInsertScript" runat="server" Text="Insert Inline"

onclick="btnInsertScript_Click" />

On the CodeBehind of our page we can see that the html is actually captured and properly painted.

htmlCode = HttpUtility.HtmlEncode(txtComments.Text);

Response.Write(this.txtComments.Text);

When running the application and capturing the HTML within that textbox (and because even change the validation mode in the web config) we get the following exception.

1

It is important to note that this exception occurs inside the HttpRequest, ie., even if our code is prepared to handle exceptions with a try catch, this error occurs before executing any code of our site, including the Load. If you want to handle this exception in a custom way, you need to do it inside the Global.asax.cs file with the Application_Error method.

void Application_Error(object sender, EventArgs e)

{

// Code that runs when an unhandled error occurs

Response.Redirect("ErrorPage.htm");

}

This method of exception handling will control any exception that is not properly handled in the application.


If we want this automatic validation to be disabled to allow html input in our textbox, you need to add the following tag within node in the Web.config file:

<httpRuntime requestValidationMode="2.0" />

This will disable the validation and allow the capture of html:

2

Important note: This is a way to allow the user to enter html tags inside our application. However, you should never rely on any text captured by a user, it may contain malicious code that could cause failures in our application. It is best that when you are returning a captured text to the user interface, always use the HtmlEncode method:

HttpUtility.HtmlEncode(txtComments.Text);

In this way all html tags will be fully rendered on the screen and not interpreted by the browser. If you want to display the html that the user enters, it is best to use specific controls for this edition, or adequately control the code in which the HTML will be injected.