The protection of XSS injection

The essence of XSS injection is: a Web page in accordance with user input, do not expect to generate the executable JS code, and JS has been the implementation of the browser. This means that the string that is sent to the browser contains an illegal JS code that is related to the user's input.

Common XSS injection defenses can be addressed by simple Htmlspecialchars (escape HTML special characters), Strip_tags (Clear HTML tags), but there are some hidden XSS injections that cannot be solved by these two methods, and Sometimes business needs do not allow clear HTML tags and special characters. Here are several hidden XSS injection methods:

IE6/7 UTF7 XSS Vulnerability attack

Stealth index: 5 Damage Index: 5

This vulnerability is very covert because it makes the vulnerable page appear to be English-only letters (ASCII characters), and there are no illegal characters, and the Htmlspecialchars and strip_tags functions have no effect on this attack. However, the attack only works on IE6/IE7, and Microsoft has been fixed since IE8. You can save the following code in a text file (with no spaces and lines in front), and then try to open it with IE6 (no malicious code, just a demo):

+/v8 +adw-script+ad4-alert (document.location) +adw-/script+ad4-

The easiest thing to recruit is the application of JSONP, and the solution is to filter out all the characters that are not letters and numbers underlined. There is also a way to start the page to output space or line, so that UTF7-XSS will not work.

Because only the very old version of the ie6/ie7 caused damage, no damage to the firefox/chrome, so the damage index can only give 4 stars.

Incorrectly stitching Javascript/json Code Snippets

Stealth index: 5 Damage Index: 5

Web front-end programmers often generate some JavaScript code snippets dynamically in PHP code or some template languages, such as the most common:

var a = ' <?php echo htmlspecialchars ($name);?> ';

Do not want, $name is entered through the user, when the user input a '; Alert (1); , an illegal JavaScript code is formed, which is XSS injection.

Before we solve the problem, we have to think about what is the nature of the problem. The essence is that programmers can control the whole world with strings, but instead of generating the correct strings in the right way, they use powerful and primitive "hand string stitching".

Just change the above code to:

var a = <?php echo json_encode ($name);?>;

Remove single quotes and use PHP's Json_encode () function to generate a string representing a string. This is because it's best to use the Json_encode () function to generate all the JSON strings instead of trying to splice them yourself. Programmers always make the mistake of parsing HTTP messages themselves, rather than using ready-made, mature libraries to parse them. The benefit of using Json_encode () is that XSS injection can be avoided even if the business requires "I want to keep single quotes".

Hidden index of the highest level, hurting all the general browsers. This method of XSS injection has very important reference significance.

Finally, based on the experience of the work and the mistakes I made with myself and others, I have summed up a theorem: There is no single way to solve all XSS injection problems once and for all.

Useful experience:

Htmlspecialchars When exporting HTML code

Json_encode when you output JavaScript code

Input filtering should be used to resolve business restrictions, rather than to resolve XSS injection (contrary to Jing Jinquan principles, so this article is worth discussing)

Discuss:

The experience mentioned above 3rd is a principle of "widening and tightening out" and is inconsistent with the principle of "strict and broad". In fact, I think we should not put "Yan Jin Kuan out" as a false truth, as if except for its other statements are wrong. "Wide into strict out" and "strict into wide out" should have a completely equal status, according to the cost of implementation trade-offs.

For example, the user's name can be "strict to wide out" principle, do not allow users to fill in single quotes, greater than the number less than the number. But what about the user's signature? Can't we just fill in the quote? If you want to go to extremes, want to find a silver bullet, then I can think of all the input will be carried out htmlspecialchars and json_encode (and do not say that can not solve UTF7-XSS).

In fact, the solution to XSS injection should be related to the output end. Filtering and escaping are unnecessary when you need to output to a text file. Json_encode is not necessary when outputting to the HTML rendering engine. When the output to the JS engine, htmlspecialchars is not necessary.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Network/Security/