Hacker's views on XSS and References

Cross-site scripting is also known as XSS where X stands for CROSS and SS stands for SITE SCRIPTING (just our assumption). It is an injection-based attack where the attacker submits a malicious code that is accepted by the server and can harm the company’s infrastructure or leak their users' PII (Personal identification information).

The best effective way to find the XSS according to many Bug Hunters is

Going slow understanding the input methods used by the web app to store the user data and find a way to break the HTML. 

Every web app nowadays has a Defence mechanism. They usually filter out harmful or malicious characters like < > / “ ‘ `. So to know the characters which are being filtered by the web app and encoding or even double encoding, just don’t rush things by using some polyglots which are not understood by you. Finding an XSS needs a creative mind. Sometimes web apps use a method called encryption.

So for example, if we provide a username as <script> it would reflect as &it;script&gt but when we provide %26it;script%26gt, it would reflect as <script>.

Our Teams approach for the XSS is quite simple

First of all, we would try giving the server characters like ; ‘ % & “ : < and see how they are reacting. The next step is to get an idea of the characters who are blocked and accepted by the web server which makes life easier.

And then we can give a harmless payload; the most basic one like <script>alert(1)</script> and according to the response from the server and its behaviour we will craft our payload by encoding or double encoding.
Using <svg> in place of <script> or a <img> who knows the developer might block the script tag but might have forgotten about the <img > tag. In this way, we can test all the available methods and look for a way to bypass the WAF which is preventing my XSS from popping up.

The standard payloads used by us are:
<script src=javascript:alert(1)>
<iframe src=javascript:alert(1)>
<embed src=javascript:alert(1)>
<a href=javascript:alert(1)>click
<svg onload=alert(1)>
"><svg onload=alert(1)//
"><img src=1 onerror=alert(1)>.gif


  • XSSstrike (a personal favourite)
  • Dalfox
  • Findom-XSS
  • XSSHunter or ezxss (we prefer XSSHunter as it gives everything built, all we have to do is signup and spray our payloads.)
  • KNOXSS.me 
  • Last but not least made by the XSS legend Brutelogic. It finds almost all XSS and is well-updated but it is a paid one :)

Additional References

  • https://brutelogic.com.br/blog/
  • Chapter 12-Attacking Users: Cross-Site Scripting from Web Application Hacker's Handbook (2nd Edition).
  • 4.8.1 Testing for Reflected Cross-Site Scripting from OWASP Testing Guide 4.0.
  • 4.12.1 Testing for DOM-based Cross-Site Scripting from (OTG-INPVAL-001) 4.8.2 Testing for Stored Cross-Site Scripting (OTG-INPVAL-002).
  • Introduction to the DOM from Mozilla Developer Network - Web Docs.

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.

No comments:

Post a Comment