Truth. I got started quite quickly in bug bounty... But I spent 15+ years before I started learning how the web works and how to code
...for the record: I don't want to discourage newbies; far from it! But I *do* want people to have realistic expectations when it so often feels like there's people popping crits right out of the gate.
@InsiderPhD ...I think one of the hardest things for people who are completely new to the scene is assessing impact. When you don't know your XSS from your elbow how do you know what's worth submitting? My advice here is: think primarily about how your bug impacts the customers.
@InsiderPhD ...so, for example, you've got XSS on some random in-scope domain. First off: congrats. Secondly: what's the impact? Popping alerts is an OK proof of concept, but alerts don't really harm customers. The real issue with XSS is that you've bypassed a thing called Same Origin Policy
@InsiderPhD ...that's the thing that browsers have which says "JavaScript running on this domain can only access things on this domain" (there are exceptions, but that's the gist). So what? That means that the impact of your bug depends heavily on what else is on that domain.
@InsiderPhD ...if there's nothing else on that domain, chances are the impact of your bug is very low - maybe even zero. As an example, you can execute JS on null.jsbin.com *by design* - many targets have sandbox domains. Google has a list of theirs here: sites.google.com/site/bughunter…
@InsiderPhD ...there's a possible exception to that, which is if another in-scope domain "trusts" the vulnerable domain using CORS. I won't go into that here, but you can read about it on MDN: developer.mozilla.org/en-US/docs/Web…
@InsiderPhD ...so the middle-ground would be if the vulnerable domain hosts something like a marketing site with no login functionality. Remember: think about impact to customers. What can you do? You can re-write content etc for sure, but probably not much else to directly harm customers.
@InsiderPhD ...then we get to the juicy stuff. What if the domain has login functionality? Then an XSS payload could do anything a legitimate user of the site could. The impact is kinda similar to what could happen if a user left a shared/public computer logged into their account. Pretty bad
@InsiderPhD ...an example would be stealing the user's data, or changing the email address on the account so you could take over the account completely. An XSS payload could do either of those things, maybe even without alerting the user. Same bug, much more impact.
@InsiderPhD ...notice I didn't say "steal the cookies!". Many cookies have HttpOnly flags, and exfiltrating session tokens etc would be a lousy attack anyway because they'd probably be expired before an attacker could use them.
@InsiderPhD ...also there may be mitigations in place. Ever been prompted for your password before changing your email address? That's (in part) a mitigation to limit the impact of attacks like this.
@InsiderPhD ...ordinarily I would never submit an XSS as 'Critical', but there's a few things could make it a 'High' for sure.
One is if it's wormable (see here for a great example from @jobertabma: hackerone.com/reports/397968)
Another is if it fires in an administration panel (:
One is if it's wormable (see here for a great example from @jobertabma: hackerone.com/reports/397968)
Another is if it fires in an administration panel (:
@InsiderPhD @jobertabma ...this is just one bug type as an example (and I haven't even covered stored vs. reflected/DOM etc), but the point remains: impact is not governed entirely by the type of bug; always think about the impact to the customer first and foremost.
