During my time as a bug bounty hunter/security researcher, I have come across a few disclosed reports that look super serious but actually have little or no impact to the programs assets or its users.
This usually ends up being marked as informational, N/A or worse, spam! Then comes the push back from the hunter, which always looks messy in a report and likely degrades the reputation of the finder (enter shameless plug for my other post here about reporting standards).
Remember people, this is about building relationships with companies and triagers who work very hard to reduce the potential of user information falling into the wrong hands. We are simply the notifiers of issues that could result in a disaster if left unchecked.
So without further ado, here is a non-extensive list of bugs that you should double check before reporting and really think hard to avoid adding to the pile of informational reports.
4 — Open redirects (without impact)
There is a vast amount of reports that talk about open redirects, but the truth is, simply being able to redirect a user without anything else isn’t a real worthy bug.
Yes, I understand that there is a potential to redirect the user over to a phishing page but what is really stopping the user from discovering the address they have been redirected to, and as for attempts to share malware, browsers are getting significantly better at mitigating this issue (with warnings to users that a download could be malware ect).
An open redirect normally requires 2 stages for an attacker to successfully pull off an attack against a user. 1st, the attacker has to craft a specific URL with special parameters that have the desired redirect address (based on the fact that the application is redirecting without validation). 2nd, they have to share the URL with the victim, sound familiar? Yep, just like they would attempt to do in a phishing campaign. In reality, all this does is give the attackers phishing email body 1% more credibility, but with more than enough time for victims to discover something is off. I know I am giving users far too much credit, but this is mainly the opinion of the programs that I have come across.
When does this become a real issue? When you can tag it with XSS (Cross Site Scripting). Should you be able to pull off something like https://completelyfakesite.com?redirect=javascript:alert(1) and actually see the alert pop (ideally with session tokens, so maybe use document.cookie) then by all means report the hell out of this!
My advice/opinion, read the scope, if open-redirect is listed as out of scope then back away unless XSS is exploitable. If it isn’t, I’d hit up the security team with a note asking if it is in scope and try to gain a general feel for their response to this ‘maybe’ bug (if there is a contact for questions that is).
Questions I would ask myself before reporting
- Does the program scope mention open redirects as ‘out of scope’ in the program listing or do they gear towards redirect as a non-issue?
- Does the open redirect allow any form of XSS or injection of any type?
- Is there a security contact I can chat to first to gather their approach to this?
3 — Information disclosure of server version
Simply no, this alone isn’t a problem. This is at best, best practice and will probably be an N/A to anyone working triage.
Banner grabbing is the “art” of finding out information such as version number of the server is running (either by looking at the HTTP responses and finding the Server header, running the domain through https://dnsdumpster.com and seeing the server versions in the results or using nmap for example). This on its own, stop and put it down, it isn’t a bug.
What you should do is take the version information and note it down. Research for known exploits and attempt them against the target (providing you aren’t going to completely down the site that is). This at least gives you an avenue to actually finding a real bug.
Questions I would ask myself before reporting
- Does the version of this server have any CVEs or disclosures attached to it?
- Are they exploitable against the target? (Report this instead).
2 — Self XSS
Cross site scripting is the ability to inject scripts into the application. They are normally either classed as Reflected, Stored or Self.
Lets drill this down:
Reflected
Reflected XSS requires the attacker to share the payload with the victim, to me this reduces the likelihood of attack (a tad) and should reduce the overall severity down to somewhere between low and medium (very rare if you get this to high).
An attack scenario, would be something along the lines of, attacker finds the ability to use javascript in a search bar, the web app also adds the payload (say, <script>alert(1)</script>) to the URL in its GET parameters (so the URL would look a little like this: https://crapsecuritystore.com?search=%3Cscript%3Ealert(1)%3C%2Fscript%3E).
The attacker then sends an email to the victim enticing them to click the link, hey presto.
Stored
This is more dangerous in terms of impact to the user. Stored XSS means that the payload is actually stored on the site itself and is shared with other users when they hit the affected page.
For me, I consider this medium to critical depending on the circumstances. Medium if you can’t grab session cookies and critical if you can :)
Again, as for an attack scenario, say you have a forum with multiple users that can see each post as long as they are authenticated. The attacker writes a script to steal session tokens and adds it to the body of a post and multiple users read this post and end up passing their cookies over to the attacker.
Then you have a stored XSS finding, with the ability to take over sessions.
Self
Self simply means… You can only attack yourself. If you think about it, every single site is affected by self xss. You have a developer console attached to your browser that can essentially run some javascript, quick panic, the web is on fire! (jokes). I only know of one program that accepts self XSS as a real bug (and crazily they pay for it!) but you will have to figure out which bounty program that is for yourself.
Questions I would ask myself before reporting
- Can this payload be executed against other users?
- Can the payload grab session tokens?
1— Logout CSRF
CSRF (Cross Site Request Forgery) is an issue that could lead to users doing things they didn’t intend such as changing their passwords, or any value/information associated with their accounts.
By crafting a request (maybe via a hidden self submitting form hosted on an attackers site), the attacker ‘could’ depending on certain circumstances smuggle a request to the target website on behalf of the victim (check out: https://portswigger.net/web-security/csrf for more info).
CSRF may be on its way out with changes to the way cookies are handled in browsers. The idea of same-site/lax cookies may make this type of attack very difficult to pull off in the future, given that the cookies are no longer (if configured correctly see: https://owasp.org/www-community/SameSite) able to be passed to the target site meaning the users interaction would be unauthenticated by the time it hits the intended page with the vulnerable function.
But, I have seen the odd occasion where a report is the following “I can log out any user by sending the victim to my site with a self submitting form or sending them a link with this logout parameter included”. No program is going to care if the impact is “The user gets logged out”. 3 things to consider, the user data is isn’t compromised by this, the user might be a little annoyed at being logged out, the user will likely get in touch with support if it is a problem and the support team will likely be able to see the origin of the request.
Alas, there is no impact with Logout CSRF and actually impactful CSRF may be on the way out, so really consider “what can an attacker actually do with this CSRF vulnerability?” That is not to say, you shouldn’t attempt CSRF during your research, but be considerate of the actual impact that the CSRF issue holds. I’d personally consider a password change as an end result of CSRF a high severity bug, as this essentially leads to account takeovers, but the attacker still needs to get the user to interact with the attackers site or payload (making it more difficult to do).
Logout CSRF is the bug bounty equivalent of saying “Your fly is undone” when you are already naked. The point I am making here is, it isn’t the CSRF that holds the impact alone, it is what the end results looks like that makes the bounty.
Questions I would ask myself before reporting
- Why on earth would I ever report logout only CSRF?
- Does CSRF work on critical actions against the users account or is it mitigated?
Conclusion
The key question should always be, “What can an attacker do to the application, user or business if this vulnerability was exploited in the wild?”
Now think really hard, if this is something like the attacker will receive $100000 from every user by exploiting this, then for sure this is a problem. But, if it is something like the victim will notice a slower login flow the next time they authenticate, then forget about it and move on.
