Today, software development and security testing have become a significant technical challenge. The immense rise of web applications that enable businesses, networking, etc., requires a robust approach for writing and securing the internet, web applications, and data. OWASP and OWASP top 10 are essential in securing web applications and data.
Security testing is essential when developing web applications. However, many organizations overlook this integral component of the Software Development Life Cycle (SDLC). This OWASP Web Security Testing Guide covers the OWASP testing framework, its scope, the principles of successful testing, and its techniques. It also covers reporting best practices and testing for specific vulnerabilities via code inspection and penetration testing.
The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to web application and software security. The OWASP guide helps set a security standard for developers and practitioners worldwide. They can use the OWASP standard as guidelines for security testing and code review while developing web applications.
The OWASP offerings, including everything from online tools and videos to forums and events, are free and easily accessible through its website. It sets forward an “open community” model under which anyone can participate and contribute to OWASP-related online chat, projects, etc.
Creating a guide like this that covers all the crucial aspects of SLDC security is an undertaking task and requires the expertise of people around the world. One of the crucial factors of the OWASP guide is that it is open and easily accessible for anyone involved in the web application development process.
It captures the consensus of leading experts around the world, and the OWASP community can evolve and expand with the increasingly evolving application security threat landscape. It helps guide developers and practitioners on how to perform security testing quickly, effectively, and efficiently.
Among the main benefits of OWASP, we can highlight the following:
Following the OWASP guide is essential for anyone involved in web application development. Different roles in the organizations can use this guide:
While this guide covers different techniques to identify security holes, it should not be considered a complete checklist as new vulnerabilities are always popping up, and organizations can use this guide as a good place to start.
The OWASP Top 10 report consists of the ten most critical web application security risks. The image above highlights the new installment of the OWASP Top 10 2021 report. This list includes the most recent update that occurred in 2021.
According to the new list, three new categories have been added. The risks added are ranked based on security defects, their frequency to occur, the severity of vulnerabilities, and potential impacts. Developers and security practitioners can use this report to get an insight into the most prevalent security risk so that they can minimize the presence of known risks as much as possible while developing web applications.
1. Broken Access Control (A01:2021)
Moved to number 1 from number 5 in the 2021 report based on severity, broken access control is among the top security weaknesses that can aid in accessing user accounts by attackers. This risk had more occurrences in the applications than in any other category.
2. Cryptographic Failures (A02:2021)
Previously known as sensitive data exposure, shifts up to 2nd position depicting failures related to cryptography. This category sheds light on the risk when sensitive data is exposed and compromised during application development.
3. Injection (A03:2021)
Injection falls to number 3 from number 1, comprising cross-site scripting as part of this category. It occurs when an attacker injects an invalid data code into a web application to make it do something it was not designed to do.
4. Insecure Design (A04:2021)
Insecure design is a new category added to the OWASP top 10 2021 report and focuses on risks related to design flaws. For an industry trying to “shift left”, threat modeling, secure design patterns, and principles may not be enough.
5. Security Misconfiguration (A05:2021)
Unsurprisingly, security misconfiguration moves up to the number 5 position as “90% of applications were tested for some form of misconfiguration. It occurs from configuration errors or shortcomings. XML External Entities (XXE) is being added to this category now.
6. Vulnerable & Outdated Components (A06:2021)
Previously known as using components with known vulnerabilities, vulnerable and outdated components move up from number 9 to 6 and focus on the components underlying known and potential risks. Also, outdated components must be evaluated for risks.
7. Identification & Authentication Failures (A07:2021)
Previously known as broken authentication, this category has shifted from number 2 to 7 but remains an integral part of the OWASP Top 10. It includes CWEs related to identification failures that result in compromised passwords, keywords, and sessions, leading to identity theft.
8. Software & Data Integrity Failures (A08:2021)
Introduced as a new category in 2021, it highlights assumptions without verifying integrity related to software updates, critical data, and CI/CD pipelines. Insecure deserialization is now a part of this category.
9. Security Logging & Monitoring Failures (A09:2021)
Previously known as Insufficient Logging and Monitoring, this category has shifted up from number 10 to 9 and includes more types of failures that are challenging to test and aren’t represented in the CVE/CVSS data. Failure in this category can result in more severe compromising activities.
10. Server-side Request Forgery (A10:2021)
Added as a new category in the OWASP Top 10 2021, Server-side Request Forgery (SSRF) focuses on the severity and incidence of SSRF attacks.
The OWASP Testing Project is built with the expertise of leading experts from all around the world. The main goal of this testing framework is to provide knowledge about when, how, where, what, and why of testing the security of web applications.
You can use this framework and adjust it according to your testing requirements. It helps organizations test web applications to build secure software. Go through the complete guide to have a better insight into the OWASP testing framework
The OWASP Testing Project clears some significant misconceptions about developing a testing methodology. It puts forward some basic testing principles for professionals when performing security tests on software.
Metrics are not easy to develop. However, using a standard such as the IEEE can prove to be beneficial in the start.
Organizations can adopt different testing techniques to build security testing programs according to their requirements. In this section, we will mention four techniques along with their advantages and disadvantages.
Manual inspections are human reviews that play an essential role in testing security techniques in the organization. They help analyze the people, policies, processes, and technology decisions with the help of documentation and interviews.
Manual inspections are one of the powerful and effective testing techniques that help by asking people different questions at different levels of testing. It can help understand whether people follow security measures, understand security protocols, or have the skills to design secure applications or not.
However, a trust-but-verified model must be adopted as nothing told to the reviewer can be accurate, and there are chances of errors.
Threat modeling is a technique designers use to predict threat attacks or how malicious attackers can harm the application or computer system. It is a cost-effective method to integrate security in the design phase (can be implemented in other phases too) of SDLC. All applications must develop and document a threat model.
OWASP recommends taking an approach that simply follows the NIST 800-30 standard for risk assessment. This approach will involve:
Source code review is a process of examining the source code of web applications to identify security errors in it. Testing web applications require the availability of the source code for testing purposes. This technique is most liked by experts. They agree on the fact all necessary information is present in the code and can help identify security vulnerabilities.
According to OWASP experts, any other form of analysis or testing can not detect serious security issues better than this technique. Many problems are hard to discover with other methods.
Also known as black-box testing or ethical hacking, penetration testing is a technique to test networks or applications for security vulnerabilities. In this technique, the penetration test team acts as the user of applications, and the tester attacks the system or application to exploit security vulnerabilities.
While penetration testing is an effective technique for networks, it may not prove to be beneficial in application security. Also, organizations must not use it as a stand-alone technique for security issues. “In practice, a penetration test can only identify a small representative sample of all possible security risks in a system.” wrote Gary McGraw in Software Penetration Testing.
With so many security testing techniques and processes for web applications, it sometimes becomes challenging to choose a proper technique and determine when to use it. There are no right or wrong techniques for security testing; instead, every phase of SDLC requires a different technique.
While there are different processes for each phase, organizations mostly rely on penetrating testing that may not be enough for web application security. No single technique is enough to address and resolve security vulnerabilities.
The right approach for security testing is a balanced approach consisting of several techniques. From manual review to source code review to CI/CD pipeline testing, a balanced approach must include testing at all phases of the SDLC.
There will be times and situations where only one process will be possible. Also, security testing techniques vary in different projects. The following image consists of the right proportion of test efforts according to test techniques in the SDLC.
You must know the testing objectives to have a successful security testing program. Security requirements specify these objectives. In this section, we will discuss the testing objective and how you can document requirements by deriving them from applicable standards and regulations.
One of the objectives of security testing is the validation of security control if they work as expected or not. Security requirements help document the functionality of the security control. Another objective of security testing is to implement security controls with no or few vulnerabilities. The OWASP Top 10 mentions some of these vulnerabilities and other vulnerabilities identified previously during risk assessments in the SDLC.
Understanding business requirements is necessary to document security requirements. For example, if any business wants to provide financial services or deals with online transactions, the security section for its services will highlight the need to secure customer data. Also, the need to comply with applicable security standards or regulations.
Compliance with regulatory industry standards is the first step towards achieving security. For instance, a company that handles credit card data of customers needs to comply with the PCI-DSS regulation. According to this regulation, any company handling credit card information can’t store PINs and CCV2 data.
These regulations are necessary for companies handling customer data and require security validation via testing and documentation.