When we are facing a Blind XSS, which means that we cannot see our input reflected in the body of the HTTP response ( i.e. Reflected XSS or Stored XSS ) or try to modify the current DOM via javascript ( i.e. Dom-Based XSS ), the given vulnerability is triggered on a page where we do not have access to
And it usually occurs on contact forms, reviews, user details, support tickets and so on
Since we cannot see how our input ( i.e payload ) is displayed in the HTTP response, we can use a javascript payload that sends an HTTP request back to our server
Since we do not know the context where our input is loaded, this is a good way to assess a possible injection point
Another drawback is that if we are facing a contact form that is periodically reviewed by an agent or administrator, we will not know which of all fields is vulnerable, at least if we enter the same payload in all fields
However, we can send a different payload for each field. All payloads will request a resource hosted on the operator’s HTTP server. This resource will be the name of the field
For instance, we have a contact form with three fields, namely username, email and subject
If we receive a request for any of these resources, then we will know the vulnerable one
Otherwise, we have to try again with a different type of payload, such as those mentioned previously
Abuse
Session Hijacking
As we all know, the vast majority of web application handle the user sessions with cookies
The latter means that users do not have to log in to the web application every time they start their browser
However, this means that any attacker who steals the session cookie will be able to impersonate the user and takeover the entire account, which is called a Session Hijacking
So, once we have detected the vulnerable endpoint, we can proceed to the XXS Exploitation and hence, to the Session Hijacking
We have several javascript payloads to exfiltrate the session cookie by sending it to our HTTP Server