I’ve been working as an Application Security Auditor in Oupost24’s web application security testing team for almost three years now. Our team have shared several pieces of research over the past year, on topics including cross-site request forgery, cross-site scripting attacks, and weaponizing permissive Cross-Origin Resource Sharing (CORS) configurations.

Testing web applications can be challenging, so I thought it would be helpful to pull out five key strategies that have helped me to get positive results in my career so far. Here are my five pieces of advice to find web application vulnerabilities that I shared in a recent talk at Bsides Exeter. Hopefully they’ll be helpful to junior (or experienced!) pen testers.

1.      Get comfortable with automation

It can be tempting to try to do it all yourself. When I first started testing, I felt automation was unreliable – and was even a bit scared of it due to the potential risk of crashing applications! But letting automation complement your testing can be a game changer.

Take vulnerability scanners. They’re not 100% accurate, but they have their uses when you think about them in the right way. They might discover a cross-site scripting vulnerability or an SQL injection vulnerability every now and then, which is great. But instead of relying on them, I’d advise thinking about the results they find as clues which a human can build on. So, use automated scanners, but more so they might find areas of weakness that you can expand on yourself.

Vulnerability scanners are also particularly helpful when it comes to fuzzing (a software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program). They can automatically fuzz endpoints far better than I could manually, so I’d encourage other testers to embrace its potential. It can save time from manually checking everything and highlight the areas you do want to spend more time looking into manually.

So don’t be scared of automation! Learn it, understand it, and use reliable tools. You can even build tools yourself. But definitely don’t ignore it – the harsh truth is you’ll be left behind, given the size of the applications we have to deal with in short spaces of time.

2.      Try that ‘obvious’ idea!

Nothing is too obvious to test – this is always my best advice to new testers. You’d be surprised how often you check for something that seems too obvious to even bother with and it turns up valuable information. So, try to catch the voice in your head dismissing an ‘obvious’ test. Worst case, at least you’ve checked. But I’ve personally found that playing around with ideas that seem silly at first can actually lead to interesting discoveries.

If something seems complicated (as it often does in this line of work), embrace simple thinking and break the task down into obvious steps. Then introduce these ‘obvious’ steps into your methodology, as they might be the things nobody else is looking for.

And to follow on from the first “How to find vulnerabilities in web application” tip in this article, this is another area where automation can help. One great thing about automation is it makes testing for ‘stupid’ ideas quick and easy. Automation means you can run the tests and forget about them. If they turn nothing up, you’ve not lost anything. But if they do, happy days! You’ve found something everyone else thought wasn’t even worth looking at.

3.      Step back and reflect

It’s important to question your assumptions. Something I often do is state them out loud to myself, or to the nearest rubber duck. Now, bear with me here… There’s an age-old software development trick called ‘rubber duck de-bugging’ where you explain your problem to an inanimate object or to a person who has no idea what you’re talking about. Explaining the problem in simple terms can make it easier to catch yourself making an error with logic or making an incorrect assumption.

Another key piece of advice that may seem obvious is to step back and read the documentation – then double-check and read it again! Read it before the testing so you know what the application does, and then read it again halfway through the testing when you’ve started discovering things. Start treating the documentation as an ‘exploit development guide’ and you’ll get more out of it.

4.      Embrace the complexity

Imposter syndrome is something many of us feel in our careers. I’m relatively experienced now and I still get it sometimes! For many people, it’s something that doesn’t go away no matter what you accomplish. The truth is that the work we do is complicated and challenging – so it’s natural to feel that way.

If you’re feeling out of your depth… You’re probably in the right place. Embrace the complexity and learn that new technique you’ve been worried about trying. Test the hard-to-test features and try to have fun with it. You might discover a critical vulnerability that other testers missed.

5.      Always push for maximum impact

Critical vulnerabilities are forged – not found. It’s important to know what is possible in the application, and the ‘how to exploit it’ comes later. You won’t reach maximum impact by going through the motions and coasting. Read, research, listen and then repeat. There’s always something new and you’ll be surprised how often new research is released to change the way you think about a topic.

I’d also encourage testers to always chain their vulnerabilities together. Chain, chain, and then think about what else you could chain. You might find small things that aren’t worth individually reporting to the customer but could have an impact when considered alongside other things in the bigger picture.

If you found the tips for finding vulnerabilities in web applications in this blog helpful, you can check out my full presentation at Bsides Exeter here, which contained some walkthrough of recent vulnerabilities I’ve found.

Does your organization need support with web application testing? Get in touch and our expert team will be happy to help.