NetSPI Blog

Are You Testing Your Web Application for Vulnerabilities?

Steve Kerns | Wednesday, May 5th, 2010

As an organization that performs a large volume of code reviews and penetration tests, NetSPI is frequently asked which type of application assessment is the best option. Your primary options are a code review or a web application penetration test. Both are recommended and both find many of the vulnerabilities commonly found in web applications as defined by the Open Web Application Security Project (OWASP) Top 10 (http://www.owasp.org). By themselves, neither a code review nor a web application penetration test find all of the vulnerabilities that threaten the application.

Why perform them?
Many regulations either require them or highly recommend them. For example, Payment Card Industry Data Security Standard (PCI-DSS) requires that either a code review or a web application vulnerability security assessment (web application penetration test) is performed annually on any web application that stores, processes or transmits credit cards (PCI Requirement 6.6).  In addition, for payment application vendors (i.e. point-of-sale application, etc.) the PCI Payment Application Data Security Standard (PA-DSS) requires a code review and a penetration test targeting the OWASP Top 10.

Picking one over the other
Even though code reviews and web application penetration tests can find most of the same vulnerabilities, they look at the application differently and as a result their findings can differ. Typically both approaches find OWASP Top 10 issues such as SQL Injection, cross-site scripting (XSS), etc.  However, the efficiency and effectiveness how each method finds these vulnerabilities can differ. For example, code reviews are better at finding most instances of input validation issues (i.e. XSS or SQL Injection). All of the automated code scanning tools NetSPI uses trace the data within the application from its entry point to its exit point. A web application penetration test can find these instances but it could take days or weeks to prove they exist in the application.

Web application penetration testing
A web application penetration test can uncover vulnerabilities from the outside looking in. These vulnerabilities can be related to configuration or versions. An example might be an older version of Apache with a chunked encoding overflow vulnerability (http://osvdb.org/838). Web application penetration tests can also uncover vulnerabilities that are related to the operation of the application, such as default or easily guessed credentials. Other types of vulnerabilities found by a web application penetration test include:

  • Access control (forced browsing, etc.)
  • Session hijacking
  • Vulnerabilities related to business logic

In addition, web application penetration testing can find these instances easier than a code review. This being said, I am talking about a third-party code review, not a code review done by a person or person familiar with the code or the company’s development processes. Automated source code analysis tools do not find these types of vulnerabilities.  Manual testing can be done but could greatly inflate the cost of the code review.

Code Reviews
A code review looks at the application from the inside out. Vulnerabilities commonly found in a code review that cannot be easily found in an application penetration test include logging of sensitive data or application backdoors, as they are not exposed to the outside.  Other types of vulnerabilities found by a code review include:

  • Denial of services caused by not releasing resources
  • Buffer overflows
  • Missing or poor error handling
  • Dangerous functions
  • Hardcoded password or keys in the source code
  • Code implementation problems
  • Missing or poor logging

Look at the statistics
NetSPI has found through our own experience that only a small subset of vulnerabilities found by code reviews and application penetration tests overlap. In NetSPI’s analysis, only 18% of the overall vulnerabilities found were discovered in both the code review and the web application penetration test where both services were performed on the same application (see Code Review Percentages pie chart below). Of the vulnerabilities found in the web application penetration tests, only 14% of the findings are found by both the web application penetration test and a code review (see Pen Test Percentages pie chart below).

 sk_050510_charts

Final Thoughts
The most comprehensive approach to finding security vulnerabilities in web applications is performing both a code review and a web application penetration test. For critical applications, performing only one of these services can result in many vulnerabilities remaining within the application and unacceptable risk to the organization.

Permalink | Email the Author

Tags: , , , ,

What’s Happening in the Application Security Arena?

Steve Kerns | Thursday, January 7th, 2010

Application security attacks are increasing

According to Gartner, 75% of the attacks are coming though web applications and not through the network. This means greater emphasis needs to be placed on application security. However, this does not appear to be happening.

Application security vulnerabilities are increasing

For the first half of 2009, Cenzic identified about 3,100 total vulnerabilities, which is an increase of over 10 percent from the second half of 2008.  (http://www.cenzic.com).  Another revealing piece of data: WhiteHat Security has stated that in 83% of the 1,300 websites they scan have had at least one serious vulnerability (http://www.whitehatsec.com). Of the projects NetSPI has done in the application security area, 83% of these projects also had serious findings (serious vulnerabilities are those of HIGH, CRITICAL, or URGENT severity as defined by PCI DSS naming conventions).

What can happen if you do not fix the problems?

The first real risk is the theft of your data or your customers’ data. If applications are not done right, SQL Injection can allow a person (or persons) access to your database. Think TJX and all of the problems they had. Another risk is to your company’s reputation. Given the right situation, a user could be redirected to a site that is not under your control. It could be a porn site or even a site that looks like yours; it just exists to steal your users’ credentials. Your reputation will take years to repair, and the cost to your company may be insurmountable.

What can you do?

Many of the problems can be fixed by training. These do not have to be external training courses; they could just be brown bag lunches that cover specific secure coding techniques. A good place to start is the OWASP web site (http://www.owasp.org ). This site gives good information on detecting and preventing these vulnerabilities.

Perform code reviews and application vulnerability assessments on a regular basis. Code reviews need to be performed every time the code changes. Application vulnerability assessments need to be done at least annually.

By doing code reviews, and vulnerability assessments, you are helping both your company and your customers.

Permalink | Email the Author

Tags: , ,

How Good Are Your Application Security Assessments?

Steve Kerns | Monday, November 16th, 2009

Let’s talk about application vulnerability assessments, penetration testing, and code reviews. How effective they are depends on a number of factors: the education and experience of the testers, the tools used, the restrictions put on the testers, or even the environment in which the testing is done. This post focuses on the education and experience of the testers.

Consider the well-known recent case of the Heartland breach. Robert O. Carr, Chairman and CEO of Heartland Payment Systems, was quoted as saying the following: “In early 2008 we hired a QSA to perform a penetration test which found nothing. On April 30, 2008, we were deemed PCI-compliant” (http://www.infosecurity-us.com/view/4562/qsa-system-is-broken-says-heartland-ceo/).

I wonder if Heartland Payment Systems queried the QSA company on the background of the pen tester. Yes, the company was QSA-certified, but did the person or persons actually doing the penetration test have the education and experience needed to perform a pen test well? Not everyone does. This also goes for application vulnerability assessments and code review. Just because you hire a company that sells itself as having experts on staff does not always mean you get the top dog or even the middle dog. You might be getting a puppy. If the company performing the testing uses a team approach, the team’s collective knowledge might be as good as or better than that of the top dog.

Find out who will be performing your tests and get their resumes, or at least ask them about their background. What kind of training and experience do they have in this area? Are they right out of school or do they have at least a couple of years of experience? Does the firm employ a team of specialists? Is their work process mature and well defined?

These are not hard questions to ask or answer. Making this small effort could make a big difference in the effectiveness of your application security assessments, and your organization’s overall information security.

Permalink | Email the Author

Tags: , ,