Solutions to freetextbox and FCKeditor security issue warnings

Solutions to security issues warning when using freetextbox and FCKeditor in ASP. NET 4.0

 

Problem

The problem is that when freetextbox 3.2.2 is used in vs2010 to assist in sending the body content of the email, the system prompts the following error:

A potentially dangerous request. Form. value was detected from the client (freetextbox1 = " 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 compromiseSecurityOf your application, such as a cross-site scripting attack. to allow pages to override application request validation settings, set the requestvalidationmode attribute in the httpruntime configuration section to requestvalidationmode = "2.0 ". example: Exception details:System. Web. httprequestvalidationexception: a potentially dangerous request. Form. value was detected from the client (freetextbox1 = "

The reason is as shown above: In the subject content of the email (that is, in the rich text box above, enter the test text "bbtest1" with the style H1 ".

Cause Analysis and Solution

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. That is to say, when a page request contains a string such as HTML or Javascript. ASP. NET considers it a dangerous value and throws a resignation exception. This exception occurs when the WYSIWYG editor (for example, the FCKeditor or freetextbox control) is used on the page. The following three solutions are available in ASP. NET 2.0 or ASP. NET 3.5 environments.

Solution 1

Add <% PAGE validaterequest = "false" %> to the page.

Solution 2

ModifyWebThe <pages> label of the. config configuration file. <Pages validaterequest = "false">... </pages>. This method removes all page verification functions, so this method is not recommended.

Solution 3

Capture exceptions so that you can define the exception prompts by yourself.

ASP. NET 4.0 request verification mode changed

 

The ASP. NET Request verification function provides application security assurance to 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.

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: