Bukunmi Odugbesan
A frontend engineer with a desire to be a JavaScript expert
Article by Gigson Article
The OWASP 10 is the standard awareness document for developers and web application security. It is regularly updated, outlining security concerns for web applications, focusing on the 10 most critical risks. OWASP stands for Open Web Application Security Project, which is an international non-profit organisation dedicated to web security. They recommend that all developers incorporate the report into their processes in order to minimize and/or mitigate security risks. Here are the security risks reported in the most recent OWASP document:
1. Broken Access Control:
Access control refers to a system that regulates access to information or functionality. When access control is broken, cyber attackers can bypass authorization and perform tasks as though they were authorised users. For example, a web application that allows a user to change which account they are logged into by changing part of a URL, without any other verification. This is now the number one vulnerability, and can be prevented by ensuring a web application uses authorization tokens and sets tight controls on them.
2. Cryptographic Failures:
Web applications should protect sensitive data, such as passwords, by using encryption; otherwise, attackers can gain access to that data and do whatever they want with it. Sensitive data can be stolen through on-path attacks (on-path attackers place themselves between a web browser and a web server, and intercept or modify communications between the two).
Aside from encryption, data exposure can be minimised by authenticating all transmissions and disabling the caching of any sensitive information. Caching is the practice of temporarily storing data for reuse. For example, web pages are often cached so that if a user revisits within a timeframe, the browser does not have to fetch pages from the web.
3. Injection:
When untrusted data is sent to a code interpreter through data submission to a web application, that’s called an injection attack. This category also includes cross-site scripting attacks, which previously had its own category. It can be reduced by escaping untrusted HTTP requests and also using modern frameworks like React, which has its own cross-site scripting protection. Generally, injection attacks can be prevented by validating and/or sanitizing submitted data.
4. Insecure Design:
This includes a range of weaknesses embedded in the architecture of an application. OWASP lists the use of security questions for password recovery as a workflow that is insecure by design. It is vulnerable because more than one person can know the answer to the questions. Threat modelling before deployment can be used to mitigate these types of vulnerabilities. Threat modelling is an exercise for finding security holes in an application.
5. Security Misconfiguration:
This is the most common vulnerability on the list. It is often the result of using default configurations or excessively descriptive error messages, 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. An example of an overly descriptive error message, using an attacker trying to log in as a case study:
{
"status": 500,
"error": "Internal Server Error",
"exception": "java.sql.SQLSyntaxErrorException",
"message": "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1",
"path": "/api/v1/auth/login",
"trace": [
"com.mycompany.auth.AuthService.authenticate(AuthService.java:42)",
"com.mycompany.db.DatabaseConnector.executeQuery(DatabaseConnector.java:108)",
"org.hibernate.exception.SQLGrammarException: could not extract ResultSet",
"SERVER_ROOT: /var/www/html/prod/backend/...",
"DB_VERSION: MySQL 5.7.33-0ubuntu0.16.04.1"
]
}This error message tells the attacker exactly what vulnerabilities affect your specific database version, your technology stack (Java and Hibernate), and your file hierarchy, helping them understand your application logic.
A better error message will be:
{
"status": 500,
"error": "Internal Server Error",
"message": "Something went wrong. Please try again later or contact support if the issue persists.",
"requestId": "req-12345-abcde"
}6.Vulnerable and Outdated Components:
Components like libraries or frameworks used by developers to avoid redundant work and provide needed functionality can be targeted for vulnerabilities, which can be used to orchestrate attacks on the application. Developers building these libraries often offer security patches and updates to plug up known vulnerabilities, but applications do not always have the most recent versions. To reduce the risk of running components with known vulnerabilities, remove unused components from projects, and ensure components are obtained from trusted sources. In ensuring that components are gotten from trusted sources, you need a combination of tools: Gatekeepers(to block bad code), Scanners (to check for bugs) and Verifiers(to prove identity.
7. Identification and Authentication Failures:
In the event of a data breach, an attacker can use a script to try multiple combinations of usernames and passwords on a login system. Using 2-factor authentication, as well as limiting or delaying repeated login attempts using rate limiting, can be used to prevent authentication vulnerabilities.
8. Software and Data Integrity Failures:
An application that automatically accepts updates from an outside source could be vulnerable to an attacker uploading their own malicious updates, which would then be distributed to all installations of that application. Also, deserialising data from untrusted sources can result in serious consequences like DDoS attacks. Distributed Denial of Service (DDoS) attacks are malicious attempts to disrupt the normal traffic of a targeted server, service or network by overwhelming the target or the surrounding infrastructure with a flood of internet traffic.
Application developers should use digital signatures to ensure that data and updates have not had their integrity violated. Check software supply chains, and ensure that continuous integration/continuous deployment pipelines have strong access control.
9. 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 about 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. It is recommended that web developers implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.
10. Server Side Request Forgery:
This is an attack in which someone sends a URL request to a server that causes the server to fetch from an untrusted resource. For example, an attacker fetching from ‘www.example.com/high-level-data’, even though web users are not supposed to be able to navigate to that location, and get access to high-level information from the server’s response. ’The most important form of mitigating this is by validating all URLs coming from clients. Invalid URLs should not result in a direct, raw response from the server.
Frequently Asked Questions
What is the difference between Broken Access Control and Identification/Authentication Failures?
Authentication is about who you are, i.e., the attacker logs in as you. Access Control is about what you can do.
Is insecure code another name for bad coding?
No. Bad coding means the design is safe, but the code has a bug or doesn’t follow best practices. Insecure code means the code is written perfectly and according to the spec, but the spec itself is flawed.
Can we automate OWASP Top 10 checks?
Detection can be automated, but prevention cannot be automated.
.webp)
