Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 7 minutesWe 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.
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.
The OWASP Top 10 was last updated in 2017, and comprises the following vulnerabilities A1-A10:
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.
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).
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.
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.)
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:
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:
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.
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.
Arthur has been involved in software security and test automation at Parasoft for over 25 years, helping research new methods and techniques (including 5 patents) while helping clients improve their software practices.