Validaterequest = "false" attribute and XSS attack

Validaterequest = "false" indicates whether to submit invalid characters on the IIS verification page, such as >,<. When we need to obtain HTML code in a certain format and insert it into the database, set this attribute to false, for example, when you perform operations such as font thickening.
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

In this regard, the default security is achieved. In this way, programmers who are not familiar with security can still write websites with certain security protection capabilities.

However, when I search for httprequestvalidationexception or "a potentially dangerous request. form value was detected from the client" on Google

I was surprised to find that the solution provided by most people was to disable this feature by setting validaterequest = false in the ASP. NET page description, instead of caring about the programmer's network.

Does the website really 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, an active consciousness in

In your mind, your site will be much safer.

Why do many programmers want to disable validaterequest? Some of them really need to be characters such as "<>. This is unnecessary. Another part is not allowed by the user.

The characters that are easy to cause XSS hate this form of error. After all, a typical ASP. NET error message is added to a large part of English, which indicates that the site has failed, rather than the user entered an invalid

Character, but you do not know how to prevent it from reporting errors.

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, the user is given a valid error message. If the current

There is no page_error () on the page. 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 there. If there are no

The default error page is displayed only when the exception handling function is written.
For example, it takes only a short piece of code to handle this exception. Add the following code to the code-behind page:

The following is a reference clip:
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 ().
}
}

Note:

1. What is XSS attack?

XSS, also known as CSS (Cross Site Script), is a cross-site scripting attack. Attackers insert malicious HTML code into a web page. When a user browses this page

HTML code is executed to achieve the Special Purpose of malicious users. XSS is a passive attack, because it is passive and not easy to use, so many people often call it harmful. This article focuses on the use

XSS obtains the shell of the target server. Although the technology is old, its ideas hope to help everyone.

How to find XSS vulnerabilities

Personally, XSS attacks are divided into two types: internal attacks, which mainly refer to the use of program vulnerabilities to construct cross-site statements, such as showerror of dvbbs. cross-Site ASP

Vulnerability. The other type is from external attacks. It mainly refers to constructing XSS Cross-Site vulnerability webpages or searching for webpages with cross-site vulnerabilities other than the target machines. For example, if we want to penetrate a website

A web page with cross-site vulnerabilities has been constructed, and cross-site statements have been constructed. By combining other technologies, such as social engineering, the administrator of the target server has been deceived to open the web page.

How to Use

In traditional cross-site exploitation methods, attackers usually construct a cross-site webpage, and then put a cookie-collecting page in another space, then, combine other technologies to enable users to access cross-site pages to steal

User cookies for further attacks. I personally think this method is too backward, and you may know the disadvantages, because even if you collect cookies, you may not be able to penetrate further.

The passwords in the number of cookies are encrypted. If you want Cookie spoofing, you must be subject to other conditions. The other idea proposed in this article solves the above problems to a certain extent.

. For individuals, a mature method is to construct a form through cross-site, and the content of the form is to obtain a high permission by using the backup function of the program or adding the administrator. Below I will detail

This technology is introduced in detail.