Comments are good. We all know and have a general consensus on that. The developers should make use of comments in a useful manner. One more aspect of comment that normally we see in the wild is: developers often comment out unwanted or unused code. This may be because the functionality (code) is no more needed or there can be any other reason. This is where the problem starts. Lets elaborate it with the help of real examples from Alexa top sites. Please open the following URL (our harmless probe string "xxxxxxxx'yyyyy</img is part of URL's GET parameter slowo) and the following screen-shot shows the reflection of our interest (i.e., inside an HTML comment block). The site GAZETA has an Alexa rank of 589 at the time of writing.
It can be seen in the screen-shot above that our XSS probe string (i.e., "xxxxxxxx'yyyyy</img) lands as a part of value of <input> tag's value attribute in particular while there're HTML comments (<!-- -->) around the <input> tag. Further " from the probe string has been encoded into " while < is not filtered. In my experience, if < is not filtered than 99.9% of the time > is also not controlled but will get back to it later. Now for the moment, imagine that HTML comments are not there around the <input> tag then is it possible to break the context (i.e., attribute context)? In order to break the attribute context (i.e., value attribute of an <input> tag), we need hard-coded " because developers're using it. The " are properly encoded into " so no chance to break the context in modern browsers.
Now lets see how we can leverage HTML comments that're around <input> tag and < is not filtered as can be seen in the screen-shot above. The implicit assumption is that > is also not filtered. Lets inject the following XSS attack payload -->anyxssattackvectorhere. The goal is to prematurely closes the HTML comment block and then execute JavaScript with the help of any XSS attack vector. The browsers are good guys and as soon as the parser detects the syntax/token -->, it will try its level best to close the HTML comment even though reflection was part of quoted attribute (i.e., value attribute of an <input> tag). Please remember for the browser's parser, HTML comment has already been started (i.e., <!--) before the <input> tag. The URL at the time of XSS looks like the following and screen-shot is also given below:
Now lets see how we can leverage HTML comments that're around <input> tag and < is not filtered as can be seen in the screen-shot above. The implicit assumption is that > is also not filtered. Lets inject the following XSS attack payload -->anyxssattackvectorhere. The goal is to prematurely closes the HTML comment block and then execute JavaScript with the help of any XSS attack vector. The browsers are good guys and as soon as the parser detects the syntax/token -->, it will try its level best to close the HTML comment even though reflection was part of quoted attribute (i.e., value attribute of an <input> tag). Please remember for the browser's parser, HTML comment has already been started (i.e., <!--) before the <input> tag. The URL at the time of XSS looks like the following and screen-shot is also given below:
The next example related to HTML comments is from one of the Alexa top 500 sites. Please open the following URL (YAOLAN's Alexa rank at the time of writing is 399). The probe string "xxxxxxxx'yyyyy</img is part of URL's GET parameter searchWord.
The following screen-shot shows the reflection in HTML comments which is of our interest. There are other reflections (can be XSSed) also on the page but we will not consider them.
It is clear from the reflection of XSS probe string that " has been filtered (removed) while < is there in its hard-coded form. The developers are using " for the value attribute of <input> tag and " has been filtered so it means that in this particular reflection or case, we can not break the context (i.e., attribute context) in modern browsers. Further, reflection shows that < is not filtered so the assumption that > is also not filtered should work while at the same time please keep in mind that we want to prematurely close the HTML comment block. The attack payload will be looks like -->anyxssattackvectorhere. The URL at the time of XSS should looks like the following.
I was expecting a confirm box having 1 but got the following Chinese message (available in the form of screen-shot). I think some sort of malicious code detection mechanism (may be some WAF) was in place on their site (I translated the message and realized).
The following screen-shot shows the reflection in HTML comments which is of our interest. There are other reflections (can be XSSed) also on the page but we will not consider them.
It is clear from the reflection of XSS probe string that " has been filtered (removed) while < is there in its hard-coded form. The developers are using " for the value attribute of <input> tag and " has been filtered so it means that in this particular reflection or case, we can not break the context (i.e., attribute context) in modern browsers. Further, reflection shows that < is not filtered so the assumption that > is also not filtered should work while at the same time please keep in mind that we want to prematurely close the HTML comment block. The attack payload will be looks like -->anyxssattackvectorhere. The URL at the time of XSS should looks like the following.
I was expecting a confirm box having 1 but got the following Chinese message (available in the form of screen-shot). I think some sort of malicious code detection mechanism (may be some WAF) was in place on their site (I translated the message and realized).
Now this would be interesting :) After spending few minutes on their detection, I realized the following (go and test yourself for fun):
- <iframe>, <object>, <meta>, <style> and <script> tags are part of their black-list
- <svg>, <img>, <details> and <p> tags works
- onerror=confirm(1) does not work and it has been detected
- onerror%0a=%0aconfirm(1) becomes onerror%0a=%0aconfirm1 (small parenthesis are removed) // It means not detected ... but () has been removed
- ontoggle=confirm(1) becomes ontoggle=confirm1
- javascript: has been detected but javascript: works
- `` was not removed so we can use confirm`1` instead of confirm(1)
- many more ....
http://search.yaolan.com/all.do?searchWord=--><p/id=1%0Aonmousemove%0A=%0Aconfirm`1`>
I deliberately picked a XSS vector that needs user-interaction so that you can identify and see yourself the vulnerable end-point i.e., inside comment block. On the page, there are other vulnerable end-points also. I found some real examples related to JavaScript comments and how can we leverage them for XSS but I will write about JavaScript comments later sometime. I will conclude on ... Why not delete the unwanted or unused code instead of commenting out?
Really informative ! :) i have been into many sites with same type of filtering and scenario, and now i think that i have learned much from this write-up and able to bypass them now :) Thanks sir really much appreciated. :)
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
Deletewhatz the logic behind using "id=1" in above xss payload ?we can execute payload without it..any pointers?
ReplyDeleteIt is just a construction of XSS vector. Some examples can be found here: http://slides.com/mscasharjaved/deck-11#/ and http://slides.com/mscasharjaved/sucuribypasses#/
DeleteWeb design is the process of creating websites. It encompasses several different aspects, including webpage layout, HTMl Training in Chandigarh, content production, and graphic design. While the terms web design and web development are often used interchangeably, web design is technically a subset of the broader category of web development.
ReplyDelete