Help would be appreciated


#1

Hello. When it came to computer security the majority of my focus to went low level exploits. The exploits that required you to have knowledge of reverse engineering, C, C++, Assembly, and computer science. Occasionally I looked into things like like java-script, php, and so on. I had knowledge of the exploits that were possible in web apps but I’ve never properly exploited web apps. With web app exploitation, the focus is information disclosure by exploitation, the only web app exploitation I can enjoy is the exploitation that overwrites some memory triggering an exploit in the lower level, giving you root to the system. Because I did this recreationally, I did not care for getting things like credit card numbers, addresses etc. It was only fun when there is a challenge and when it is complete you have the ability to modify the functionally of the device. However, I recently found out about bugcrowd and hackerone. I’ve seen that the majority of programs in hackerone are web apps. Due to this I thought I might give web app sec a try because it had good money in it. I got myself a trial of Burp Suite Pro and starting looking more into web app sec. I am aware of many tools that are used to help the discovery of bugs, tools like: gobuster for brute-forcing sub-domains and finding bugs there, obviously burp, masscan, etc. However one thing I have difficulty understanding is the process of finding bugs. I do not know how to approach the discovery of bugs. I understand I would have to go to the site and test it for XSS, SQLi, Command Injection, etc. Due to my belief that web app sec relied on automation, I purely relied on Burp, which was a huge mistake. Burp gave me many false positives which I reported to h1. I did not take time to create a PoC because the severity of the bug was high and the confidence was certain. I thought that given enough info they can figure out what was wrong. Obviously all those reports got closed due to them lacking any evidence, PoC, or reproducibility. Because of my failures in discovering bugs, I tried to look for better ways to discover bugs. I have searched for many explanations on the process of discovering bugs in web apps, and have not found anything to satisfy my question. My questions is how would I find bugs without dynamically testing the web app? I know that with back-end server-side code I can find a lot more bugs by manually read through the code, but obviously I do no have access to that. Does the process purely involve dynamically testing the web app and scanning it? I assume the logical answer to this would be something along the lines of, “The only way to test for bugs in web apps is to dynamically interact with them and use a proxy on the side to scan the target. Without the source code it is not possible to do anything else.”. I have never posted anything on any forum, but if someone were to answer my question, it would help a lot more than doing research. Thank you.


#2

Hi ape-script! Welcome to Bugcrowd :slight_smile:

Can you do any reverse engineering? Sounds like you might have the skills already, which we can definitely use for some of our bounties :slight_smile: We have a few bounties right now that involve reverse engineering windows binaries.

Regarding web app hacking, what you’re talking about is the “Discovery” process. We have some videos that should be able to help you with this:


#3

Hi @Ape-Script,

If with “scan the target” you meant “look at the requests going through the proxy and read the response”, that’s exactly what I do and I’ve been able to find vulnerabilities working that way.
However, there are bug bounty programs which are not focused in web applications but instead on native applications or hardware. And from what I see, there is a lack of people looking into those - I assume it’s because lack of knowledge. So, it’s valuable if you spend time looking into native applications. Even being paranoid: web applications could go away, but native applications are never going to go away.