What is OWASP?
The Open Web Application Security Project (OWASP) is a community-led nonprofit foundation committed to improving the security of software. For 20 years OWASP has been a repository for web application security resources including documentation, tools, videos, and forums, all of which are freely available and accessible via their website. One of OWASP’s best-known projects is the OWASP Top 10.
What is the OWASP Top 10?
The OWASP Top 10 is a web application security awareness document that outlines the most critical security risks to web applications based on data submissions from security firms. The primary purpose of the document is to educate developers, designers, architects, managers, and organisations about the consequences of the most common and important web application security weaknesses.
The current OWASP Top 10 web application security risks are:
1 – Injection
A code injection attack occurs where an attacker transmits carefully crafted data through an input field or other data entry point to change the way the application code behaves when executed. One of the best known attacks of this kind are SQL injection attacks, where an attacker can enter SQL database code into a submission field that expects plaintext input. If the malicious input is not correctly sanitised when processed, the SQL code could be positioned within the SQL query and can change the query’s syntax and function. This could allow the attacker to perform unauthorised actions such as data exfiltration and the creation/deletion of database entries.
Injection attacks can be prevented by validating (rejecting data that looks suspicious) and/or sanitising (cleaning unnecessary input characters and suspicious-looking parts of the data) user submitted data. For SQL injection specifically, developers can ensure that all input for SQL queries is parameterised so that the injected input cannot be used as part of the query syntax.
2 – Broken Authentication
Vulnerabilities in an application’s authentication mechanisms can allow attackers to gain unauthorised access to user and potentially even admin accounts. For example, if the authentication mechanism permits automated attacks such as brute force (where the username and password are unknown), password spraying (where the username is known but the password isn’t) and credential stuffing (trying known username/password pair, often found through breached credential databases), the attacker could potentially gain unauthorised access by trying a range of credential combinations.
It can be a challenge to perfect your authentication mechanism security but some effective measures to focus on include ensuring that a strong password policy is implemented, that 2FA is enforced and that rate limiting controls are optimised to prevent automated attacks.
3 – Sensitive Data Exposure
Sensitive data exposure can occur when data is not securely obfuscated (i.e., encrypted/hashed) when in transit or at rest. For example, where passwords are not properly salted and hashed with a secure algorithm such as MD5 before being placed in the database. If an attacker were to obtain this password through a flaw in the application, the attacker could conduct an offline brute-force attack against the hash or use a rainbow table to successfully derive the plaintext password.
The secure transit and storage of data needs to be implemented throughout the data lifecycle to reduce the weaknesses that can lead to sensitive data exposure. Some of the key measures that should be adhered to are using up-to-date and strong standard algorithms, protocols, and keys as well as ensuring that data in transit enforces a protocol such as TLS to encrypt the traffic moving between devices/machines.
4 – XML External Entities (XXE)
An XXE attack involves providing XML input that references an external entity (a storage unit) which attempts to exploit a vulnerability in the parser. This can trick the XML parser into sending data to an unauthorised external entity and potentially allow the attacker to exfiltrate or upload arbitrary data to the backend server which can result in the server’s compromise.
5 – Broken Access Controls
Securely implemented access controls are important in ensuring that users cannot act outside of their intended permissions/authorisations. For example, there could be a web page that should only be accessible by an admin-level user and the link to this page is only found on the admin dashboard. Because of this the developer may believe that only an admin can access this page because no user would know about it without being on an admin dashboard. However, if a malicious user discovers this page, such as via a directory brute force attack, the user may then be able to access that admin functionality.
In scenarios such as this, authorisation tokens should be implemented effectively to ensure that unauthorised users aren’t able to access resources that aren’t permitted to access.
6 – Security Misconfigurations
Security misconfigurations arise from the improper implementation and upkeep of web application components and settings. Security misconfiguration is common among web applications and includes vulnerabilities as simple as leaving default accounts active and/or not changing default passwords. Other vulnerabilities include unpatched flaws in software, insecure component settings, and leaving unnecessary features enabled.
Some steps that can be taken to guard against the exploitation of misconfigurations includes ensuring that unused features and components are removed or disabled, that error messages are generalised and that the server is sending the relevant security headers (and that they are set with secure values).
7 – Cross-Site Scripting
There are a few methods that can reduce the risk of XSS occurring, including using frameworks that automatically escape the XSS input by design, manually escaping the submitted input before returning a response based on the context of the input, as well as enabling security headers such as Content Security Policy (CSP).
8 – Insecure Deserialisation
Insecure deseralisation occurs when an attacker sends a serialised object that has been tampered with to an application that deserialises the input which can lead to outcomes such as remote code execution, injection attacks and privilege escalation attacks.
The only way to completely secure against deserealisation attacks is to not accept serialised objects from untrusted sources. However, by monitoring the deserialization of incoming/outgoing connections and implementing integrity checks such as digital signatures on serialised objects.
9 – Using Component with Known Vulnerabilities
If there are components that are not sufficiently patched or are unsupported by the vendor, the components may not be receiving the necessary security updates required to patch known vulnerabilities. The longer the components remain unpatched, the greater the chance that a vulnerability will arise that is relevant to that component’s version. Even in supported, fully patched software, 0-day exploits can be developed (albeit this typically requires a large amount of effort).
Ensure that all components are supported and fully patched so that they are receiving the required security updates. Also remove all unnecessary features, components, dependencies, files, and documentation where possible.
10 – Insufficient Logging and Monitoring
Exploitation of insufficient logging and monitoring can allow an attacker to avoid detection for a long period of time after a breach. This can allow them to exfiltrate large amounts of data or utilise the web application in a malicious way undetected and unchallenged. What is more alarming is that the average discovery time for a breach is around 200 days after it has happened, which gives an attacker a lot of time to cause damage.
Applications should log all login, access control failures and server-side input validation failures with sufficient context to identify suspicious or malicious accounts. The logs should be generated in a way that can be easily monitored and analysed. An incident response and recovery plan should be adopted to supplement these measures to ensure that you have a clear and detailed process to follow during and after the incident event.
Building Upon the OWASP Top 10
The OWASP Top 10 highlights the ten most critical security risks to web applications, however, it’s often incorrectly referred to as a framework or standard. To develop a more in-depth and consolidated approach to web application testing, OWASP also publishes the Web Security Testing Guide (WSTG) and the Application Security Verification Standard (ASVS).
OWASP Web Security Testing Guide
The WSTG is especially relevant to IT professionals that perform penetration testing of web applications as it provides guidelines on what to test and how it should be tested. The WSTG expands on the OWASP Top 10 and provides a framework of best practices used by penetration testers and organisations all over the world.
OWASP Application Security Verification Standard
The ASVS project provides a list of requirements for secure development and acts as a web application security checklist. Although the ASVS doesn’t provide the ‘how’ like the WSTG, it helps to normalise between developers and vendors what to build into security controls to satisfy application security requirements.