Security testing of web applications through the use of testing software is generally broken into two distinct types of automated testing tools.
This section looks at these tools and discusses the importance of penetration testing, which generally includes the use of human expertise and automated tools.
The section also looks at secure code reviews and OWASP recommendations for security testing
Static Application Security Testing
Static application security testing (SAST) is generally considered a white-box test, where the application test performs an analysis of the application source code, byte code, and binaries without executing the application code.
SAST is used to determine coding errors and omissions that are indicative of security vulnerabilities.
SAST is often used as a test method while the tool is under development (early in the development lifecycle).
SAST can be used to find XSS errors, SQL injection, buffer overflows, unhandled error conditions, and potential backdoors.
Because SAST is a white-box test tool, it typically delivers more comprehensive results than those found using the test described in the next section.
Dynamic Application Security Testing
Dynamic application security testing (DAST) is generally considered a black-box test, where the tool must discover individual execution paths in the application being analyzed.
Unlike SAST, which analyzes code offline (when the code is not running),
DAST is used against applications in their running state. DAST is mainly considered effective when testing exposed HTTP and HTML interfaces of web applications.
It is important to understand that SAST and DAST play different roles and that one is not better than the other. Static and dynamic application tests work together to enhance the reliability of organizations creating and using secure applications.
Runtime Application Self-Protection
Runtime application self-protection (RASP) is generally considered to focus on applications that possess self-protection capabilities built into their runtime environments, which have full insight into application logic, configuration, and data and event flow.
RASP prevents attacks by self-protecting or reconfiguring automatically without human intervention in response to certain conditions (threats, faults, and so on).
Vulnerability Assessments and Penetration Testing
Both vulnerability assessment and penetration testing play a significant role and support the security of applications and systems before an application going into and while in a production environment.
Vulnerability assessments or vulnerability scanning look to identify and report on known vulnerabilities in a system.
Depending on the approach you take, such as automated scanning or a combination of techniques, the identification and reporting of a vulnerability should be accompanied by a risk rating, along with potential exposures.
Most often, vulnerability assessments are performed as white-box tests, where the assessor knows that application and the environment the application runs in.
Penetration testing is a process used to collect information related to system vulnerabilities and exposures, with the view to actively exploit the vulnerabilities in the system.
Penetration testing is often a black-box test, in which the tester carries out the test as an attacker, has no knowledge of the application, and must discover any security issues within the application or system being tested.
To assist with targeting and focusing the scope of testing, independent parties also often perform gray-box testing with some level of information provided.
Within cloud environments, most vendors allow for vulnerability assessments or penetration tests to be executed. Quite often, this depends on the service model (SaaS, PaaS, IaaS) and the target of the scan (application versus platform).
Given the nature of SaaS, where the service consists of an application consumed by all consumers,
SaaS providers are most likely not to grant permission for penetration tests to occur by clients.
Generally, only a SaaS provider’s resources are permitted to perform penetration tests on the SaaS application.
Secure Code Reviews
Conducting a secure code review, whether informally or formally, is another approach to assessing code for appropriate security controls.
An informal code review may involve one or more individuals examining sections of the code, looking for vulnerabilities.
A formal code review may involve the use of trained teams of reviewers that are assigned specific roles as part of the review process, as well as the use of a tracking system to report on vulnerabilities found.
The integration of a code review process into the system development lifecycle can improve the quality and security of the code being developed.
OWASP Recommendations
OWASP has created a testing guide (presently v4.0) that recommends nine types of active security testing categories as follows:23
- Identity management testing
- Authentication testing
- Authorization testing
- Session management testing
- Input validation testing
- Testing for error handling
- Testing for weak cryptography
- Business logic testing
- Client-side testing
These OWASP categories play as well in a cloud environment as they do in a traditional infrastructure.
However, additional threat models associated with the deployment model you choose (such as public versus private) may introduce new threat vectors that require analysis.
