How to Learn OWASP & Jumpstart Your Application Security

We continue to see large data breaches affecting organizations of all sizes. As cybersecurity problems continue and even increase in frequency and severity, we’re left to wonder, “Are we next?” and “What can I do about it?” That’s where OWASP comes in.

What Is OWASP Top 10 & Why Should You Learn It?

Most well-known for the OWASP Top 10, OWASP is the Open Web Application Security Project, an open community with free information and training about application security. The OWASP Top 10 is a list of common dangerous security risks for web applications, updated periodically to stay current. If you haven’t been doing much in the way of application security, or if what you’ve been doing is ad-hoc, the OWASP Top 10 is an excellent place to start.

Understanding OWASP’s Role in Web Application Security

OWASP, the organization, provides resources, guidelines, and tools to help web application developers identify, mitigate, and prevent security vulnerabilities. The OWASP Top Ten is a key resource the organization has been publishing since 2003. The intention is to get the developer community focused on key security problems and understand their impact.

The Importance of Learning OWASP for Addressing Security Risks

Understanding and implementing the OWASP Top Ten and other recommendations from the OWASP improves web application security since it helps eliminate the most common and critical security risks. Learning the root causes of these top ten vulnerabilities helps developers prioritize their efforts and focus on the highest risks. As an organization matures and embodies these practices, their web applications are more resilient to attacks, they reduce the risk of data breaches, financial losses, and damage to reputation.

OWASP Top 10 Vulnerabilities: What You Need to Know

The OWASP Top 10 comprises the following vulnerabilities A1-A10:

1. A01:2021-Broken Access Control
2. A02:2021-Cryptographic Failures
3. A03:2021-Injection
4. A04:2021-Insecure Design
5. A05:2021-Security Misconfiguration
6. A06:2021-Vulnerable and Outdated Components
7. A07:2021-Identification and Authentication Failures
8. A08:2021-Software and Data Integrity
9. A09:2021-Security Logging and Monitoring
10. A10:2021-Server-Side Request

OWASP provides documentation for the Top 10 with a webpage dedicated for each vulnerability. The page describes what each vulnerability is and provides a risk score, which is used to help prioritize and triage possible vulnerabilities. Here’s an example of the A03:2021 Injection web page:

The “Table of contents” on the top right provides guidance and helps you understand the importance and danger of each of the vulnerabilities.

Common Vulnerabilities in Web Applications

According to the OWASP Top Ten, the most common vulnerabilities are broken access control, cryptographic failures, and injection flaws.

Access control keeps users within their intended permissions in an application. However, these controls are often poorly implemented and easily bypassed. With higher than intended privileges, attackers can access private data or disrupt operations. Proper access control means implanting effective controls with a deny-by-default philosophy. Security testing needs to thoroughly address possible issues with access control.

Another common vulnerability is the lack of appropriate cryptography. Weak or complete lack of securing data in motion or rest often leads to data exposure. When cryptography is used, it sometimes uses weak encryption that has already been “cracked” by attackers. The key to prevention is keeping data secure when being transmitted with secure protocols and strong encryption when being stored. This also implies proper key management and updating encryption tools and methods as needed.

Injection attacks manipulate inputs to execute unauthorized commands. These commands can be used to expose confidential information. For example, an SQL injection attack can expose customer data. Weak login and session management can lead to unauthorized access, often leading to data exposure that speaks to a general problem of poor protection of confidential information.

How OWASP Addresses Insecure Design

Addressing insecure design is a new category in the OWASP Top Ten for 2021. It’s different in the fact that it focuses on the organizational issues related to web application security. It’s impossible to fix an insecure design in implementation, so the best approach is to introduce security early in the development process and throughout the life cycle.

Secure by design is an approach that includes threat analysis, risk management, secure design and coding practices, and ongoing security validation and verification. OWASP publishes the Software Assurance Maturity Model (SAMM) to help organizations align and mature their secure software development life cycle.

OWASP includes many recommendations to shift to a more secure development process. Key aspects include threat modeling, integrating security checks and language into user stories, and of course, establishing a secure development life cycle with outside AppSec professionals if needed.

OWASP Top Ten Details

For each of the Top Ten, there’s a dedicated page for each category of web application security issues.

Factors

The factors section shows the data associated with the category, such as the number of CWEs mapped, incidence rates, percentage coverage, number of incidents.

Overview and Description

The overview and description as expected, provide details on the vulnerability category. This is expanded from previous versions of the list.

How to Prevent

The How to Prevent section is the most interesting in my humble opinion. Security testing is important, but building secure code is the only solid foundation for strong application security. This section outlines various strategies that will help you shift left your security by not only testing earlier, but by building better code that is fundamentally less vulnerable to attack. This is the basis for a security-by-design approach, required by GDPR, for example.

Example Attack Scenarios

The Example Attack Scenarios section shows how an attacker might take advantage of each vulnerability. This information can be used to help build tests as well as educate the team on how software vulnerabilities affect application security.

