XSS exploitation of InnerHTML attributes

 

InnerHTML is a strange HTML attribute, not supported by W3C standards, but almost all vendors support this attribute by default. Recently, some tests have used this attribute, here are some interesting questions about innerHTML. All elements have the innerHTML attribute. It is a string used to set or obtain the HTML in the start and end tags of an object. InnerHTML is usually used for dynamic insert.

The simplest innerHTML is used in this way:

<Br> output: <div id = "output"> </div>

<Script>

Var output = document. getElementById ("output ");

Output. innerHTML = "hello, world! ";

</Script>

This Code uses the innerHTML attribute of the output variable to insert a hello world! Into the div !. Generally, when writing webpage code, we first write a template to insert variables such as user input into the template through innerHTML, which is very convenient.

The more powerful innerHTML is that it can change the format. We can change the output statement:

Output. innerHTML = "<I> hello, world! <\/I> ";

If the code is written like this, hello world! Italics are displayed on the page.

I believe they have all seen the key points, and the <I> </I> label is resolved! Next, what if we enter the <script> </script> tag? Change the output statement again:

Output. innerHTML = "<script> alert (1); <\/script> ";

The result is very strange. It is useless. As expected, there is nothing! It is even more strange to use firebug to view the code after executing javascript. Here <script> </script> is regarded as a tag and can be seen from the blue mark of firebug, but why not play the window?

It can be guessed that the browser has performed another layer of encoding on the data parsed by innerHTML, and then another test statement to see if it is true:

Output. innerHTML = "& lt; script & gt; alert (1) & lt; \/script & gt ;"

Here, I first made an HTML encoding layer. After a parsing, it should be <script> alert (1) </script>. If innerHTML is parsed and directly displayed, it should pop up the box. View the processed source code. The output is & lt; script & gt; alert (1) & lt;/script & gt;

 

In this way, it is basically clear that innerHTML has done HTML parsing during javascript processing, and then made HTML encoding when loading pages in the browser. It seems to be seamless and there is no problem with the solution. But! Note that the order in which the browser loads pages and loads javascript can be changed.

 

The defer attribute is used for delayed loading. This is illustrated on W3shcool. If your script does not change the content of the document, you can add the defer attribute to the <script> label to speed up document processing. Because the browser knows that it will be able to safely read the rest of the document without executing the script, it will postpone the interpretation of the script until the document has been displayed to the user. Let's try this input: Security "r" D "o! \ & K/G9 M1 G) D

Output. innerHTML = "<span style = \" display: none; \ "> 1 <\/span> <script defer> alert (\" 1 \"); <\/script>"

Because IE will ignore the prefix script of the innerHTML attribute, a hidden character is added here to trigger the defer script. After the explanation of javascript is postponed, the box is displayed. Unfortunately, firefox is a bit natural and does not support defer. Therefore, this pop-up box is only valid for IE and is relatively limited.

I found this innerHTML problem. I saw it in the search box of the baidu search box, because my friend who communicated with me was a Baidu security engineer. Now it seems that I have fixed it, you know. Send this technical article to commemorate it. Get rid of newbie!

 

FROM: TOOLS