Getting Started With AppSec Using OWASP

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?

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.

What Are the OWASP Top 10 Vulnerabilities for Today?

The OWASP Top 10 was last updated in 2017, and comprises the following vulnerabilities A1-A10:

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

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. See an example of the page below:

The various sections on the page help you understand the importance and danger of each of the vulnerabilities.

Is the Application Vulnerable?

The section called Is the Application Vulnerable explains what it means for an application to have the vulnerability and what kinds of tools (DAST, SAST, etc.) are useful for finding that particular vulnerability.

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.

How to Prevent

The How to Prevent section is the most interesting IMHO. 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).

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.

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, A1 — “Injection” — is actually a broad set of things like SQL injection, command injection, LDAP injection, and more. Underlying this security weakness is the fact that user input isn’t sufficiently checked and sanitized before an application uses it.

Why Use OWASP Top 10?

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 checker/s support which items in the standard, and whether or not there are items in the standard that require more than static analysis (i.e. peer code review or software composition analysis).

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.

More Than DAST and SAST

One little thing to note is the item A9 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.)

Static Code Analysis Tools and Tips

The beauty of static analysis is that you don’t need to have the whole application or system finished, so 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 very 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 broken, 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 has helped by defining risk for each item in the Top 10 based on how easy it is to exploit a weakness, how easy it is for someone to find the weakness, and what the actual impact of the exploit may be. Use this helpful information to prioritize and triage your SAST findings:

The Power of Prevention

I’d like to emphasize something that is important if you want to truly harden your application. It’s very 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 is 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 is 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 is 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.

Summary

Getting OWASP Top 10 won’t be easy if you’ve never focused on security, but it is achievable, and it is a great place to start. 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 fully cover the standard, with both detection and preventative checkers.

Learn how to utilize OWASP risk scoring to help prioritize the findings and make sure your tools output this risk information with their findings. This will help you focus on what’s most important and is key to a successful OWASP implementation.

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.