The client detects potentially dangerous Request. Form values.

During asp.net development,The client detects potentially dangerous Request. Form values."Error message, many people provide the following solutions:

1. Add the following sentence to the web. config document <system. web>: <pages validaterequest = "false"/>
Example:
<? Xml version = "1.0" encoding = "gb2312"?>
<Configuration>
<System. web>
<Pages validaterequest = "false"/>
</System. web>
</Configuration>

2. Add validaterequest = "false" to the page in the *. aspx document header. For example:
<% @ Page validaterequest = "false" language = "c #" codebehind = "index. aspx. cs" autoeventwireup = "false" inherits = "mybbs. webform1" %>
 

In fact, this is not correct, and it will bring security risks to the program.

ASP. Net 1.1 introduces the ability to automatically check the existence of XSS (Cross-Site Scripting) for submitted forms. When a user tries to use an input like this to affect the page return results, the ASP. Net engine will trigger an httprequestvalidationtiotioin. This is an important security feature provided by ASP. Net. Because many programmers do not have the concept of security, and even do not know the existence of XSS attacks, there will be fewer active protection. ASP. Net provides default security. In this way, programmers who are not familiar with security can still write websites with certain security protection capabilities.

However, when I search for HttpRequestValidationException or "A potentially dangerous Request. when Form value was detected from the client ", I was surprised to find that the solution provided by most people was in ASP. in the Net page description, this feature is disabled by setting validateRequest = false, instead of worrying about whether the programmer's website really does not need this feature. I am so scared. Security awareness should always be in the hearts of every programmer. No matter how much you know about the concept of security, your site will be much safer with an active consciousness in your mind.

Why do many programmers want to disable validateRequest? Some of them really need to be characters such as "<>. This is unnecessary. The other part is not that users are allowed to enter characters that may easily cause XSS, but hate this form of error reporting. After all, an ASP is added to a large part of English. net typical Exception error message, it seems that this site has an error, rather than the user entered an invalid character, but they do not know how to prevent it from reporting an error and handle the error by themselves.

Do not disable validateRequest = false for programmers who wish to handle this error message well without using the default ASP. Net exception message.

The correct method is to add the Page_Error () function on your current page to capture exceptions that occur while processing all pages without handling them. Then, the user is given a valid error message. If the current page does not contain Page_Error (), this exception will be sent to Application_Error () of Global. asax for processing. You can also write a common exception reporting and error handling function there. If no exception handling function is written in both locations, the default error page is displayed.

For example, it takes only a short piece of code to handle this exception. Add the following Code to the Code-behind page:

Protectedvoid Page_Error (object sender, EventArgs e)
{
Exception ex = Server. GetLastError ();
If (HttpContext. Current. Server. GetLastError () is HttpRequestValidationException)
{
HttpContext. current. response. write ("enter a valid string [<a href = \" javascript: history. back (0); \ "> return </a> ]");
HttpContext. Current. Server. ClearError ();
}
}

In this way, the program can intercept the HttpRequestValidationException and return a reasonable error message as the programmer wishes.

This code is very simple, so I hope that all friends who do not really want to allow user input and other characters should not prohibit this security feature at will. If you only need to handle exceptions, use the code similar to the above to process it.

For programmers who explicitly prohibit this feature, they must understand what they are doing and manually check the strings that must be filtered, otherwise, your website is prone to cross-site scripting attacks.

　　What should I do with pages with Rich Text Editor?

If the page has rich text editor controls, the HTML tags of the classes will inevitably be submitted back. In this case, we have to set validateRequest = "false ". So how to deal with security? In this case, how can we prevent cross-site scripting attacks to the maximum extent?

According to Microsoft's suggestion, we should adopt the"Disabled by default, explicitly allowed.

First, we encode the input string with HttpUtility. HtmlEncode (), and completely disable the HTML Tag.

Then we Replace the security tags that we are interested in with Replace. For example, if we want a "tag", we will explicitly replace it "".

Void submitBtn_Click (object sender, EventArgs e)
{
// Encode the input string so that all HTML tags are invalid.
StringBuilder sb = new StringBuilder (HttpUtility. HtmlEncode (htmlInputTxt. Text ));
// Then we can selectively allow <B> and <I>
Sb. Replace ("& lt; B & gt;", "<B> ");
Sb. Replace ("& lt;/B & gt;", "</B> ");
Sb. Replace ("& lt; I & gt;", "<I> ");
Sb. Replace ("& lt;/I & gt;", "</I> ");
Response. Write (sb. ToString ());
}

In this way, some HTML tags and dangerous tags are allowed.

According to Microsoft's suggestions, we should be careful to allow the following HTML tags, because these HTML tags may cause cross-site scripting attacks.

<Applet>
<Body>
<Embed>
<Frame>
<Script>
<Frameset>
<Html>
<Iframe>

<Style>
<Layer>
<Link>
<Ilayer>
<Meta>
<Object>

is the most incomprehensible. However, after reading the following code, you should understand the risks.