Powering the Lamest: Self-XSS

The image is a great example of self-XSS — it is the kind of XSS that only affects the currently authenticated user*.

*Note: We will not be talking about social-engineering attacks where you ask someone to paste your payload in the browser console — as they are more lame than a self-XSS! And I have set some limit to the lameness I can talk about… I hope you understand ;)

Reflected

Say you are pentesting an application and found a self-xss that reflects what you type on the page — say while searching an item.

How would you exploit it? Can you trick the user into typing what you want in the search bar?

Well when I was thinking for this, there were 2 possibilities that came to mind:

2. Clipboard or Drag text modification: If the attacker is able to get the victim to copy something from the page controlled by him/her or is able to make them drag it to the vulnerable webpage, then too we can trigger XSS — but it sounds a bit lame to me, doesn’t it?

Stored

If you found a stored XSS on a website, in that case you can possibly exploit it using the following techniques:

1. Exploitation by CSRF Login/Logout: If an attacker is able to perform a CSRF attack, then you can:

Since the domains are same, the iframes can read each other’s contents and thus the sensitive information from iframe #1 can be read by the attacker and sent to their servers for later use :)

2. Exploitation by Cookie Injection: If the website is using non-HttpOnly cookies, then JavaScript can be used inject the cookies to the website. How exactly?

So if you have issues where cookie injection is possible like: Subdomain takeover, XSS on another subdomain, response header injection.

So the idea would be as follows:

What if the mentioned vectors are not feasible in your case?

The website has protections against CSRF, doesn’t allows you to frame it and is not vulnerable to response header injection or cookie attacks in general.

Then what?

I myself found self-XSS issues in the past but wasn’t really sure how to escalate those. The application was secure enough — no CSRF, no cookie injections. So I looked up and found this interesting talk by ­Mathias Karlsson. Although the points covered were great but none of those were of help there :(

Do you think there’s anything that can be done? Any way to make your point and get bounty for your report?

Think on it for a while and let me know on Twitter @RuntimeSecurity :)

I will share some more thoughts on this and the reasoning that I use when I get such bugs. I will also incorporate the responses I get, if they are worth considering and make this post more comprehensive. Looking forward!

Always remember finding a bug is not everything, unless you can prove that the bug has security implications. And that’s why I am putting out this post, to help you become better at reasoning on why the bug you found should be fixed and awarded bounty :)

I hope this post helped stretching your brain muscles and pump more info in there ;)

Feel free to connect with me on Twitter and let me know which topics you would love to read more on.

Lastly, if you have been enjoying my work and would love to support me, consider checking my Patreon page or you can even Buy Me a Coffee :)

See ya!
Until next time my friend, keep learning and happy hacking.