Do NOT report security vulnerabilities, report impacts instead!
TL;DR: In this post I’ll show you why and how you should report an impact instead of a vulnerability.
It doesn’t matter if it’s a bug bounty program or an internal team in your company, reporting the highest impact it’s always better than report just a vulnerability.
Think if you were on the other side. Would you fix something just because someone is reporting a vulnerability or you understand that security issue can cause a really bad impact for the company you work for?
Imagine a developer or an entire team has a big backlog with new features to be implemented in a short deadline and also a fix for a vulnerability which the description do not clear shows any impact. If you were this developer or part of this team, what’d be your priority?
By reporting a clear impact with a reproducible PoC will also avoid those endless discussions about if it’s a vulnerability or not and it’ll save time from everyone involved. Instead of report a vulnerability saying an attacker “could do this” shows the impact through a video or performing a real time demo describing “I did this” like an attacker.
In case you are a bug bounty hunter reporting the highest impact can help you to avoid duplicates because if it’s a critical it should be fixed ASAP reducing the window time for someone else report the same security issue. Don’t forget the bigger the impact, the greater the reward.
Let’s cut the cheap chat and talk about real examples.
Cross-site Scripting (XSS)
Most of the XSS are reported by running the JavaScript function alert() in a victim browser. What’s the impact on running alert()? There is no impact on alert() and some times people describe the impact by saying “by exploiting this XSS an attacker could…” trying to explain the possible impact but not really proving anything.
Let’s take this report https://hackerone.com/reports/63888 as an example. It’s a valid XSS vulnerability on login page in the email field and the hunter got only $50 for this report. There is no clear evidences of a real impact in the report. In this case I’d try to craft a payload that would steal credentials as soon as the user provides the username and password in the login page. Notice a critical vulnerability under the same program would pay $500 (10 times more than the bounty received) and that’s exactly what another hunter did in this report https://hackerone.com/reports/881115 for another program and received $500 without much discussion.
Steal credentials is just one possibility. There are no limits what you can do with a XSS because basically you can run any JavaScript code on the victim browser.
You can also combine a XSS with other vulnerabilities in order to increase the impact. Like in this report https://hackerone.com/reports/534450 where the hunter found a vulnerable endpoint which allows to set or get any cookie. Under the same application there was a cookie based XSS. Combining these two issues the hunter was able to perform full account takeover and got $2000 and the report was classified as high severity.
Open Redirect
Open redirect is probably the most reported vulnerability without any impact. This report https://hackerone.com/reports/311330 with 6 lines got 8 duplicates and received $100.
If you find a open redirect I’d suggest to find a feature which can be abused with the open redirect or another vulnerability which requires an open redirect. In any case the impact will be higher than reporting only the open redirect alone. I’m not really sure but I believe experienced hunters only search for open redirects or XSS when they need one.
On the other hand in this report https://hackerone.com/reports/206591 the hunter was able to perform an account takeover because of an open redirect and received $8000. That’s a common case when the OAuth protocol is not implemented correctly (https://portswigger.net/web-security/oauth#leaking-authorization-codes-and-access-tokens).
Like XSS an open redirect can be combined with other vulnerabilities. For example an open redirect when combined with HTTP Request Smuggling (https://portswigger.net/web-security/request-smuggling) can cause a big impact like in this report https://hackerone.com/reports/737140 where the hunter was able to perform a mass account takeovers and received $6500.
Currently HTTP Request Smuggling is one my favorite vulnerability. By combining a HTTP Request Smuggling and open redirect I was able to send any MDM commands to any device enrolled on a vulnerable MDM server as described here https://ricardoiramar.medium.com/the-powerful-http-request-smuggling-af208fafa142.
What should I do then?
With the vulnerability found in mind think from the attacker perspective and write down your gains like take control of the victim account, delivery a product in a different address, send a message on victim behalf, read private messages from the victim, etc… now put in the victim position to be sure this is really impacting you.
If you don’t see a clear impact it’s time to research. Search for similar scenarios on Google or for the vulnerability that you have in hands. If you don’t find anything interesting you may talk to someone you trust in order to get more ideas. In the last case if there is no impact just take a note and maybe in the future you will need that vulnerability to complete a beautiful chain of vulnerabilities.
Now that you have your malicious scenario with a real impact it’s time to prove by creating a PoC video. If possible, use two different virtual machines or VPS and from one VM plays the attacker and from another the victim. Using your test environment try to reproduce the attack and if everything works fine do it again but record everything in a video to be attached in your report.
If you have any question or want to share anything interesting you can contact me on twitter @ricardo_iramar.
