Why proofing impact for every XSS is "dumb" - Bug Bounty Reports

Key Takeaways

i had some a bit of a discussion on twitter regarding showing impact of xss especially in bug bounties um there's always this conversation you need to provide a proof of concept to show impact to show impact and that is important but only once once there's one example like the developers of blogger or google triages they once you understand what the capability of xss on blogger.com can do you don't need to re-prove it you don't need anybody else to write the proof of concept you understand now that xss on blogger is critical and so you don't need to reprove that alerting blogger.com the domain is enough you know oh it's on blogger.com oh that's critical that's fine and so with buck bounty reports i understand like if it's a new client a new black bounty plat um program they don't really have a security experience yet and they want to have a bit of knowledge with back bounties maybe they are not aware which domains are really critical for them right they because they have multiple domains they have the dev dot something domain they have the api.something domain they have the whatever something domain so they have a lot of different domains and one part is hosting their javascript one domain is holding the local storage one domain has cookies um so they don't really they should know but maybe they don't know yet the impact of it so a a as a pen tester if you do an audit or um if you're a backbone hunter you need to show them once um you know this is your critical domain here's a proof of concept here's an example this doesn't have to be a full xss though you can just by looking at you know which domain has the cookies which domain has the local storage and so forth um this allows you to already assess okay this is the critical domain without having a nexus s in the first place but once you have an exercise with the proof of concept that's good enough as well anyway what i'm saying is that once one backbone t hunter showed that this domain is critical with one proof of concept all the other bug bounty hunters coming after it shouldn't have to have write a proof of concept again to show that this domain is critical um basically in my opinion i think for back bounty programs it would be easiest if they list all their sub domains or domains and they write behind it how critical it is because there will be sub domains where the xss doesn't really matter for example a lot of websites when you upload an image an avatar that image is then put on a static host so it might for example be put in an s3 bucket and you host the image there but the website itself runs on a different domain it just uses s3 for the image now oftentimes you can actually just upload anything to s3 and you can upload an html document and this html document can now have javascript and now you have an xss on the domain of this website but the the impact is basically zero because this xss cannot do anything on the main domain because it's on the s3 bucket right so um i guess that's also why they exclude the domain uh from the the uh from the program with this three buckets i guess it's clear but it could also be their own service maybe they have an image.website.com and uh where they host static content like this and you uh you you get the point so uh i i don't know where i started with that what i'm just saying is that once you once they should list their subdomains and write after it this is the critical domain if you find xss here this is critical and if you find xss here it's annoying we would like to not have it there so it's a medium or low and here our sandbox sub domains and xs and xs on there doesn't matter does that make sense and a bit unrelated that has to do with a different video i made before if your only argument is it's fishing it's not a valid issue in my opinion that is not a vulnerability if it can only be used for phishing in my opinion i'm feeling pretty strong about that it's not a vulnerability [Music] [Music] you