Need help pen testing a web app? Ask the client!

 Wait! Isn’t the client paying you to test the app? Should you really be asking them for help?

Absolutely! Clients want the best value for their money.  If you don’t talk to them about their web app you’re testing, I’d hazard to say you’re cheating them.

One of my recent engagements has been performing penetration tests on a large web application with multiple servers.  When it boils down to it, it is really multiple web applications that interact with the same back-end database.   The penetration test is supposed to be a white-box test, and we have the web application source code to review for obvious coding errors (though this isn’t strictly a code review type of test).  We are testing the application before it goes into production, so initially there was no data on the system.

As I started looking at the application, I realized how complicated it is.  There are literally hundreds of forms and some of their purposes aren’t immediately clear.  Further, the relationship between the forms definitely isn’t obvious.  The hacker in me wants to figure it all out, but I have to put my inner-hacker on hold to get the best value for the client.  I called up to get some training from the client on the system.

Training? I don’t need no stinking training!

Um, yes you do.  Unless you know how all the forms and data are supposed to interact, you absolutely need training.  A good tool like Burp Suite can help you find all sorts of web site flaws, but it won’t check for constraints set by the developer. For instance, in a recent web application we tested loan officer supervisors could only view applications explicitly assigned to them by someone in an auditor role.  In an application we reviewed last year, everyone in the supervisor role could review all records. If I hadn’t have had training on the specifics of this application, we would have missed a fairly critical logic flaw.

Valid user accounts

When performing a penetration test, I like to make sure I have two sets of valid user credentials and one set of admin credentials.  The logic here is that I want to be able to test the ability to migrate from one authorized user account to the other without supplying the second user’s password.  This is a common flaw.  Another common security issue found is the ability to add administrator (or other) permissions to an already authorized session.  Sure, it’s possible that you could brute force your way into these systems, but what if that fails? You’ll have failed to test for a common security flaw.  Just asking the client for these accounts up front ensures they get maximum coverage for their money.

Parting thoughts

Clearly, there’s a lot more to web app penetration testing than this.  I haven’t even touched on the hard stuff yet (like finding XSS, CSRF, or SQLi), but before you can find that effectively, you need access to the entire website under test.  You’ll also need to understand how the web application works (or is supposed to).  Which leads me full circle back to my original statement: when in doubt, just ask the client.