References

Finally, each Top 10 item has a section with more information about each problem, approaches for avoiding it, and approaches for testing it. It also contains links that will lead you to related problems. This will be very useful as you work to continually improve your software security.

List of Mapped CWEs

The final section lists all of the CWEs mapped to the current category with links to MITRE’s CWE descriptions.

When reading the OWASP Top 10 documentation, you may find that some of the items are obvious from their name alone, while others require digging deeper to understand. For example, A01 Broken Access Control is actually a broader set of things like enforcing access controls, authorization testing, revoking access, and more. Underlying this security weakness is the fact that access failures can lead to unauthorized information disclosure, modification, or destruction of all data or performing a function outside the user’s limits.

Why Use OWASP Top 10 for Web Application Security?

There’s information, training, and advice in the OWASP Top 10. You can learn about common security problems as well as strategies to detect and even avoid some problems entirely. All of this information is available without cost and is constantly being updated and improved.

Compliance also means that we need to know exactly what specific item in our toolkit is supporting which specific part of the standard. In the case of static analysis, this means knowing what checkers support which items in the standard and whether or not there are items in the standard that require more than static analysis, such as peer code review or software composition analysis.

The Benefits of Secure by Design

Adopting security by design should be a top priority for web application development. Prevention through secure design and coding and implementing a secure coding standard are part of the solution. In fact, the latest OWASP Top Ten list has added the insecure design category to address these very issues. Security can’t be bolted on. It needs to be in the application from the beginning.

SAST tools play an important role in shifting security left, meaning applying security controls earlier in the development life cycle. SAST tools help prevent security vulnerabilities when used to enforce secure coding practices and standards. In addition, these tools can detect existing vulnerabilities whether in newly developed or existing code.

The payoff for secure design is considerable since security incidents, especially data breaches, are very costly. Security issues found in production or in deployed products cost several orders of magnitude more to fix than those found during development. Public data breaches that become news can cost companies millions of dollars.
Secure design also provides returns in terms of reputation and customer experience. Building in security from the beginning is a best practice.

How OWASP Helps in Identifying Security Risks

The OWASP Top Ten, first and foremost, provides awareness and a common language for the most common and risky web application vulnerabilities. As a list, it also provides prioritization and risk assessment for developers to consider. For example, injection flaws remain a critical vulnerability and should be a top focus for security design, coding, and when using scanning and penetration testing tools.

The Top Ten is also a good resource for training and helping organizations mature their security posture. Secure by Design and DevSecOps are all informed by the information and guidance provided by OWASP and resources like the Top Ten.

Beginning at the End

It’s easy—and dangerously common—for software development organizations to start security by beginning at the end using external, late-cycle, full-system testing such as penetration testing. I might call this something like DevTestOpsSec.

This testing is great for demonstrating that the application/system doesn’t contain any of the vulnerabilities enumerated in OWASP, sure. But this black box testing isn’t the most efficient way to actually produce code that is more secure. We don’t want to rely on black box testing as a way to secure our software or find bugs, as much as we want to use it to prove that the software is secure.

So, if the penetration testing finds a vulnerability, we need to ask ourselves, why? And try to address the root cause underlying the problem. This is when we move from a “test security in” to a “security by design” mentality. For this, you’ll find static application security testing (SAST) tools, such as static code analysis, with support for OWASP.

Tools & Strategies for Satisfying OWASP

One little thing to note is that item A06 in the OWASP Top 10 is completely different than the rest and doesn’t lend itself to SAST or DAST because it’s about looking for known vulnerabilities in open source, not finding new vulnerabilities.

Luckily OWASP has a free tool for this called OWASP Dependency Check. This tool identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities, and can be used to scan applications and their dependent libraries to identify known vulnerable components.

If you’re using Parasoft, we actually integrated OWASP Dependency Check into our reporting system and made it part of the OWASP Top 10 Dashboard. This makes it easy to handle issues in your open source components by scanning as a regular part of your CI, along with SAST, and putting the results into a unified dashboard with the rest of your OWASP information. With this approach, instead of being a separate orthogonal process, A9 is integrated with the Top 10 as it should be.

DAST and SAST: Tools for Satisfying OWASP

Application security testing tools support the necessary activities to prevent the vulnerabilities listed in the OWASP Top Ten. As such, making use of a combination of these tools is a best practice for software developers.

SAST tools analyze code “at rest” and can be applied very early in the software development life cycle. Their strength is in detecting software weaknesses and insecure programming as code is written. They are also excellent for enforcing secure coding standards like SEI CERT. SAST tool vendors often have configurations for the OWASP Top Ten and document how their tool can be used to address these top vulnerabilities.

DAST tools, on the other hand, are used when an application is running. They detect vulnerabilities as they occur and with very high precision. DAST tools are used during testing to detect bugs and vulnerabilities that might be missed from test results alone.

How to Use OWASP Guidelines for Secure Code Analysis

