Cross Site Scripting tricks

See also: http://character-code.com/
http://www.degraeve.com/reference/specialcharacters.php
http://www.tedmontgomery.com/tutorial/htmlchrc.html
http://www.theegglestongroup.com/writing/special_chars.php
 http://rabbit.eng.miami.edu/info/htmlchars.html
https://www.youtube.com/watch?v=VAE0A0rn8JI&list=PL1A2CSdiySGIRec2pvDMkYNi3iRO89Zot&index=7


https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

http://www.ivizsecurity.com/blog/penetration-testing/bypassing-xss-filters/


Since the time bug bounties have started, a lot of security vulnerabilities can be seen reported. From the college students to Hard Core Security Researchers, all researchers have been into it. Cross-site scripting or XSS is one such type of security flaw which is very frequently reported as this can be found much more easily than other flaws. But wait, are you sure this can be found easily always? Well, we disagree.

Most testers use two payloads, i.e., “> and ; and try them out at most of the injection points. If you are also following the same approach, then you are likely to find XSS in most of conditions, but not in ALL of them. What about those which do not lie in this category (say the application has got a filter, or say they encode some characters).

(Read More:  Is STORM Better Than HADOOP For Real Time Security Big Data Analytics?)
So instead of just passing random payloads, it’s pretty obvious to first understand where and how the payloads are getting reflected (if any). It simply means, if you can understand the request and response properly, you can be the champion. So we will be talking about the “approach for bypassing XSS filters” in this article.

Here we will mention some of the unique XSS vulnerabilities we found recently.

Case 1:

This is one which I loved personally. While testing an application there were five columns on the EDIT profile page and all were vulnerable to improper sanitization. All the payloads were getting reflected in Attribute of input tag, however the only problem with all of them was they were not allowing more than 14 characters in each field. As I started with the following:

            aa”>aaaa


Successfully injected and complete the input tag and displayed “aaaa” on the page. So I injected:
            a”>

Injected successfully but didn’t executed my script due to length based filtration and page was tampered. Tried several other payloads, and then got to know that only 14 characters were allowed. Suddenly thought of comments and along with partial payloads. So I broke my payload into three parts and then injected in three columns simultaneously:

Part1: “>

So once injected in HTML page, it was something like
script>/*   BLAH BLAH BLAH */alert(1);/*  BLAH BLAH BLAH */

Where BLAH BLAH BLAH are the page contents which I commented using the Multiline javascript comments and thus my XSS payload got executed successfully.

(Read More:  How iViZ broke Microsoft SharePoint?)

Case 2:

While testing a FILE upload functionality, I intercepted the request using burp. While the contents of file were being transferred as an XML, the inputs were getting echoed on the page which was used to show the progress of the upload. So I tried to include a CDATA into the XML file and thought of including my XSS payload in between the CDATA. This worked fine and I got an XSS. The response where XSS was being echoed was something like below.

The payload used in this scenario was :