How to improve project security with OWASP?

OWASP stands for the Open Web Application Security Project, a non-profit organization, whose goal is to improve… Yes, you guessed it, web applications’ security. As this international community produces documentation, tools, and methodologies which are to raise awareness of the present-day security threats, today, I’d like to discuss what you can learn from the OWASP resources and how to incorporate this knowledge into your project.

Before we dig deeper into OWASP Top 10, you might be interested to read about the importance of documentation in IT security.

OWASP Top 10

One of the most well-known (if not the best known) resources brought to you by the organization is the OWASP Top 10. The list showcases ten most critical threats to web applications as selected by the project’s team who take into consideration four factors: ease of exploitability, detectability, prevalence, and impact on business.

According to the community’s website, “using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code”. While I won’t deny that this list is a useful tool indeed, I must admit that due to its ever-growing popularity, OWASP Top 10 has been painfully misunderstood. Before I explain what I mean by that, let me first go through the list – it’s possible that you’ll arrive at the same conclusion already when getting acquainted with these risks.

OWASP’s Top 10 security risks as of 2020

• Injection – a situation whereby the system interprets user input as a part of a command.
• Broken Authentication – a vulnerability that allows attackers to bypass login procedure or leak passwords and tokens.
• Sensitive Data Exposure – this one is quite self-explanatory: an unauthorized person gets access to sensitive, private data that can be later used for nefarious purposes.
• XML External Entities (XXE) – parsing is hard and XML parsers tend to have security flaws, one of which is including external data through XML documents.
• Broken Access Control – if access boundaries are not properly enforced, users – including attackers – may get access to other users’ data and perform actions available to a certain function only, e.g. that of an administrator.
• Security Misconfiguration – this vulnerability encompasses wrong access control, wrong usage of external APIs, and HTTP headers that allow too much. A practical example is that of an excessively lenient Same Origin Policy.
• Cross-Site Scripting (CSS/XSS) – the 7th threat on the list means that unauthorized JavaScript code can be executed within our application’s context.

How about finding out how to deal with XSS using Content Security Policy?

• Insecure Deserialization – one of the most interesting flaws. Why is that? Because insecure deserialization may lead to code execution on the server when data parsers misbehave (or are misconfigured). An example of such a breach may be CVE-2017-5941 which caused troubles on NodeJS servers.
• Using Components with Known Vulnerabilities – whenever external libraries are used, they need to be monitored and upgraded to the latest available versions compatible with our systems in order to protect the application.
• Insufficient Logging and Monitoring – some breaches may be silent and remain undiscovered. The sooner we see that something is happening, the quicker will we be able to react and stop the cracker.

Now that I’ve introduced you to OWASP Top 10, it’s worth mentioning that some attacks can occur simultaneously. For example, we could use a library with a known flaw thinking that it’s only used on an endpoint to which only trusted users have access. In fact, however, an attacker could be able to exploit some deserialization bug in this library, get access to sensitive data and, due to insufficient monitoring, we’d never know about it until our database appears on some darknet forum. Can you see what I’m getting at?

Is OWASP Top 10 enough, though?

As you’ve probably realized by now, the first issue that I have with this list is that it gives a false sense of security. Being secure against the top 10 problems does not mean that you’re secure at all. Your application may have a critical flaw categorized as the 11th problem by OWASP so paying attention to the selected set of problems only can easily leave you with a huge hole.

There’s also another problem; namely, there are plenty of companies that create things like “OWASP Top 10 certificate”. By doing so, they suggest that it’s enough to check against this selected set of threats and encourage treating security as a one-time event rather than introducing it as a regular practice. And nothing could be further from the truth in software development.

Learning materials brought to you by OWASP

Having covered OWASP Top 10 and my concerns regarding the list, I’m glad to tell you that Open Web Application Security Project is a true goldmine of useful security-themed resources of all kinds. The most valuable ones, in my opinion, are those focusing on learning. Truth be told, they are fundamental for making the first step in the world of infosec and hardening projects. Here’re two examples of what OWASP offers in that respect.

OWASP Wiki

If you’re looking for loads of theory, OWASP’s wiki is the place to go. Let’s say, you want to understand SQL injections better. You’ll find there are pages telling you what type of threat it is, how to properly secure your application against it, and how to identify and exploit it. Is there anything more you can wish for?

WebGoat

Actually, there is more. The theory is like the armor but it’s the practice that acts like the weapon which will ultimately defend you and your product. So in order to sharpen your (or your developers’) skills, OWASP has prepared a deliberately insecure application called WebGoat. Using it, you can learn how to look for vulnerabilities, how to exploit them, and to what extent they compromise the system. After all, it’s cool to find a security defect but it’s also crucial to assess its potential impact.

An example of a WebGoat assignment

For example, a CSRF that allows for changing someone’s avatar is not something that sounds alarming. But if it’s followed by granting the attacker the ability to upload and execute arbitrary code, it might become critical. Being able to identify such interconnected problems is something that requires a lot of practice – and WebGoat helps to get in it.

Don’t be wise after the event. Learn from others’ mistakes and treat security seriously from the very beginning.

Threat modeling

Having identified loopholes within the project, it’s worth knowing how to put these issues into words that business understands. To help them properly prioritize means, OWASP has prepared general guidelines that foster informed decision-making as far as security issues are concerned. Although it doesn’t go very much into details, it’ll help you understand what “threat modeling” is and search for further resources. If you need something more descriptive, please refer to this chapter in the Web Security Testing Guide, which I’ll cover in the next paragraph.

For now, however, let me emphasize that explaining the matter to business and including them in the process is crucial for the success of the project. On one hand, developers get a chance to work on their security-related skills and improve the quality of the project they’re working on. On the other hand, people responsible for sticking to the budget are not kept in the dark – they can feel they’re actually involved in the process and make more conscious decisions. Needless to say that this benefits developers who don’t have to struggle with misguided ideas resulting from a lack or insufficient amount of knowledge on the security topic.

Web Security Testing Guide

Once both developers and all CxOs are on the same page, it’s time to implement an organized approach towards security within the existing workflow. That’s where the OWASP testing guide steps in. It contains a detailed description of everything you need to know about testing. If the previous points discussed the “what” and “why” of security, this is dedicated to the “how”.

A typical software development life cycle testing workflow

If you still feel unsure about how the threat modeling should look like, you’ll find the answer here. If you don’t know at which stages you can do something to improve the security, you’ll find out here. From source code review to penetration tests, it’s all in the Testing Guide.

Summing it up: get to know OWASP and use it wisely

My aim today was to show you the value of OWASP and its materials from both developer’s and project manager’s point of view. Together, we went through the basics, the whys of the actions that should be undertaken to improve the app’s security, and the resources to introduce them to your daily routine. By now, you should have also understood my skepticism towards OWASP Top 10. It all boils down to the fact that solutions have to be adjusted to the needs and resources available. Maybe the scale doesn’t require thorough penetration tests or maybe the budget doesn’t allow it and you can put more effort into a different area – like QA manual testing – to achieve similar results. As is always the case in software development, it all depends on the project.

Every application calls for taking a different set of security precautions. Consult our experts to find out which ones suit your needs best.