Use page_error () to handle non-disabled validaterequest = false [from network]

Enter text here

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. By default, the following text page is returned:

The following is a reference clip: Server Error in ''/yourapplicationpath'' Application A potentially dangerous request. form value was detected from the client (Txtname = "<B> "). Description: Request validation has detected a potentially dangerous client input value, and processing of the request has been aborted. this value may be indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. you can disable request validation by setting validaterequest = false in the page directive or in the configuration section. however, it is strongly recommended that your application explicitly check all inputs in this case. Exception details: system. Web. httprequestvalidationexception: a potentially dangerous request. form value was detected from the client (txtname = "<B> "). ....

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 searchHttprequestvalidationexceptionOr "a potentially dangerous request. form value was detected from the client", I was surprised to find that the solution provided by most people turned out to be in the ASP. NET page description by settingValidaterequest = falseTo disable this feature, without 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, you can receive 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 in it. 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:

Protected void page_error (Object sender, eventargs E) { Exception EX = server. getlasterror (); If (ex is httprequestvalidationexception) { Response. Write ("enter a valid string. "); Server. clearerror (); // if the error is not clearerror (), it will continue to be passed to application_error (). } }

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

The sample code is as follows:

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 ;",""); SB. Replace ("& lt; I & gt;", "<I> "); SB. Replace ("& lt;/I & gt ;",""); 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.

The following is a reference clip:

Script: Alert ('hello'); ">

Script: Alert ('hello'); ">

The label may cause JavaScript Execution, so that attackers can do anything they want to disguise.

The same is true for <style>:

The following is a reference clip:

<Style type = "text/JavaScript">...

Alert ('hello ');

</Style>