OWASP Top 10 Guide
What is OWASP Top 10?
As software complexity increases, shipping reliable and secure applications is no longer a nicety for organizations but table stakes. Adopting security recommendation frameworks helps structure and systematize how software is built starting from when the code is written to when it’s deployed. OWASP Top 10 is one such framework that focuses on web application security and is one of the most widely adopted standards for software security.
The Open Web Application Security Project Foundation, or OWASP Foundation, is a non-profit foundation dedicated to improving software security. The foundation is community-driven and helps organizations build secure software through open-source tools, resources, and research.
The OWASP Top 10 is a recommendation framework maintained by the OWASP Foundation since 2003. The list is a collection of security recommendations that helps organizations to write more secure code. It is updated periodically to accommodate for the advancements and developments in application security.
Why should you adopt OWASP Top 10?
OWASP Top 10's importance lies in the actionable information it provides. The list serves as a crucial security checklist when writing or reviewing code. Following these recommendations can prevent your applications from some critical security vulnerabilities and attack vectors.
Adherence to the OWASP Top 10 recommendations is also a crucial part of security compliance. For instance, SOC 2 auditors will require you to show that you're regularly looking for and fixing security issues in your code. Integrating a workflow to regularly audit and fix OWASP Top 10 issues into your software development life cycle demonstrates an overall commitment to industry best practices for secure development.
OWASP Top 10 Vulnerabilities
Following are the security risks reported in the OWASP Top 10 2021 report. The foundation refreshes the list every few years, and the current list consists of several changes from the last iteration in 2017.
A01 Broken Access Control
Access control systems are ubiquitous in modern web applications and allow for a mechanism to control what a user can see or do in the application. If it is not implemented correctly, a user can gain privileged access to the system, misuse an API, or act as a different user. This is especially problematic in multi-tenant SaaS applications where data from all users reside together in the database.
Access control must be implemented in server-side code and enforce record ownership rather than accepting that a user has access to read or modify any record. An excellent way to model an access control system is to deny everything by default, except for public resources, and then deliberately give users access only if needed.
In 2013 Gibson Security found broken access control vulnerabilities in Snapchat. Initially, it was dismissed as a theoretical attack, but a few months later brute force enumeration had revealed 4.6 million usernames and phone numbers.
A02 Cryptographic Failures
Failures related to cryptography, or lack thereof, often lead to exposure of sensitive data. User data must be encrypted in transit and at rest, and none of the data is encrypted using weak or old cryptographic algorithms or protocols. If your application needs to adhere to privacy laws, such as EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS), extra precaution must be taken to eliminate these failures.
A number of straightforward steps can be taken to mitigate this risk. Storing passwords using adaptive and salted hashing functions, such as bcrypt or PBKDF2, ensures that users' passwords are not compromised even if there’s a database breach. It is also worth the effort to implement a secrets management system to store and periodically rotate credentials required by the application, such as third-party API keys and tokens.
In 2017 Google's Project Zero found a bug in Cloudflare's edge servers, which would be named Cloudbleed. Due to a bug in the automatic HTTPS rewrites done by Cloudflare, it was possible to dump memory containing sensitive data, some of which were cached by search engines.
A03 Injection
A code injection occurs when an attacker sends invalid data into a web application, intending to make the application do something it's not supposed to do. SQL injection is one of the most common injection flaws found in applications and can be caused by using unsanitized user data to construct dynamic database queries. Cross-site scripting is another common risk if URL query parameters without context-aware escaping are used directly in business logic.
It is crucial to keep data separate from queries to prevent injection. If you write SQL queries by hand, extra caution must be practiced whenever you write dynamic queries. Sometimes it makes sense to use an Object Relational Mapping (ORM) tool, although performance degradation is a trade-off. As a rule of thumb, always strictly validate user input on the server.
In 2016 The Panama Papers were leaked. The reason was that the site was hosted on outdated software. The number of possible attack vectors is so high that it's difficult to even determine what actual method was used to obtain the data. The website was using versions of WordPress, Drupal, Apache, and Microsoft Exchange each with various vulnerabilities.
A04 Insecure Design
This is a risk related to design and architectural flaws. An application's architecture needs to take security principles into account from the beginning of the design process. For instance, a password recovery workflow might include questions and answers. However, they cannot be trusted because more than one person can know the answers, or the answers can be guessed using social engineering.
An effective way to mitigate insecure design in software is to write unit and integration tests for misuse cases. Assuming malicious intent from the get-go might be a bleak way of designing software, but it can help prevent many fundamental issues that would be difficult to remediate when the application is shipped.
Many e-commerce sites do not factor in protecting against bots that scalpers use to buy up their entire stocks. PC gamers found it difficult to purchase new Nvidia GPUs because of this.
A05 Security Misconfiguration
When any part of the application stack (like network services, web server, database, and frameworks) is not configured correctly, an attacker can take advantage of it to access the systems. For instance, if a default account and its original password are still enabled, the system is vulnerable to exploitation. Other attack vectors include unnecessary features being enabled, such as unnecessary ports or services, or error handling reveals stack traces to the users.
The best way to mitigate against misconfigurations is to invest in a repeatable hardening process across the stack — from virtual machines to container images and application code. Removing unnecessary components and dependencies and making the platform as minimal as possible reduces the surface area of attack.
Several organizations use Amazon S3, but it seems that many of them fail to protect their S3 instances. Accenture exposed its business data in a public bucket. Security researchers even found classified US Army data on an unlisted S3 bucket with no password.
A06 Vulnerable and Outdated Components
This vulnerability's title states its nature — it describes when applications are built using components or third-party software that are outdated. Since these components typically run with the same privileges as the application itself, flaws in any component can result in serious impact. Such defects can be accidental (e.g., an error in the code) or intentional (e.g., a backdoor in a third-party library).
Periodically removing unused third-party dependencies and putting together an upgrade plan for useful dependencies is a solid first step in mitigating this risk. A software composition analysis tool can automate this process, although most of these tools can be noisy. Instilling a culture where developers triage third-party dependencies regularly goes a long way.
In 2017 1.5 million pages were defaced because of a vulnerability in the WordPress API. Malicious users were able to use an unauthenticated REST API flaw to modify WordPress content. Even though WordPress released a fix many websites still didn't apply the patch leaving them exposed to the vulnerability.
A07 Identification and Authentication Failures
When an application's authentication or session management workflow is not implemented correctly, an attacker can use manual or automated attacks to try to gain access to any account, or in the worst case, control over the system.
A common vulnerability of this category is when web applications allow the use of weak or well-known passwords (i.e., "123456" or "qwerty"). It is relatively easy to brute-force and gain access to user accounts. To avoid this, it is recommended to check passwords against a list of known common passwords before allowing users to set them.
Implementing multi-factor authentication (MFA) can prevent attacks like automated credential stuffing, brute force, and the reuse of stolen credentials. Other measures that can be taken to mitigate this risk include limiting failed login attempts and monitoring authentication failures for anomalies.
In 2012 hackers stole 3.6 million Social Security Numbers from the South Carolina Department of Revenue. Since employees had default passwords and no two-factor authentication was enabled it was easy for hackers to obtain their username and passwords once they clicked the link in the spam email. The lack of encryption of these sensitive data fields only helped to increase the impact of the incident.
A08 Software and Data Integrity Failures
This risk is related to code that does not protect against integrity violations. If your application relies on third-party packages that are downloaded from untrusted sources, it is vulnerable to unauthorized access or system compromise by injecting malicious code. These are usually known as supply-chain attacks.
Always use signature verification when installing third-party dependencies and only install from trusted sources as a rule of thumb. Ensure that all new packages added to a project go through a mandatory manual code review process to prevent typosquatting attacks.
The SolarWinds cyber attack in 2020 is the most high-profile example of this new category. Hackers were able to get into their Onion platform and add malicious code undetected. This meant SolarWinds sent out updates and patches with that code to their customers which includes many Fortune 500 companies and government agencies. These compromised updates created backdoors that the hackers used to install malware.
A09 Security Logging and Monitoring Failures
Sufficient logging and monitoring help detect breaches and take corrective action on time. The lack of logs for critical workflows or the absence of an alerting mechanism in case of an anomaly makes the entire system vulnerable to attackers quietly compromising the system without anyone noticing.
Logs are the primary source of information when something's wrong and needs action. Ensuring that logs are in a structured format that log viewing tools can consume is essential. Critical events should be logged to append-only databases to prevent tampering and ensure integrity.
A10 Server-side Request Forgery (SSRF)
Fetching a remote resource without validating the user-supplied URL can make the application vulnerable to an attacker coercing the application to send a crafted request to an unexpected destination.
Deny by default is a good rule of thumb for firewall policies and network access controls. In the application layer, all user input should be sanitized and validated.
In 2019 Capital One had a breach where the attacker used a server-side request forgery. This breach changed how security professionals think about this attack helping it make the OWASP Top 10 this year.
Conclusion
The OWASP Top 10 list provides an excellent actionable framework to ensure your web applications are safe against common threats. Thinking in terms of threats as compared to vulnerabilities helps systemize your engineering culture to write secure code because threats don't go away.
Implementing a static analysis tool in your software development workflow helps automate the detection of specific vulnerabilities for each of these threats while code is still being written and reviewed. As the code moves along the workflow and gets closer to getting deployed, it becomes more and more expensive to find and fix these issues. Enabling developers to ensure source code security helps you embrace the core principles of DevSecOps and shift left.
As a result of automated detection of issues, both the engineering and security teams save time while guaranteeing that known security vulnerabilities never make it into the code. To err is human. Automated tooling eliminates the possibility of human oversight.