OWASP stands for the Open Web Application Security Project. It is a non-profit organisation that releases standard awareness documents, tools such as OWASP ZAP, and technologies for web application security. All these resources are free and open-source.
The OSWAP community follows the “open community” model under which anyone can contribute to the OWASP projects.
Cyber security is essential to keep our data safe and maintain privacy in today’s era. OWASP is a non-profit organisation that takes care of web application security. Let’s dive into the article to understand OWASP and the OWASP top ten vulnerabilities.
OWASP Top 10 Vulnerabilities
The OWASP community releases an OWASP top 10 every two to three years. This list contains the top ten security risks or vulnerabilities to web applications, with the steps and best practices to prevent them.
It is advised to the companies to adopt this document to maintain the security of their application and ensure their application doesn’t have these risks or vulnerabilities.
Let’s see the top 10 OWASP vulnerabilities according to the latest list released in 2021.
A01: 2021 – Broken Access Control
When a web application’s authentication and access controls are not correctly implemented, the attackers can gain access to sensitive user information and act as users or administrators — known as Broken Access Control.
According to the tests, 94 % of the web applications had broken access control with an average incidence rate of 3.81%.
Some examples of Broken Access Control can be –
- The attackers can access the REST API point for POST, DELETE, and other operations if the authentication is missing.
- The application metadata can be manipulated, such as tampering with the cookies or JWT access control token.
- The attacker can view or edit or delete the user’s details.
- The attacker can bypass the control checks by modifying the URLs.
You can secure your application from Broken Access Control by using some of the preventive measures mentioned below.
- Use penetration testing to find out some broke access controls in the application.
- Your application should have strong access and authorisation control mechanisms implemented across the web application.
- Access to any data should require authorisation except for public resources.
- Use Multi-Factor Authentication to enhance the security of the application.
- You can use the IAST (Interactive Application Security Testing) solutions to detect cross-site request forgery or insecure storage of users’ sensitive data.
- The user should get alerted in case of access control failures, and the logs should also be stored for future reference.
- The session tokens should be short-lived so that the attackers don’t get enough time and opportunity to get into the system.
A02: 2021 – Cryptographic Failures
Cryptographic failure, earlier known as Sensitive Data Exposure, leads to the exposure of sensitive data and comprises the system. The cryptographic failure can occur if:
- The encryption algorithms used are old and have some vulnerabilities in them.
- Some HTTP headers are missing.
- The transmitted data is not hashed properly,
- Deprecated hash functions or encryption algorithms are used.
Improperly encrypted sensitive data such as credit/debit card details and passwords can be exposed to attackers. Thus, if needed, they should be stored with extra caution as these data come under privacy laws and regulations such as GDPR and PCI DSS.
You can secure your application from Cryptographic Failures by using some preventive measures specified below.
- Identify and classify sensitive data according to the privacy laws, rules and regulations.
- Keep updating the encryption algorithms and protocols regularly.
- Only the highly required data should be stored, and the rest should be discarded or truncated.
- Strong hashing functions should be used to store passwords such as Argon2, scrypt, bcrypt..
- Use IAST and SAST (Static Application Security Testing) tools to identify any risk of data exposure and faulty algorithms.
A03: 2021 – Injection
Sending some invalid data to the web application by the attacker to gather some information or to do something the application isn’t supposed to do is known as code injection. The invalid data is sent through the help of a command or query such as an SQL query. Examples of injections are SQL injections, LDAP injections, OS command injections.
Cross-Site Scripting (XSS) is now a part of the Injection criteria. You can secure your application from Injection attacks by using some of the preventive measures specified below.
- Validate the input given by the user on the server side.
- Use SAST and IAST tools to identify the injection flaws during testing.
- Use escaping scheme on the user input before putting the input into the query.
- You should use the SQL controls and Limit so that many records are not leaked during an SQL injection attack.
- Keep your development environment and packages up-to-date.
Also read: What is a SQL Injection? How to prevent it?
A04: 2021 – Insecure Design
The flaws present in the application design can lead to risks that come under the Insecure Design category. This category was introduced in 2021.
For example, you missed considering some security requirements, such as adding password constraints during the design phase. The application that will be developed later will not have password constraints; thus, it will be a risk. The user can add any whole string password such as qwertyuiop, password. The attacker can brute force the application as the unavailability of constraints will ease the attacker’s work.
The difference between secure and insecure design risks is that secure designs can have some implementation bugs or issues that can be solved. However, that’s not the case with insecure designs.
Follow the preventive measures specified below to minimise the insecure design risks in your application.
- Before the development phase — in the design phase — every requirement should be considered thoroughly, especially the security requirements.
- While designing the application flow, always look into the failure stages — when the application can fail and what the application should do in case of a failure or error.
- Write integration and unit tests and cover all the failure stages.
- The attacker can misuse to application to find loopholes or some sensitive information. Thus, while testing the application cover all the aspects, including the use-cases and the misuse cases.
- Conduct threat modelling workshops to examine major security issues such as access and authentication.
- Learn from previous insecure design issues and keep in mind to consider them in your new application.
A05: 2021 – Security Misconfiguration
The lack of security that happens because of misconfigured or unnecessary settings, features, or permissions comes under the category of Security Misconfiguration. It depends on the developer’s configuration.
Approximately 90% of the applications tested in 2021 had some misconfiguration.
A classic example of security misconfiguration would be that the default account and passwords you get with the sample application are still valid and enabled. The attacker can easily use them to log in to the application as an admin.
XML External Entities (XXE) attacks come under the category of Security Misconfiguration. In this attack, the application that parses XML inputs is targeted. An attack can occur if the misconfigured XML parser parses an XML input having an external entity reference.
Some preventive measures to check the security misconfiguration are listed below.
- Use dynamic testing to find out misconfigurations in your application.
- All the applications and operating systems should be configured securely and updated regularly.
- Do not keep any unnecessary features, settings, or components in your application.
- The server should send security headers and should have secure values.
- Keep your development, production, and QA systems identical, however, with different credential values.
A06: 2021 – Vulnerable and Outdated Components
Using vulnerable and outdated components such as packages, frameworks, and APIs, in your application exposes it to vulnerabilities. The attacker can negatively impact your application, such as severe data loss or server takeover. This category was earlier called “Using components with known vulnerabilities”.
Recently, the logj4 vulnerability was exposed worldwide, through which the hacker could take control of the vulnerable devices and execute any code on them. A huge loss was faced due to this vulnerability. The log4j vulnerability is a perfect and recent example of the vulnerable and outdated components category.
Check out the ways mentioned below to keep your application away from vulnerabilities in this category.
- Keep updating the libraries and other components your application uses regularly.
- Do not keep unused features, dependencies, or files on your application.
- Keep an eye for the latest security news, and if any component you use is exploited, remove it from your application or apply the patch if released as soon as possible.
- Keep track of all the component versions that you use.
- Configure your application very well.
- Keep on testing the compatibility of every component timely.
A07: 2021 – Identification and Authentication Failures
When the authentication and session management features are not implemented correctly, it gives the attacker permission or easiness to steal the user identity by compromising the password. This category was earlier known as Broken Authentication. Some examples of when can identification and authentication failure occur are listed below.
- The passwords and other sensitive data are not strongly hashed.
- Weak password is used.
- The attacker can brute force into the application.
- The “forgot password” process is fragile and “knowledge-based questions” are used.
- The session is not properly managed. For example, after logout, the session ID is not nullified, or Session details are exposed through the URL.
Follow the preventive measures specified below to minimise your application’s identification and authentication failures.
- Implement multi-factor authentication to strengthen the security of the application.
- Do not deploy your application with default credentials such as “admin, admin”.
- Use a strong password for your application which includes alphabets (a-z A-Z), numbers (0-9), and special characters (!, &, -).
- Do not use easily guessable passwords such as your name, date of birth, or even easy passwords such as “abcdef” or “password”.
- Limit the number of failed login attempts and alert the user.
- Keep changing your passwords timely.
- Perform DAST and SCA testing before deploying the application, and remove or correct all the vulnerabilities found.
- Use a secure session management feature and ensure your session details are not exposed through URLs.
Also read: What is com.sec.epdg?
A08: 2021 – Software and Data Integrity Failures
As the name “software and data integrity” suggests, the failure due to some code compromises the integrity of the data falls into this category.
For example, when you use some library or plugin from an untrusted source, you may expose your CI/CD pipeline to the attacker to gain access to your system. Once the attacker gets access to your system, they can create and upload updates. Through the auto-update feature, hundreds and thousands of systems can be affected by downloading this malicious update.
Insecure Deserialisation, a part of this category, allows the attacker to execute code in the system. The attacker can also start the Denial of service (DoS) attack.
Follow the preventive measures specified below to minimise integrity failures in your application.
- Use penetration testing to reduce the risk.
- Ensure the libraries and plugins you are using are from a trusted source.
- Verify that the data/updates you receive are from a trusted source using digital signatures.
- Review the code and configuration from time to time to check if there is some malicious code present or not.
- Your CI/CD pipeline should have proper access controls and configuration.
A09: 2021 – Security Logging and Monitoring Failures
When the security of any application is compromised, the logs are used to detect the attack and respond to it. The failure of your application’s logging and monitoring feature to provide sufficient and adequate details falls into the security logging and monitoring failures category.
If the logs are not present, you cannot check or monitor if any break occurred or not. Thus, logging and monitoring are essential components of any application.
Check out the ways mentioned below that you can implement into your application to secure it from security logging and monitoring failures.
- Ensure that all the security-related failures such as login or input validation failures are logged into the system.
- Ensure your log contains adequate data to identify attacks or suspicious activities.
- Use penetration testing to check the logging and monitoring of your application.
- Make sure the logs are not visible to the user or the attacker.
- Use monitoring and alerting features so that as soon as the suspicious activity is found, it is reported to the responsible person, and action is taken.
A10: 2021 – Server-Side Request Forgery (SSRF)
The server-side request forgery happens when the application fetches some data from the user-specified URL without even first validating the URL. In such a scenario, the attacker can specify any URL as an input, and the server secured by a firewall would request the resources from that URL without even validating the URL.
Check out the ways mentioned below to keep your application away from vulnerabilities in this category.
- Do not take URL as input from the user until required.
- Always validate user input.
- Make sure your application does not redirect HTTP requests.
- Block unwanted traffic by using the “deny by default” firewall policy.
Also read: Ransomware Attacks explained