NetSPI Blog

Posts Tagged ‘code reviews’

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: , , , ,

Are We Ready for a Security Software Assurance Program?

Seth Peter | Monday, October 5th, 2009

Integrating security checks and balances with your application development processes is certainly uncharted territory for many security professionals. Why is this so? With the multitude of benefits that custom developed applications bring to an organization, there is also a multitude of risks, namely that sensitive, regulated, and confidential data is being stored, processed, transmitted, and exchanged inside and outside the boundaries of the organization. Why don’t we have a better handle on these risks? I think that we as security professionals have missed an opportunity to embed security in the development process. Let’s begin to understand why this is and how we can go about changing it.

Step back a few years to when your security program was just really getting off the ground. Developed applications were supposed to just work right. Applications either met design specs or they didn’t; wasn’t it that simple? Why did security need to be involved? Back in the day, applications were always quarantined behind the firewall, and business partners only received data via a data exchange solution. Out of scope for security, right?

Now, fast forward from the days of firewalls and anti-virus concerns and take notice: everyone who has any reason to access your data can, from anywhere, anytime. Sure, you’re protecting it with a strong password, maybe even two-factor authentication, a VPN, or rock-solid acceptance and confidentiality agreements. You’re conducting vulnerability scans on the DMZ nightly, right? Would you ever dream of scanning that application nightly? In production? Are you crazy? That might cause an outage. But hold on, and consider what else you may be missing.

Good application security practices require security checks and balances throughout the entire lifecycle, not just a security assessment at the end of the line. These checks and balances include things like secure coding standards, developer training, well-defined security requirements, security code reviews, the use of sanitizing test data, separation of duties, security testing during development checkpoints, security use case testing, and penetration testing. So, if that’s where we need to be, how do we get there? Is the answer Security Software Assurance Programs? They sound like a great concept, prescriptive programs that include everything from A – Z for application security; all you need to do is implement it and watch the needle on the risk meter drop.

Let’s get real. Budgets are tight, development timelines are tight, and security programs are underfunded. Can you realistically launch a massive and invasive security program? Once again, I think we missed an opportunity somewhere between the 1990s and now to ensure that security and application development work in tandem.

So what do you do now? I suggest you think big, but start smart. Pick two or three obvious pain points and start there, e.g., with more testing or better requirements. If there is one thing to get in there sooner than later, start training your development leads (literally, scare the daylights out of them). Keep in mind, you will need to turn this into a full-on program, so begin working towards it, but begin by re-acquainting yourself with your developers and providing them with some high value wins. Help them find security issues in-house before someone else does.

Permalink | Email the Author

Tags: , , , ,

Application Security-An Introductory Post

Paul Johnson | Wednesday, July 15th, 2009

NetSPI is embarking on an initiative to provide opinions and insight to security practitioners in the form of periodic blog entries covering four specific subject areas, one of which is Application Security. Entries in this blog category will be provided by members of NetSPI’s Application Security team and will include commentary on application security testing products, analysis of recent exploits, and our perspective on developing trends in application security.

The team, which consists of developers and pentesters with extensive experience across several industries, will draw on a wealth of experience: we test hundreds of applications for security vulnerabilities every year. The work done by the team includes application vulnerability assessments, penetration tests, architecture reviews, code analyses, and SDLC evaluations. This experience has given us a great perspective on where application controls are missing or fail, as well as the root cause of failures.

Our goal for this blog is to contribute content on application security that will not only be of interest, but that will have real value for you in protecting information assets. We welcome your suggestions and feedback.

Permalink | Email the Author

Tags: , , ,