After ASP.Net 1.1, the ability to automatically check whether there is XSS (cross-site scripting attack) for submitting forms is introduced. When the user tries to use such input to affect the page to return the result, the ASP.Net engine will trigger an HttpRequestValidationExceptionin. By default, the page with the following text will be returned:
This is a very important security feature provided by ASP.Net. Because many programmers have no idea about security, and they don’t even know the existence of attacks like XSS, even fewer people know to take the initiative to protect them. ASP.Net is safe by default at this point. This allows programmers who don’t know much about security to still write websites with certain security protection capabilities.
However, when I Googled search for HttpRequestValidationException or A potentially dangerous Request.Form value was detected from the client, I was surprised to find that the solution given by most people was to disable it by setting validateRequest=false in the ASP.Net page description This feature is not to care whether the programmer's website really does not need this feature. I was so frightened by the sight. Security awareness should always be in the mind of every programmer. No matter how much you know about the concept of security, if an active awareness is in your mind, your site will be much safer.
Why do many programmers want to ban validateRequest? Some of them really require users to enter characters such as <>. There is no need to say this. Another part is not actually that the user allows the input of characters that easily cause XSS, but hates this form of error reporting. After all, a large paragraph of English plus a typical ASP.Net exception error message shows that this site is wrong, not the user. I entered an illegal character, but I didn't know how to prevent it from reporting an error, so I handled the error by myself.
For programmers who want to handle this error message well without using the default ASP.Net exception error message, please do not disable validateRequest=false.
The correct way is to add the Page_Error() function to your current page to catch all exceptions that occur during page processing without processing. Then give the user a legal error message. If the current page does not have Page_Error(), this exception will be sent to Global.asax's Application_Error() for processing, and you can also write a general exception error handling function there. If no exception handling function is written in both places, this default error report page will be displayed.
For example, it only takes a very short piece of code to deal with this exception. Add this code to the Code-behind page of the page:
| The following is a quoted snippet: protectedvoidPage_Error(objectsender,EventArgse) { Exceptionex=Server.GetLastError(); if(exisHttpRequestValidationException) { Response.Write (please enter a legal string.); Server.ClearError();//If ClearError() is not clearError(), this exception will continue to be passed to Application_Error(). } } |
In this way, this program can intercept the HttpRequestValidationException exception and can return a reasonable error message according to the programmer's wishes.
This code is very simple, so I hope that all friends who are not really allowed to enter characters such as users, do not ban this security feature at will. If only exception processing is required, please use code similar to the above to handle it. Can.
For programmers who explicitly ban this feature, they must understand what they are doing and must manually check the strings that must be filtered, otherwise your site will easily trigger cross-site scripting attacks.
How should pages with Rich Text Editor be handled?
If the page has controls with rich text editors, it will inevitably lead to the submission of HTML tags of class. In this case, we have to validateRequest=false. So how to deal with security? How to prevent cross-site scripting attacks to the greatest extent in this situation?
According to Microsoft's advice, we should adopt a policy called security- based, explicitly allowed policy.
First, we encode the input string with HttpUtility.HtmlEncode() and completely ban the HTML tags in it.
Then, we replace the security tags that we are interested in and are replaced by Replace(). For example, if we want to have a label, we will explicitly replace it.
The sample code is as follows:
| The following is a quoted snippet: voidsubmitBtn_Click(objectsender,EventArgse) ...{ //Encoding the input string, so that all HTML tags will be invalid. StringBuildersb=newStringBuilder( HttpUtility.HtmlEncode(htmlInputTxt.Text)); // Then we selectively allow <b> and <i> sb.Replace(<b>,<b>); sb.Replace(</b>,); sb.Replace(<i>,<i>); sb.Replace(</i>,); Response.Write(sb.ToString()); } |
In this way, we allow some HTML tags and prohibit dangerous tags.
According to the advice provided by Microsoft, we should carefully allow the following HTML tags, because these HTML tags may lead to cross-site scripting attacks.
The following is a quoted snippet:
|
Perhaps the most incomprehensible thing here is <img>. However, after reading the following code, you should understand its danger.
| The following is a quoted snippet: <imgsrc=javascript:alert('hello');> <imgsrc=java
script:alert('hello');> <imgsrc=java
script:alert('hello');> |
It is possible to cause Javascript execution through the <img> tag so that the attacker can do whatever he wants to disguise.
The same goes for <style>:
| The following is a quoted snippet: <styleTYPE=text/javascript>... alert('hello'); </style> |
| The following is a quoted snippet: 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 indicate an attempt to compensate 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>). .... |