OWASP Top 10

In this first series, we are going to explore the OWASP Top 10, one of the most important resources for developers and cybersecurity practitioners alike.

The Open Web Application Security Project (OWASP) is a nonprofit that produces resources to help make a more secure internet. It’s most popular resource is their list of top 10 internet application vulnerabilities — the OWASP Top 10.

However, it does have other resources to help ensure current and developing website and web applications are created with security in mind. These include:

• OWASP Juice Shop: The OWASP Juice Shop is a playground web application that is just chock full of vulnerabilities. Eventually, we will be exploring more of OWASP Juice Shop, so check back in later for an exploration of this fantastic resource.
• OWASP Zed Attack Proxy (ZAP): Another great resource from OWASP — though in this case a tool — is the Zed Attack Proxy, commonly referred to as “ZAP.” ZAP is like a swiss-army knife for web application security testing. Since it’s from OWASP, it’s open source, and since it’s open source, it’s free. Again, we will be exploring that here in the future.
• OWASP SAMM: A third useful resource is the Software Assurance Maturity Model (SAMM). SAMM is more like a reference that can be used to ensure that your app development is as secure as possible. As such, it is closer to frameworks like NIST CSF and ISO 27001.

With those other resources to check out, let’s jump into the Top 10.

OWASP Top 10: The List

The list is pretty straightforward. Even if you haven’t read the list, if you have read a few news articles involving hacks from the past you are likely to have heard of a few of these.

This is just a brief introduction: click the list link to get more information on each. Click the links in the descriptions for corresponding walkthroughs on CTFs and THMs.

1. Injection: The Injection security risk covers the gamut of different injection techniques, including SQL, NoSQL, etc. injections. The actual risk occurs when untrusted data can be entered into the database interpreter as part of a command or query. These untrusted commands can essentially trick the database into performing actions with the corresponding data that the database owner doesn’t want to allow, i.e. allow access to the data without the proper authorization.
2. Broken Authentication: When your app contains sensitive information and you set up login/authentication procedures to access it, you need to make sure that it is implemented correctly. When the authentication measures are not implemented correctly, an attacker can exploit the broken authentication and steal passwords, keys, session tokens, etc. They can also use that broken authentication to covertly assume another user’s (read: the admin’s) identity.
3. Sensitive Data Exposure: Closely linked to the above two, in general web apps and APIs often have problems placing the proper protections on sensitive data. Therefore, when an attacker is able to exploit a vulnerability, they will often have direct access to the sensitive data. Your web app should include levels of defense that an attacker has to get through in order to get to the sensitive data. This is referred to as “defense in depth.”
4. XML External Entities (XXE): Remember the ’90s? Back in the days when the internet was a “frontier” and not the fenced-off capitalist nightmare scape it is today, XML was a big deal. While the language is still used widely (the ability to define your own tags was and still is a big draw as compared to HTML) if it is not written in a secure manner it can be exploited, particularly when XML processors evaluate external entity references in XML documents. An attacker may mess with this data to trick the processor into incorrectly reading the XML data, which in turn may allow the attacker to view data they do not have proper authorization to view.
5. Broken Access Control: A core principal in security architecture is the implementation of access based on the principle of least privilege. In as simple language as possible, the principle of least privilege states that access rights should only be as expansive as required to finish a particular job. These access rights need to be properly enforced and reviewed on a regular basis as attackers can exploit improper enforcement measures to access data they should not be able to.
6. Security Misconfiguration: Out of the other nine items on the list, this is both the broadest item and the most commonly seen. Within your overall security architecture, security configurations need to be properly implemented. This is from the very base — making sure you actually do configure your app’s security from the start — to the continual updates, requiring you to make sure all aspects of the app are properly configured and vulnerabilities/patches are addressed as soon as they are discovered.
7. Cross-Site Scripting (XSS): Today’s web applications are more often than not a conglomeration of other sites’ tools mixed with the main content of the app. Cross-site scripting exploits the use of these other sites by injecting malicious code into already-vulnerable web applications to be carried out in your web app. This injection can be performed by loading the malicious script into a regular user’s browser who visits the compromised website.
8. Insecure Deserialization: As a short introduction, serialization is the process in which the data structures, which are often highly complex, are flattened into a smaller format that can be sent and received as a stream of bytes. This allows for quicker and simpler writing of the data to memory, storage, or a database as well as quicker sending of the data. Deserialization is the process of taking that smaller file and essentially unfolding it to have access to the full data. As will be detailed in the fuller Insecure Deserialization write-up, data should never be deserialized anywhere near a public face page or network; if it is, it allows an attacker to view the full data.
9. Using Components with Known Vulnerabilities: As we discussed above, modern web apps are often a mish-mash of different tools implemented into the barebones web app code. Even here on WordPress, there are APIs, widgets, etc. that can be used to spruce up a web app, page, or blog. Using those tools are well and good but you need to make sure that the components that are being used are as secure as possible: stay away from components that have published and known vulnerabilities, particularly those that have not patched those vulnerabilities. Bug-bounty, CVE sites, social media (particularly Twitter), and cybersecurity news sites are the places you want to keep bookmarked to make sure new vulnerabilities are not effecting your app’s components and, if they are, the component’s developers are actively patching the vulnerabilities.
10. Insufficient Logging & Monitoring: The final item in the list is not a vulnerability per se, but describes more of a lack of tools used to keep track of who is accessing your app’s data, when they are accessing it, and whether they should be able to access it. This is logging and monitoring; tools should be in place to ensure that suspicious behavior on your network is caught as soon as possible. As such, these tools come in greater use when an attacker has already gained access to your system: your job now is to stop them from further attacking the system, maintaining persistence, or interacting with the data in your system.

That’s all of them! Each of these items will have corresponding pages that go into greater depth on how they are used and how to defend against them. Check out the corresponding THM walkthroughs as well!