Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2021 OWASP Top Ten.
(1) A01:2021 Broken Access Control
Moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.
Access control refers to a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example, a web application could allow a user to change which account they are logged in to simply by changing part of a URL, without any other verification.
Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls.
Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are without having to constantly enter their login credentials.
- – Allows access to restricted resources
(2) A02:2021 Cryptographic Failures
Shifts up one position to #2, previously known as Sensitive Data Exposure, which was a broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.
Slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition
If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sell or utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.
Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this will result in that SQL code being executed. This is known as an SQL injection attack.
Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.
– LDPA
– SQL
– OS
– XSS
– Log
A new category for 2021, focusing on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.
(5) A05:2021 Security Misconfiguration
Moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.
Security misconfiguration is the most common vulnerability on the list and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors, which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.
(6) A06:2021 Vulnerable and Outdated Components
Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common examples include front-end frameworks like React and smaller libraries that are used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components, which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploitation.
Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensure that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.
- NIST NVD
- Shodan
(7) A07:2021 Identification and Authentication Failures
Previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.
Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) and limiting or delaying repeated login attempts using rate limiting.
- Weak Password Policy
- Weak Cryptography
- User Access Controls
(8) A08:2021 Software and Data Integrity Failures
A new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.
(9) A09:2021 Security Logging and Monitoring Failures
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.
SIEM
App Logging
Crash Logging
Exception Handlling
(10) A10:2021 Server-Side Request Forgery
Added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above-average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.
The official OWASP PDF for the OWASP Top Ten 2021 can be found here.
•1980’s, Dr David Chaum wrote numerous papers on subjects including; “Security without Identification: Transaction Systems to Make Big Brother Obsolete” and “Numbers Can Be a Better Form of Cash than Paper”. Chaum basically predicted the anonymous use of electronic money as opposed to paper money, which we all now know, as Crypto-Currencies.
•1992, Eric Hughes, drafts the Cypherpunks Manifesto in which he states ‘privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.’
•1997, Adam Back creates Hashcash an anti-spam mechanism which adds a time and computational power cost to sending email, making the sending of spam uneconomical. The sender would have to prove that they had expended computational power to create a stamp in the header of an email (similar to the proof of work (POW) use in Bitcoin) before they can send it.
•1998, Wei Dai, publishes a proposal for B-Money. This included two methods of maintaining transaction data; a) every participant to the network would maintain a separate database of how much money belongs to users and, b) all records are kept by a specific group of users. WithIn the second option the group of users who have custody over the records are incentivised to be honest because they have deposited their own money into a special account and stand to lose it if they are not. This method is known as “proof of stake” (POS) and the specific groups of users (or master nodes) will lose all the funds they have staked if they attempt to process any fraudulent transaction.
•2004, Hal Finney, created Reusable Proofs of Work which borrowed from the principles of Backs’ Hashcash
•2005, Nick Szabo publishes his proposal for Bitgold, built on previous ideas developed by Hal Finney and others.
•2008, Satoshi Nakamoto, an anonymous individual or group of individuals, sends a paper to the cypherpunk mailing titled, “Bitcoin: A Peer-to-Peer Electronic Cash System”. This paper makes direct references to b-money and hashcash and addresses many of the issues that previous developers had such as, double spending (the risk that a single token is used multiple times to purchase goods). Even though the papergarnered a lot of criticism from sceptics, Nakamoto continued on and mined the genesis block of Bitcoin on 3 January 2009.
Software Security 