Out of Scope
How to prevent N/As, informatives and other soul-sucking devils in the bug hunting world.
Okay, I’ve got to admit, I’m not proud of it… But I’ve gotten N/As before, lots of them. And I’ve also been told that my reports were “informative”, many times over.
Over time, I’ve learned to drastically reduce the occurrence of these heartbreaks. Reducing N/A and informative reports benefits everyone: it not only saves you time and effort, but it also saves the security team that you are reporting to the unnecessary manpower dedicated to processing these reports.
This post is about some tips that have helped me reduce non-valid security reports. I hope it would be useful for you too.
Read the bounty policy
The best way to prevent N/As is to read the bounty policy. Carefully, and repeatedly. A well-drafted bounty policy page will tell you exactly what kinds of reports the program wants to receive.
Most of the time, there will be specific sections dictated to “Out of Scope” report types. Read this section extra carefully. What vulnerability types are out of scope? What assets of the organization are out of scope?
Organizations mark vulnerabilities and assets as out of scope for a reason, though that reason is not always apparent to hackers on the other side. Respect these boundaries, and don’t hack on targets that are out of scope.
And if you do *accidentally* find a critical issue on an out of scope asset, do still report it if you think it’s something that the organization ought to know about!
Put yourself in the shoes of the organization
Informative reports are, in my experience, much harder to prevent than N/As.
I’ve found that the most helpful thing to do to help reduce informatives is to put myself in the shoes of the organization. Most of the time, when you get an “informative”, it’s because the program simply doesn’t care too much about the issue that you are reporting.
Learn about the organization during your recon process and find out: what is their product? What data are they protecting? What do they care about? Figure out the priorities of the business and go after the vulnerabilities that they will care the most about. And remember: an informative report to one organization could be a critical one to another.
Imagine that you are a member of the security team at the organization: if you are busy safeguarding millions of users’ data every day, would you care about this self-XSS that is practically unexploitable? Even though it’s a valid security flaw, would you care about this clickjacking attack that merely allows attackers to toggle a user’s sidebar menu? Probably not!
Finally: let informatives be your guide
But honestly though, sometimes, it’s difficult to figure out how impactful an issue will be to different organizations. Some issues that I have reported as critical ended up being informative, and some vulnerabilities which I classified as “low impact” were rewarded as “high” or “critical”.
This is where trial and error can really pay off. After making sure that the issue is not an obvious N/A or informative, you should submit the report! And if you were wrong and it’s not something that the program cares about, you now have a guide to work with for future reference.
Next time you find a bug, ask yourself: did this program care about issues like this before? The last time I reported, what was the issue classified as? Learn what each organization cares about, and tailor your hacking efforts to suit their business model.
You will eventually get a good idea of what kinds of issues will deliver the most impact, and your hacking efforts will become much more fruitful then!
What about dupes?
Well, there’s simply no avoiding those… :(
First, let me give you a digital hug… And may you find some solace in the fact that somewhere on Earth, another hacker was thinking the same thoughts as you! You now share a deeper bond as laptop pounding, request intercepting human beings.