Vulnerability Analysis is just fancy QA

Test an application for vulnerabilities is just like testing an application for meeting the business requirements.  The analyst has to have access to the application, an understanding of how the application works, and a test plan in both cases in both cases. Let's take each one at a time.

First is access.  While it seems like cheating, it isn't. First, discovery of credentials takes time and social engineering (usually) which we don't have and/or is out of scope.  Second, the analyst needs to work from the assumption of an insider threat.  I usually ask for two sets of credentials for each role in the system. (Two Admin accounts and two User accounts, for example).  This makes it a lot easier to test for privilege escalation. 

Second is how an application works.  Usually the QA team on an application has been building the test plan from the start of the development, with the business analysis.  Vulnerability analysts don't have that benefit, so we have to do recon.  This is my recon list:

  • Qualys SSL Test
  • Scan network with nmap
  • Run Content Discovery in Burp
  • Index site with proxy: highlight important interactions
  • Run Content Discovery
  • Analyze uRLs for sensitive data
  • Brute force: FuzzDB directory and file scan
  • Search Google/SO/Pastebin for selected filenames in the application/names in comments
  • Take apart anything binary
  • Isolate common hidden form fields, cookies and URL Parameters

It helps out a lot.

Finally, is a test plan. Again, we haven't been building a test plan as the application is developed, but that's OK.  We don't need to.  We are almost always testing for exactly the same things. So, for this, I use the OWASP ASVS. For most applications I use Level One requirements on the ASVS, and they spreadsheet helpfully provided.

I want to rind everyone - the ASVS is open source.  It doesn't spring out of thin air.  It needs help from the community: you and me.  Check out the issues list on Github and see where you can help out.

Hmm, I did forget something - reporting.  I suppose that will be the third in this series, as there is a lot to consider there too. Sometimes you need to use the client format, sometimes the contractor, and sometimes you own. I'll share mine, and you all can go from there!

Good testing, all.  If you liked this, start with On Tools earlier.

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

 

 

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList