This tip is part of SearchSecurity.com's Security School lesson, Web application attacks: Building hardened apps....
For more learning resources, visit either the lesson page or the Security School course catalog page.
Web application security assessments often fail to produce meaningful results, leaving enterprise security teams scratching their heads about what went wrong. Some are quick to blame the tools in use, others blame lack of application security training and talent in the information security team, and many cases, the assessment is treated like a checklist item that is given little time, planning or forethought.
Web application security assessments need to get close enough to the application to develop a threat model, look for common vulnerability patterns, and customize their approach based on an evaluation of the technologies rather than using a one-size-fits-all approach. In this tip, we’ll explore each of these points.
Does your Web application security assessment start by getting a grasp of the business purpose and justification for why the application exists in the first place? Unless you can clearly state what the application requirements and expectations for performance are, you can't begin to assess it for vulnerabilities. After all, what may seem like a broken function may actually be an intended feature; what appears to be sluggish performance may be perfectly normal.
Don't let the application development team bury you in jargon or cryptic acronyms; if you don't know what something means, ask. Developers often forget that the Web application security assessment team is missing context that has already been established within their group. Get out the whiteboard and draw out the system as you understand it, and let them correct you or add that context.
Once you have a good understanding of the application, build a quick threat model. The following questions will help you to determine which vulnerabilities have meaningful effects on the application.
- Who is likely to attempt to abuse this application? Anonymous users on the Internet? Your customers? Internal users?
- Where is the trust boundary and what attack surface is exposed to untrusted or semi-trusted users?
- What assets are worth protecting? Common assets include the integrity of the application's data, availability of the service, the confidentiality of user or company data, or the underlying operating system or network. Don't forget about client-side threats, where user sessions and browser integrity can be targeted.
- What incidents have taken place in the past and what concerns keep the application team up at night?
- What security requirements were important enough to be documented, and more importantly, what requirements were assumed or implied without being documented?
Web applications often share a set of "deadly features" that have a common and frequent pattern of vulnerabilities that usually are platform-independent. Things such as file download and upload, custom session management, authorization and access control, homegrown single sign-on, password storage and reset mechanisms, email functionality and search functionality often have critical flaws because of the subtle complexity required to implement them safely. Make sure you identify these potential problem areas when you assess an application, as they are likely to require careful attention.
An assessment approach should be customized to the situation at hand. If the application is a third-party product where source code is not available, dynamic vulnerability analysis with tools may be the preferred approach, and if the application has a high-risk posture, manual penetration testing may be the logical next step.
Where source is available, work hand-in-hand with the development team to use source code analysis tools to look for vulnerabilities. Don't just throw Web application security assessment tools over the wall and ask developers to run them. Get feedback on each tool's strengths, and invest time in learning how to set tools up effectively to get sufficient coverage. Quickly throw out classes of findings that are not relevant to your threat model or prone to false positives when you first starting using static code analysis tools to avoid fatigue.
When using dynamic analysis tools such as Web application vulnerability scanners, make sure the tool "understands" your application as much as possible, including where all the application endpoints are and what functionality exists. Too many people rely exclusively on a tool's capabilities to discover content and test it effectively without verifying the most sensitive parts of the application are covered.
Manual penetration testing should be considered for high-risk applications, sometimes in conjunction with code review or dynamic analysis. Leverage your penetration testing resources to look for things that are difficult to automate, such as threats targeted at data leakage, authentication and authorization bypass, and cryptographic vulnerabilities.
When putting this approach together, realize that organizational change takes time. People that are used to steamrolling through the assessment process may be hesitant at first to dedicate the necessary time to produce a meaningful Web application security assessment. A step-wise approach that shows the value for time spent incrementally will often break down some of the defensive barriers.
About the author:
Cory Scott is a San Francisco-based director at Matasano Security, an independent information security research and development firm.