5

I'm using FreeTextBox HTML editor in some webforms in my asp.net project . if I do not set ValidateRequest property to false I get this error :

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

It's OK in admin folder though , Because only authorized users have access to work with it . But how about public pages like sections where every users have access to leave comments(using FreeTextBox for collecting users comment ) ? Isn't risky for XSS Attack ? If the answer is not Yes , So what's ValidateRequest property for ?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Mostafa
  • 3,002
  • 10
  • 52
  • 79

4 Answers4

7

Nope you are correct this is potentially dangerous. The idea behind it is that .net doesn't want to restrict what can be done with it's controls, but at the same time remove many of the possibilities for a security hole. The ValidateRequest property is there so you can tell ASP.NET, "Hey don't worry about this. I'm going to validate it myself, because I expect something that may look dangerous to you."

It's set to validate responses by default, because not validating potential xss attacks is dangerous, and it's better to get a validation error that you didn't realize than have your site hacked.

kemiller2002
  • 113,795
  • 27
  • 197
  • 251
  • I use HttpUtility.HtmlEncode() , Is it enough for validation ? – Mostafa Nov 02 '10 at 08:32
  • @Mostafa: Using `HtmlEncode` is enough to protect against XSS, but there may be other places where you have to make sure that the data is encoded correctly, for example if you store it in a database. – Guffa Nov 02 '10 at 09:05
  • 1
    @Mostafa: Download and use the MS AntiXSS Library, its implementation is the same as using Server.HtmlEncode, but its charachter library it uses to scrub against is much larger and better to use. – ewitkows Nov 02 '10 at 20:44
3

Yes, it's OK to disable the request validation.

The request validation catches the most common characters and phrases used in XSS attacks and similar, but it can not catch every possible way of doing an exploit. So, while the request validation offers protection from most exploits, you are never completely protected by it, you still have to treat all input as potentially evil.

The first purpose of the request validation is to protect applications that are built by people who are clueless about XSS attacks and similar, so that they are not completely unprotected. If you know how to treat input correctly, and also manage to implement that correctly, the request validation is not needed.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • As a developer, theres always a reason for\against something. At the end of the day, you have to remember the principle "defense in depth". As @Guffa states, Request Validation helps, but thats not all of it. IE8 and other browsers tend to help with stripping out XSS, but as long as you follow the basic patterns of not trusting any input.. thats the most important thing. – ewitkows Nov 02 '10 at 20:47
1

FreeTexBox control and "A potentially dangerous Request.Form value was detected from the client"

You can try another decision

 if(!this.Page.ClientScript.IsOnSubmitStatementRegistered("Replace"))
{
 string script = @"if (Page_IsValid){FTB_API['" + txtBox.ClientID + @"'].initialized=false;   FTB_API['"  + txtBox.ClientID + @"'].htmlEditor.value=FTB_FreeTextBox.prototype.HtmlEncode( FTB_API['" + txtBox.ClientID + @"'].htmlEditor.value);}";
 this.Page.ClientScript.RegisterOnSubmitStatement(this.Page.GetType(), "Replace", script);
}

and don't forget to replace symbols when you send string from server to the client application

if(!String.IsNullOrEmpty(yourstring)) txtBox.Text= yourstring.Replace("&gt;", ">").Replace("&lt;", "<").Replace("&amp;", "&").Replace("&quot;", ('"').ToString()).Replace("&#146;", "'");

In this case you don't need turn off ValidateRequest. You can also replace characters before you save a string in database.

Boriss Pavlovs
  • 1,441
  • 12
  • 8
1

Have a look at ValidateRequest on MSDN. This tells you that input is scanned for potentially dangerous content. This is all good and fine if you only ever use input fields and the like for plaintext. The problem starts once you want your user to provide eg. a link to some other page, or start keeping extra data (in eg. XML form) in hidden input fields. ValidateRequest will not tolerate this kind of content. ValidateRequest is a sort of nice feature that I nearly always end up disabling, but disabling it does mean that you need to do some validation on your input yourself. In my opinion, you should always validate input yourself anyhow.

LaustN
  • 722
  • 3
  • 7