So, whether you have your very first finding (congrats by the way) or if you are a seasoned pro, it is handy to have a few soft skills in reporting and general conduct when reporting your findings to bug bounty programs.
Here is 10 handy tips to remember when reporting your findings that may help you as they have helped me:
1. Read the scope and understand them
This is possibly the most important point to make here. Check the scope before you engage the target, check the scope before you draft the report, check the scope after you draft the report prior to submitting.
The part about reading the scope before you engage should go without saying, but you really should know what your getting into before you go diving in and getting your hand slapped or worse. I find it really helpful when drafting my report to have the scope open to check for anything that might result in the submission being invalid, and for the love of all things great, do not engage out of scope targets.
2. Start with hello
You would be surprised how many times triage folks read the same thing over and over, be a human not a robot and start with a brief greeting (as if you were starting and email maybe). You don’t need to go full on “Hi I’m Troy Mcclure, you may remember me from such bug reports as the race condition in the voucher redeem and the IDOR-able user profiles” etc.
A simple, “Hi all,” at the top goes a long way in the exchange.
3. Tell the entire story
Like all good stories, they always have a start middle and end. Start with a basic summary of the bug. Think of this part as if you were writing it in a text (plz don’t write lyke this). Short, to the point, as if you were writing to someone who may not be massively technical.
For example: “I have discovered a stored XSS (Cross Site Scripting) issue within the web application. The issue is located in the ‘post message’ section on the site and I am able to trigger an ‘alert’ payload on the site that affects all users who are authenticated and authorised to access the page.”
Be brief, but don’t hold off on important facts. Think about who the bug effects, what conditions can the vulnerability be exploited (as the attacker, do you need authentication for example), where the issue resides within the site/application and touch on the impact of exploitation.
When you have written your brief, move on to the gory details. Everything packaged as neatly as possible (make sure everything is readable), remember to stay relevant (eg don’t add every single log of non-related requests or screenshots that don’t relate to the bug).
Ensure you have detailed ‘steps to recreate’, (the middle part of the story). Be graphic here, descriptions in your steps should be along the lines of:
“Step 1 - Click on the ‘go’ button (top left of the dashboard) which should take you to the next page (page link)” etc.
Finally the end, the impact. Think about the impact as what the fallout would be should a malicious attacker discover this issue and exploit it in the wild. What would really happen, credentials leaked and shared/sold? Think about your tone here, you are not trying to scare the reader into paying out the bounty, you are trying to prevent and issue becoming a valid way of an attacker taking to the wild and hurting the business or its users.
4. Evidence is key
Please, please, please add screenshots, videos and logs and anything you can (as long as they are relevant). When writing your report, think about how you would respond to the issue if the shoe was on the other foot, can you push back and refute that the issue exists or is not as severe as you first thought. If the evidence seems to point towards the severity being lower then you thought do adjust accordingly.
Pictures paint a thousand words, videos paint a million (in most cases). If you can, always provide a video of you running through your steps. Do not think that this will always ‘get it over the line’ into triage, and definatly ensure that your steps to recreate are not neglected in return for a funky video/screenshot, you have to do both in as much detail as possible.
But evidence is a golden way forward to help you get the message across.
5. Cheek gets you nowhere
If you have ever browsed through hacktivity or perused through disclosed reports, you may have come across something along the lines of this:
“I believe this is worth a large bounty, please pay out thanks”.
Not only are you making bounty hunters look like they are only after one thing (and its disgustin), but you are reducing the chances of the person on the other end taking you seriously. In the end this effects your bounty amount (if any) and the potential success rate of your report being fixed.
So, in short, do not beg for payments or swag and do not lash out if you are rejected!
6. Polite disagreements
Following the above, you may find yourself in that ‘needs more information’, ‘duplicate’ or the ‘not applicable’ zone.
Should you find yourself NMI’d (Needs more information):
Really read through the points that the responder has added and try to see it from there point of view. If its a dupe and you have no come back and agree with the result, better luck next time, move on and keep going with other projects and don’t be dismayed from bounty hunting.
Disagree with the dupe? ok, read point 4 of this article again, take a deep breath and re-read what has been said and respond in a calm manner. Respond with politeness of why you disagree, consider starting with this: “Thanks for your reply, I disagree that this is a duplicate because of <insert reasoning here>”.
Be as detailed as possible, and ensure that evidence is included. Without any evidence, then it makes it much harder to have the decision overturned.
Been asked for more info? This is more promising, but means that you need work on your initial reporting skills to avoid this as a status. I think you get the drift now, right? Be polite and don’t be implicit about the situation. Evidence is again key here, but you don’t need to be rude of forceful, just honest and leave no gaps in your response.
7. Be realistic
Before you submit, really think about the exploit conditions (or difficulty) and the impact of the issue. Don’t submit crazy things like spelling mistakes in the site or self XSS (well, without security implications to other users or the platform you are testing at least).
There are thousands of reports submitted daily without impact, don’t add to this list. Really think about what would happen should an attacker get a hold of this, if the answer is “nothing” or “they can only attacker their own account or themselves”, then maybe contact the sites vulnerability disclosure program or support service instead of hitting it over to a bounty program (were your signal and street credit could be affected). If you can’t find this, then report it but add the caveat that the impact is limited (add it to your severity rating as none for example) and take the possibility that it may affect your scores on the doors on the chin (you should still report it in some format, your doing good work here, and you may still get something of an award but don’t ask for it and don’t assume you will get anything).
Also, if you get the dreaded “Not applicable” status, don’t request disclosure in anger or frustration. If you feel that it would genuinely benefit the security community and/or it would be of interest to disclose it then go ahead, but if you have doubts, then withhold requesting disclosure.
8. Can I have an update please?
We get it, you want that moolah, but patience is a virtue and you should exercise this. Under no exceptions should you send your report wait 24hrs and ask “Can I get an update on this?” Give it time, you will get a reply.
Check out this: https://docs.hackerone.com/programs/response-target-metrics.html
5 business days is the healthy first response time for H1, but you should allow for overflows here (again be a human). There may be thousands of other things going on around your report that might result in a delay in a response to you.
Don’t get spammy or (see point 4) start lashing out, have your own “SLA” so to speak. Say, 2 weeks after no replies maybe add the “Hey folks, just checking in to see if there is an update for this, thanks” message.
At this stage, your back in the ‘patience is a virtue’ mode, wait again!
I recommend a further 2-3 weeks at this point, even if it is a critical severity bug you are reporting. Understand that you are not in control of the reply speed and there may be other factors in the way of a speedy reply (maybe they need help with your report to understand, or to find a time to attempt to recreate and retest for example). Should you receive nothing by this point, it may be worth asking support for help (again be polite here, and do not disclose the report details to support!), simply say something along the lines of “Hi support, I have an open report but haven’t had a reply since <insert date> would it be possible for someone to take a look at this please? thanks”
Stop here, and now you have to be really patient at this point. It is in their hands now and you have done everything you can, leave it alone for now.
Don’t rock the boat, just let it be.
9. TL;DR
TL;DR (Too Long; Didn’t Read), much like this article :) don’t re-write war and peace into your report. You can be detailed and brief at the same time, and it is good to find that healthy balance between being full of words and being to the point.
10. Read it, read it, read it, read it.
Read it, yes, read it. Actually go through your submission prior to hitting the golden submission button. Check for grammar, factual, spelling and any other errors that may exist in the report and squish them.
If the reader can’t understand what your getting at, then the report will likely either be binned or you will end up in a ‘needs more info’ cycle of doom.
So, we are done here for now. I hope this helps you submit your reports and that you get lots of pennies from it.
Good luck ;)
