I’d like to get peoples opinion on something that I’ve been thinking about for some time. On wikipedia (Self-XSS - Wikipedia), they define Self-XSS as
“Self-XSS operates by tricking users into copying and pasting malicious content into their browsers’ web developer console.”
Though I know a lot of programs will rule something that doesn’t include copy/pasting, just a lot of user interaction, as Self-XSS too. For instance, a reflected XSS that requires the current user to mark a specific text on the page to trigger. On the other side, I have never seen anyone rule Self-XSS for an XSS that requires only a click (ie. onclick=alert(1)).
So my question is, where’s the line between “XSS with user interaction” and “Self-XSS”? Is there one?
In my opinion, self-XSS has a few different scenarios. Here are some that I can think of:
Where you can abuse a header or cookie to input your XSS payload without showing a working POC on how you are able to remotely achieve that. (which is the one I always run into)
Also there are setting/forms that are presented only to the user and no one else where there’s an XSS there. (not saying that it shouldn’t get fixed, but it could also be defined as XSS)
There’s another case of editors where you can insert HTML and the XSS triggers in the preview where it sanitizes the outcome before it’s posted and presented to other users.
Yeah this one is often regarded as self-xss. You can’t weaponise it to attack other people and no one else will ever see it. The other one you mention about being in forms only you can see could be self-xss, but it’s always hard to know if there’s no rendering on some back office system (blind xss). Burpsuite finally introduced out of band and blind payloads which really helps with this now.
Yeah. It always depends where you are reporting it too. Some companies accept it and may even reward you, but for most cases it’s always a no go, because it requires social engineering (unless you can do it with CSRF). I always check for that!