The ASP. NET Request verification function can provide applications to me.ProgramTo prevent the website from being attacked by XSS. However, in some cases, we need to disable this function. For example, we need to use htmleditor to allow users to enter some HTML text. In this case, Asp. NET 2.0 allows us. config sets validaterequest = "false ". Or in MVC, we can set [validaterequest (false)] on the Controller or action to disable it. However, when you upgrade the site from the old version to ASP. net 4.0, you will find that even if you do this, you will still be prompted for such an exception "a potentially dangerous request. form value was detected from the client ". How can we solve this problem?
In the previous ASP. NET versions, request verification is enabled by default, but it is only valid for page requests (request. ASPX page), and is only verified when the page is requested. However, in ASP. in. Net 4.0, the request verification function is advanced to ihttphandler. before the beginrequest method is requested, this means that all access to ASP. all HTTP requests of the. NET Request channel will be verified for the validity of the request content, including some custom httphandler and WebService requests, you can even use the custom HTTP module to customize the request processing program.
The early result of request verification processing is that we set validaterequest = false in the page or controller, which will invalidate and will not prevent the program from verifying the request input. After this is done, the validators cannot obtain whether the requested page has disabled the authentication request because httphandler has not yet been instantiated. In addition, ASP. net4.0 does not provide me with a place to disable this authentication function. However, for compatibility considerations, ASP. NET allows us to configure the request verification behavior using ASP. NET 2.0 in Web. config:
Disabling or disabling request verification is not very convenient for programmers. In consideration of security and program availability, a compromise may be caused by writing a verification processor to filter out HTML tags that we don't want to see, rather than "<>. Because an important tag of XSS is <SCRIPT>, We can filter <SCRIPT> by writing a custom verification, illegal input is reported only when the user submits this label. The following is an example of the source code.:
The preceding section may cause ambiguity about how to prevent XSS attacks. BelowCodeIt is only used to demonstrate how developers can write custom request input validators and decide which data to request based on their own needs:
Code
Using System;
Using System. Collections. Generic;
Using System. LINQ;
Using System. Web;
Using System. Web. util;
Namespace Globals
{
/// <Summary>
/// Summary Description for customrequestvalidation
/// </Summary>
Public Class Customrequestvalidation: requestvalidator
{
Public Customrequestvalidation (){}
Protected Override Bool Isvalidrequeststring (httpcontext context, String Value, requestvalidationsource, String Collectionkey, Out Int Validationfailureindex)
{
// Block SCRIPT tags
VaR idx = Value. tolower (). indexof ( " <Script " );
If (Idx > - 1 )
{
Validationfailureindex = Idx;
Return False ;
}
Else
{
Validationfailureindex = 0 ;
Return True ;
}
}
}
}
In this case, we add this configuration in Web. config to allow the system to use our custom validators for verification:<Httpruntime requestvalidationtype = "globals. customrequestvalidation"/>.
Resources related to this issue:
Http://jefferytay.wordpress.com/2010/04/15/asp-net-4-breaking-changes-1-requestvalidationmode-cause-validaterequestfalse-to-fail/