Cross-site Scripting (XSS) - Detailed

2.1 Reflected XSS (Non-Persistent)

In this type of XSS, the xss payload got injected inside the request and server reflect that payload back in response. Payload doesn't get stored anywhere only get reflected back by the server in response.

Example workflow

• There is a search functionality which takes input from user and response back with the result, having a heading like "search result for 'user_input'"

  Request url https://example.com/search?query=cat

  Response body <h3>Search results for Cat</h3>

• After using xss payload <script>alert('XSS')</script> as search input, it would be like

  Request url https://example.com/search?query=<script>alert('XSS')</script>

  Response body <h3>Search results for <script>alert('XSS')</script></h3>

• When reflected response with our injected js reached to the browser, browser treat it like a script tag and our js would be executed.

2.2 Stored XSS (Persistent)

In this type of XSS, the XSS payload get injected to such a place which is stored by the backend for further uses. For example : comments. Payload get stored inside the database/backend and distributed & executed on the each users browser who render that comment.
It is more dangerous because a single stored payload can be executed on multiple users, everyone who receive that injected response.

Example workflow

• There is a comment functionality in the blogpost. Where a user can do comments and anyone who opens that blogpost can see the comment.
• An attacker, instead of writing simple comment, he wrote a xss payload like : <script>alert('XSS')</script> inside the comment. Backend stores that comment as user provides along with the blogpost.
• Now every time when someone requests for that blogpost he will get the payload inside the comment along with the response of blogpost

2.3 DOM based XSS

Dom based XSS totally works on client side environment, where the DOM (assume dom as webpage) processes the user input and updates the dom. All the processing/updating works happens on client browser, there is no need of any interaction with backend.

While dealing with dom based xss you will encounter with 2 word "Source" and "Sink". Lets understand these.

• Source : The place where payload injected. In below example source would be the url parameter.
• Sink : Sink is the actual place who execute the payload. In below example sink is .innerHTML

Example workflow

• There is a section who shows the current section by extracting the value after # from the url. It extract the value and update the element with that value.
  
  DOM XSS html

  <div id="output"></div>
  <script>
    // takes whatever is after the # in the URL and writes it into the page
    const output = document.getElementById('output');
    output.innerHTML = location.hash.substring(1); // <-- vulnerable
  </script>
  

• An attacker can easily replace the values after # in the url with the payload <script>alert('XSS')</script>, and tricks you to open the url.
• The moment when you will open the url in your browser, the payload will be executed, because the payload is directly inserted in the code.

2.4 Blind XSS

Blind XSS is a type of xss which works similar to the stored but it doesn't send any response with the inserted payload. In Blind XSS, xss payload get stored on backend/database and can only be seen by the users having access, and when they loads that data into their browser, payload get executed. Let understand it by example :

Example workflow

• There is a webpage having a feedback form init. Where any user can submit the feedback and only the admin user can see the feedbacks.
• Attacker injected their payload inside the form and submitted. When the admin user open the feedback section to see all the feedback form, after that when the feedback submitted by the attacker get loaded then payload would be executed on the browser of admin user.

3.1 Context vs Sink

Context is the last place where payload ends. And Sink is the actual functionality who execute the payload. In below example javascript string is context and the eval() is the sink

<script>
  var userInput = "USER_INPUT";  // context: inside JS string
  eval(userInput);               // sink: eval executes JS code
</script>