The OWASP Top Ten helps guide application security testing and code analysis by providing a prioritized list of the most critical web application security risks. Developers and security teams can review their code with these risks in mind, ensuring that they address and mitigate vulnerabilities related to these top ten issues

Static Code Analysis Tools & Tips

The beauty of static analysis is that you don’t need to have the whole application or system finished. You can start checking for security problems much earlier in the cycle to shift left security testing. If you’re doing security late or near the end of your development (DevOpsSec), you can use static analysis to push security earlier, before testing even begins, while the code is actually being written (DevSecOps).

The ugly side of static analysis is that it has a reputation for being very noisy, for example producing hundreds or even thousands of violations right when you thought you were ready to release. Luckily, there are some good strategies for dealing with this. Here are a few things to keep in mind:

• Don’t save security testing until the end. Start running static analysis as soon as you start coding. If you wait and only run it as part of your CI/CD pipeline, then the findings will pile up and overwhelm your development team. Run it on the desktop to find problems, and run it in CI/CD to simply verify that the code was built properly
• Fine-tune your configuration. Some static analysis checkers may not be needed in the context of your code. Check your application and determine which security risks matter for you and only work on those. Never look for issues you don’t plan on fixing.
• The age of the code matters. “If it ain’t broke, don’t fix it” should apply to legacy code. Only run the most critical security scanners against older code. Minor issues will waste your time and these changes bring their own new risk. Never check code you don’t plan on fixing.
• It’s all about risk. SAST tools find both real vulnerabilities as well as potential ones. Not all findings have the same potential risk. OWASP Top Ten helps developers focus on the highest priority issues first. With the help of SAST tool mappings to OWASP Top Ten vulnerabilities, it’s best to prioritize and triage your SAST findings.

The Power of Prevention in Learning OWASP

I’d like to emphasize something that’s important if you want to truly harden your application. It’s easy to test for security, but more difficult to build for it. Luckily, static analysis checkers come in different flavors. Some checkers look for typical problems like tainted data and try to figure out if there’s a flow in the application where it could happen. These are the most common checkers in many SAST tools.

But the bigger value in static code analysis lies in checkers that enforce two special things:

1. A pattern that’s frequently associated with problems in the past. While this may not be as interesting looking as a specific stack trace to an exploit, it can be much more thorough to simply fix everything that’s weaker than it should be than to only fix issues that have a proven attack vector.
2. Requirements of specific types of coding to ensure proper functioning. Automotive and aircraft standards like MISRA and JSF rely on this technique to ensure functional safety. The same technique of requiring good code in addition to flagging bad code will help you build applications that are more secure.

Ironically, this is the approach that safety-critical industries have used for decades with hardware and software, but somehow in cybersecurity we think we can test security into an application and don’t need to focus on building secure code. Leverage the full capabilities of proactive static analysis, in addition to early-detection checkers, to get the most value.

Building Secure Code: Best Practices From OWASP

The best practices we can learn from the OWASP Top Ten are written into the list itself. For example, the key to preventing injection flaws is to properly validate all input into the application. In addition, the following best practices are needed.

• Keep data separate from commands and queries.
• Use safe APIs.
• Use positive server-side input validation.
• Use LIMIT and other SQL controls within queries.
• Ensure appropriate access control.
• Secure data in transit and at rest.
• Adopt security by design.
• Ensure secure configurations.
• Ensure software supply chain security.
• Ensure software integrity.
• Ensure security logging and monitoring.

How Learning OWASP Can Help in Risk Assessment

The OWASP Top Ten provides an ordered list of the highest-risk web application security vulnerabilities. Given this, web application developers are armed with the information they need to assess security risks as they arise. The priority of security incidents or detecting vulnerabilities during development can be prioritized based on their place on the list. All of the Top Ten are critical, but developers need to focus first on the most common and highest risk

Summary: Your Next Steps to Learn OWASP

Getting started with OWASP Top 10 won’t be easy if you’ve never focused on security, but it is achievable. DAST is a simple way to get started with the Top 10, and then using SAST will help you shift your security testing left. Implemented properly, SAST can even prevent problems, not just detect them, so look for tools that cover every item on the list, with both detection and preventative checkers.

Building Security Into Your Application From the Start

Web application developers can build security into their applications from the start in the context of the OWASP Top Ten by:

• Understanding the risk. Be aware of common vulnerabilities.
• Following secure coding practices. Secure coding that mitigates the top ten risks.
• Training regularly. Development teams need to learn secure coding and OWASP best practices.
• Testing security. Perform continuous security testing, including static and dynamic analysis.
• Performing code reviews. Regular code reviews with a security focus.
• Adopting security by design. Security can’t be bolted on later.
• Using threat modeling. Identify potential security weaknesses and address them in the architecture.

The key theme is integrating security measures into the development process from the outset, being proactive, and prioritizing mitigation with the risk assessment outlined in the OWASP Top Ten.

With these tips, you should be ready to start eliminating the most common and dangerous web application security risks today.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.