Hey hackers! This is the third AMA on the topic of: How to think out of the box?
The podcast episode that started this whole series is The Bug Hunter Podcast 4: Bypassing email filters & Thinking out of the box.
While preparing it, I wanted to include advice from different bug hunters. So I asked several hackers these 3 specific questions:
- How to find bugs that are not duplicates?
- How to find new areas of research (like in @securinti’s last blog post or what James Kettle does)?
- How to find logic bugs or bugs that don’t fall under any category, can’t be found with tools or require real thinking?
@ErayMitrani was one of the awesome hackers who responded. Here is his advice:
Okay most of the questions there boil down to one single thing in my mind. That is you really need to use the product to find these kinds of bugs. You need to think how you would implement a feature and where you could make mistakes. A good example for that would be https://hackerone.com/reports/481518 where I tested a graphql implementation by thinking where I as a developer could make mistakes in a GraphQL implementation.
I would highly suggest people to read documentation on commonly used specifications like GraphQL, OAuth, etc. If you know the ins and outs of the OAuth documentation you will also have read their security warnings which are basically things people can get wrong in their implementation. By studying these docs you will get a new perspective on how to attack certain technologies.
So the first goal of a hacker should be to understand and use the product or technology they are testing. This will allow you to test things a tool will not because by its very nature tools are generalized. If you know your target you can come up with much more nuanced approaches and even write your own tools.
Whenever I find a new type of bug in a certain target, I try to automate it and try against everything I’ve already tested.
In order to avoid duplicates you have to go to places other hackers haven’t gone. It’s like how they say: Hackers are people who spend way too much time trying to break something than a developer might reasonably expect. If you are persistent and innovative you will find logic bugs more often.
Thank you @ErayMitrani! It’s awesome that you took to the time to share this advice, based on your experience, with us. Very grateful!
If you want to be notified when new articles, our newsletter and podcasts are published, you can subscribe to this blog.
And if you enjoyed reading this, please consider sharing it, leaving a comment, suggestions, questions…