Protection against several extremely concealed XSS injections

Essence of XSS InjectionThat is, an executable js Code is generated on a webpage based on user input, and the JavaScript code is executed by the browser. the string sent to the Browser contains an invalid js code, which is related to the user input.

Common XSS injection protection can be implemented through simple htmlspecialchars (Escape special characters in HTML) and strip_tags (clear HTML tags). However, there are also some concealed XSS injection methods that cannot be solved through these two methods, and sometimes the business needs not to allow the removal of HTML tags and special characters. the following lists several concealed XSS injection methods:

IE6/7 UTF7 XSS vulnerability attack

Concealed index: 5
Injury index: 5

This vulnerability is very concealed because it makes the webpage with the vulnerability look only English letters (ASCII characters) and has no illegal characters. The htmlspecialchars and strip_tags functions have no effect on this attack. however, this attack only works for IE6/IE7, and Microsoft has fixed it since IE8. you can save the following code to a text file (do not have any space or line breaks before) and use IE6 to open it (no malicious code, just a demo ):

+/V8 + ADw-script + AD4-alert (document. location) + ADw-/script + AD4-

The most common method is the application of JSONP. The solution is to filter out all non-letter and digit underline characters. there is also a way to output space or line feed at the beginning of the page, so that the UTF7-XSS will not work.

It only causes damage to IE6/IE7 of very old versions and does not harm Firefox/Chrome. Therefore, the damage index can only be set to four stars.

References: UTF7-XSS

Incorrectly concatenate JavaScript/JSON code segments

Concealed index: 5
Injury index: 5

Web Front-end programmers often generate some JavaScript code snippets dynamically in PHP code or some template languages, for example, the most common:

Var a = '<? Php echo htmlspecialchars ($ name) ;?> ';
No, $ name is input by the user. When the user inputs a'; alert (1);, an invalid JavaScript code is generated, that is, XSS injection.
 
Before solving the problem, what is the essence of the problem? The essence is that programmers can use strings to control the whole world, but do not use the correct method to generate correct strings. Instead, they use powerful and original "manual String concatenation ".
 
You only need to change the above Code:
 
Var a = <? Php echo json_encode ($ name) ;?>;


Remove single quotes and use the json_encode () function of PHP to generate a string that represents the string. This is because,It is best to use the json_encode () function to generate all JSON strings instead of splicing them by yourself.. Programmers always make the following mistake: parse HTTP packets on their own, instead of using existing mature libraries for parsing. the advantage of using json_encode () Is that XSS injection can be avoided even if the business requires "I want to keep single quotes.

Concealed index is the highest level, hurting all general browsers. This XSS injection method is of great reference significance.

Finally, based on my work experience and the mistakes I have made with others, I have come up with a theorem that no single method can solve all XSS injection problems once and for all.

Useful experience:

• Htmlspecialchars When HTML code is output
• Json_encode when JavaScript code is output
• Input filtering should be used to address business restrictions, rather than XSS injection (contrary to the strict inbound and outbound principles, so this article is worth discussing)

Discussion:

The first article of experience mentioned above is a principle of "Wide-forward and strict-out", which is contrary to the principle of "strict-forward and wide-out. in fact, I don't think we should take "strict in width out" as a pseudo truth, as if none of its other statements were correct. "Wide-in-strict-out" and "strict-in-wide-out" should be completely equal, and should be selected based on the implementation cost.

For example, a user's name can adopt the "strict in width out" principle, and users are not allowed to fill in single quotes, such as numbers smaller than numbers. But what about the user's signature? Isn't it possible to fill in single quotes? If you want to go to the extreme, to find a silver bullet, then all I can think of is to all the input htmlspecialchars and json_encode (not to mention the solution can not solve the utf7-xss ).

In fact, the XSS injection solution should be related to the output end. filtering and escaping are unnecessary when output to a text file. json_encode is unnecessary when output to the HTML Rendering Engine. htmlspecialchars is unnecessary when output to the JS Engine