As I wrote in my previous post about low-hanging fruit and the 2011 Verizon Data Breach Report, I’m a strong believer in finding out where your Web systems are bleeding and focusing on those issues first. It’s the basic principle of triage – finding, and fixing, the urgent issues on the important systems. The thing is you cannot stop there. Yet I see people pause their efforts after the biggies have been addressed, especially within SMBs. The scans are run, the major issues are fixed and before you know it, a false sense of security sets in. It’s the perfect formula for a future Web security breach.
If you’ve been around web security for a while you know that some of the more technical flaws can take some time to uncover. Heck, many of the issues take some time to just understand. It reminds me of early on in my IT career when it took me years to really wrap my head around the protocols, addressing schemes and other nuances of TCP/IP. Web applications are equally complicated – if not more – and I continue to learn new things.
Web application security testing is both an art and a science. It requires deep creativity and strong analytical skills. With Web applications, we need to be able to look for specific – and verifiable – vulnerabilities using both automated scanners and manual analysis. But we can’t stop there. We also need to be able to think longer term and think about how some other potential flaws could lead to other problems. This means outlining various scenarios of what could happen if X, Y or Z falls into place and an exploit occurs.
Some issues that come to mind include:
- Password policies (or lack thereof) – just because you don’t find any weak passwords doesn’t mean they’re not there.
- Application logic flaws – if an application workflow seems a bit off then it very well could be. How could someone take advantage of this and what is there to lose when something goes awry?
- Possible SQL injection issues as found by Web vulnerability scanners – even if you’re unsuccessful validating the vulnerabilities, you or your SQL injector tool may not have dug in deeply enough so the flaw could still be present.
- Authentication mechanism issues that appear to permit login bypassing or session manipulation – these can be tricky to reproduce, but again it doesn’t mean they’re not there for the taking by a malicious attacker with nothing but time on his hands.
Bottom line: you’re the expert. You can’t blame vendors for failing to find or report on all Web security issues in your environment. People are counting on you to do your best so you owe it to your developers (and your business) to make them aware of all the issues – both confirmed and plausible.
Sure, you’re not going to find all the vulnerabilities and odds are you’re not going to completely understand them all – especially at first. That said, given what’s at stake, the general expectation is that you’re doing what you can to continually learn new things and have an open mind and the analytical skills needed to know where to look in order to ferret out the not-so-obvious “issues” that could get ugly down the road.
Just like every Web application, we’re all a work in progress. As long as we understand what’s required of us to work in this ever-changing field and we’re committed to staying focused in the right direction, that’s all that matters.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Comments are closed.