XSS bypass-I have something to say

As we all know, the common method to defend against XSS attacks is to escape the following characters in the background: <,>, ', ", but after my research, I found that in some special scenarios, even if the above characters are escaped, XSS can bypass the XSS attack. First, let's look at a JS example:

 <script>  var s = "u003cu003e";  alert(s); </script> 

 

When running this code, the result is as follows: Will anyone feel excited when xss bypasses such a familiar angle bracket? No angle brackets appear in JS Code, but the angle brackets are output during runtime !!! This means that you can replace <and> with u003c and u003e. But how can we use this feature to construct XSS attacks? Let's look at another example:

<div id='s'>  test </div> <script>  var s = "u003cimg src=1 onerror=alert(/xss/)u003e";  document.getElementById('s').innerHTML = s; </script> 

 

Run the above Code and the result is as follows:

Xss attacks have successfully implemented a bullet box case without angle brackets. Now let's imagine a more close to the actual development of the example :( 1) Here we use the network security defense Research Office site home page Demonstration: http://www.91ri.org/main.html, the code is:

01 <div id="test"> 02    aa 03 </div> 04 <script>     05    function callback(obj)     06    {         07        document.getElementById("test").innerHTML = obj.name;     08    } 09 </script> 10 <script src=" http://www.victim.com/getcontent"></script> 

 

(2) http://www.victim.com/getcontent The returned content is in the following format: 1 callback ({"name": "xx"}); the value of name is the nickname of the user. In this example, information is pulled asynchronously and displayed. Assume that the nickname is u003cimg src = 1 onerror = alert (/xss/) u003e. What is the situation? First, the nickname returned by getcontent should be like this: \ u003cimg src = 1 onerror = alert (/xss/) \ u003e when the background outputs JSON format data, generally, escape characters are added to the front. The callback function connected to main.html is equivalent to executing the following statement: document. getElementById ("test "). innerHTML = "\ u003cimg src = 1 onerror = alert (/xss/) \ u003e"; the result is as follows: Sorry, no pop-up box is displayed. The reason is that the original escape sequence u003c does not take effect, and the added escape character is escaped. However, if the returned nickname is escaped, but in actual cases, sometimes the json format data is not escaped, this will trigger the vulnerability. If there is a pair of escape characters, it is our turn to play a powerful half character. For the problem of half-character, we do not intend to elaborate here. Conclusion: For gb2312 encoding, "[0xc0]" is a legal code, which is displayed as "bytes ". For UTF-8 encoding, in IE6, the above combination is also a legal encoding. [0xc0] indicates a hexadecimal value. Now change the nickname to [0xc0] u003cimg src = 1 onerror = alert (/xss/) [0xc0] u003e getcontent output: callback ({"name ": "[0xc0] \ u003cimg src = 1 onerror = alert (/xss/) [0xc0] \ u003e"}); because of the presence of a half character [0xc0, when interpreting the above JS code, it is equivalent to: callback ({"name": "u003cimg src = 1 onerror = alert (/xss/) u003e"}); visible, the escape sequence u003c is returned, and the result is as follows: no single double quotation marks or angle brackets appear in the nickname. Therefore, if the backend only escapes single double quotation marks and angle brackets, this can be bypassed for defense. Conclusion: (1) Application Scenario: the output content is in the JS Code and is dynamically displayed (for example, innerHTML ). (2) Test method: intercept the request packet and modify the parameter to % c0u003cimg + src % 3d1 + onerror % 3 dalert (/xss/) + % c0u003e (3) defense method: the backend is processed with half characters, backslash, single double quotation marks, and angle brackets. Edit comment: there are many ways to bypass xss. Many programmers and Xiao Hei think that filtering <,>, ', "is really safe. Actually, if you escape these characters, you can bypass them!