Please be careful with ASP.net's validaterequest= "false"

Asp.net|request

ASP.net 1.1 introduces the ability to automatically check the submission form for XSS (Cross-site scripting attacks). When the user tries to influence the page return result with such input, ASP. NET engine will cause a httprequestvalidationexceptioin. A page with the following text is returned by default:

Server Error in '/yourapplicationpath ' Application

A Potentially dangerous Request.Form value is 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 could indicate an attempt to compromise the security of your application, such as a cross-site scripting. 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 the check all explicitly in the this case.

Exception details:system.web.httprequestvalidationexception:a potentially dangerous Request.Form value was detected From the client (txtname= "<b>").

....

This is a very important security feature provided by ASP.net. Because many programmers have no concept of security, even do not know the existence of XSS attack, know the initiative to protect less. Asp. NET to do the default security on this point. This allows programmers who are not very knowledgeable about security to write websites that have a certain amount of security protection.

But when I google search httprequestvalidationexception or "A potentially dangerous Request.Form value is detected from th E-Client ", it is surprising to find that most people give the solution is in the ASP.net page description by setting Validaterequest=false To disable this feature, and not to care about whether the programmer's website really does not need this feature. That's what I call a scared, scary-looking. Security awareness should always be in every programmer's heart, no matter how much you know about the concept of security, an active awareness in the brain, your site will be much safer.

Why do a lot of programmers want to ban validaterequest? Part of it is really the need for users to enter characters such as "<>". There's no need to say that. Another part of it is not that users are allowed to enter characters that are prone to XSS, but rather hate the way the error is generated, After all, a large paragraph of English plus a asp.net typical abnormal error message, it appears that the site error, rather than the user entered the illegal characters, but they do not know how to not let it error, their own to deal with the error.

For those of you who wish to handle this error message well without using the default ASP.net exception error message, you should not disable Validaterequest=false.

The right thing to do is to add the Page_Error () function on your current page to capture exceptions that occur during all page processing without processing. Then give the user a legitimate error message. If the current page does not have Page_Error (), the exception will be sent to Global.asax's Application_Error (), where you can write a generic exception-handling function. This default error page is displayed if two places do not have a write exception handler function.

For example, it is enough to deal with this exception in a very short piece of code. Add this piece of code to the Code-behind page of the page:

protected void Page_Error (object sender, EventArgs e)
{
Exception ex = Server.GetLastError ();
If (ex is httprequestvalidationexception)
{
Response.Write ("Please enter a valid string.) ");
Server.ClearError (); If not ClearError () This anomaly will continue to be transmitted to Application_Error ().
}
}

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 not really want to allow users to enter characters such as friends, do not arbitrarily prohibit this security features , if only the need for exception handling, then use similar to the above code to handle it.

　　For those programmers who explicitly prohibit this feature, they must understand what they are doing, and they must manually check the string that must be filtered, or your site will easily trigger a cross-site scripting attack.

　　What should you do with a page with rich-Text editor?

If the page has a rich Text editor control, it will inevitably cause a class of HTML tags to be submitted back. In this case, we have to validaterequest= "false". So how does security work? How do you maximize the prevention of Cross-site scripting attacks in this situation?

According to Microsoft's proposal, we should take a policy that is known as " default prohibition, explicit permission ".

First, we encode the input string with Httputility.htmlencode () to completely prohibit the HTML tags.

We then replace it with a security label that we are interested in and is replaced by replace (). For example, we want to have "" tag, then we will "" Replace the "" explicitly.

The sample code is as follows:

void SubmitBtn_Click (object sender, EventArgs e)
... {
Encodes the input string so that all HTML tags are invalidated.
StringBuilder sb = new StringBuilder (
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 ());
}

This allows us to allow a portion of the HTML tag, but also to prohibit the dangerous label.

According to Microsoft's suggestions, we should carefully allow the following HTML tags, because these HTML tags are likely to lead to cross-site scripting attacks.

<applet>

<body >

<embed>

<frame>

<script>

<frameset>

<HTML>

<iframe>

<img>

<style>

<layer>

<link>

<Ilayer>

<meta>

<object>

Perhaps the most incomprehensible thing here is . However, after looking at the following code, you should understand its danger.

The tag is likely to cause JavaScript to execute, so the attacker can do anything he wants to disguise.

The same is true for <style>:

<style type= "Text/javascript" ....
Alert (' Hello ');
</style>