OWASP Top 10 Security Risks and Vulnerabilities

       About 90% of applications have serious vulnerabilities. OWASP, which regularly analyzes
   weaknesses and attacks on Web applications, has compiled OWASP TOP-10 - the list of the
  most dangerous vulnerabilities.

What Is OWASP Top 10 Vulnerability List?

OWASP Top 10 is one of the organization's best-known projects. OWASP Top 10 is a ranking of the ten most dangerous information security risks for web applications, compiled by a community of industry experts. For each point of the rating, the risk is calculated by experts based on the OWASP Risk Rating Methodology and includes an assessment of Weakness Prevalence, Weakness Detectability and Exploitability, as well as the criticality of the consequences of their operation or Technical Impacts.

For obvious reasons, risk severity assessments do not take into account the business consequences of their implementation. Where possible, the names of the risks in the rating correspond to the names of the similar vulnerabilities in the Common Weakness Enumeration (CWE) classification. It should be noted that, unlike the classifications, the OWASP Top 10 project does not claim to cover all the existing risks, but only represents the most relevant ones at the time of the rating release.

OWASP Top 10 is not an official standard, it is just a white paper that is widely used by many organizations, vulnerability bounty programs, and cybersecurity experts to classify the severity of weaknesses and security breaches.

The rating was compiled on the basis of user posts and open discussions. OWASP Top 10 list is based on eight databases from seven companies, including four consulting firms and three SaaS vendors. The general database contains over 500,000 vulnerabilities in hundreds of organizations and thousands of applications. 

 

 

OWASP Top 10 Vulnerabilities in 2021 are:

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfigurations
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging and Monitoring

1. Injection

All data, as a rule, is stored in special databases, the requests to which are built in the form of queries, most often written in a Structured Query Language - SQL. Applications use SQL queries in order to receive, add, change or remove data, for example, when the customer edits his personal data or completes a questionnaire on the webpage. In case of the user's information insufficiently checked, a hacker can change the app's code that contains the SQL query part.

This is a very insecure weakness that can give an intruder access to the database, as well as the ability to see, modify or delete data. In such a way, the hacker can steal confidential personal data.

The weakness is the aftermath of insufficient validation of user data, so that allows an intruder to put into web forms specially prepared requests that "trick" the app and allow reading or writing illegitimate data.

Read more about OWASP Top 10 Injection or learn even more about SQL Injection [CWE-89] vulnerability in our CWE Knowledge Base.

2. Broken Authentication

According to OWASP Top 10, this weakness is one of the most critical. If someone needs to distinguish another user, the web application applies session cookies. After entering login and password when the authorization in the application is successfully completed, a special identifier is saved in the specified storage, which the program subsequently sends to the server with every query for a page of the app. This is the way web application recognizes users.

In case of this identifier is stolen by a hacker, and the IT structure did not implement checks, for instance, session's IP address, or checks for more than one connection in one session, the intruder gains the possibility to get into the system with the user's account. And if it is an Internet bank or a payment system cabinet, you can easily guess for yourself the consequences of such unauthorized access.

Read more about Broken Authentication.

3. Sensitive Data Exposure

The thing is that the information transmitted via the HTTP protocol is not cyphered in any way, and when sensitive information goes to the Web server from the device of the user, the data will go through a good many different nodes such as an office router or home router, a provider's router, a router on a channel, a router in a data center or the hosting provider server, etc. Each of these nodes can contain malware, called 'sniffer', a program that reads all traffic and sends it on to the hacker. So, the hacker looks at the received data for personal info and banking card information.

Also, the lack of encryption of such confidential information like user's password or bank card details makes data vulnerable to theft. However, in case it is cyphered, then even if unallowed entry to the server is obtained, a hacker can't steal critical data.

Read more about Sensitive Data Exposure.

4. XML External Entities (XXE)

The biggest risk with XXE is the huge variety of ways in which it can be exploited. Whether simple or complex, if an external piece of code can make its way onto an XML document, this means that the system has been compromised. XML's ubiquity means that applications making use of XML are likely to intersect with a lot of sensitive data.

The most widely-known form of XXE attack is known as the ‘Billion Laughs’ attack or the ‘XML Bomb‘. This is a simple but effective denial of service attack used to overload and shut down a target server. By defining an entity – usually something small and nonsensical, like ‘lol’ or ‘haha’ – as a nested string of other entities, an attacker can quickly overload the system's resources.

Read more about XML External Entities (XXE).

5. Broken Access Control

The essence of this OWASP Top 10 vulnerability, as the name suggests, is the lack of verification of proper access to the requested object. Most web applications check permissions before displaying data in the user interface. However, applications must perform the same access control checks on the server when requesting any function. After all, there are many more auxiliary service requests, which are often sent asynchronously in the background using AJAX technology. If the request parameters are not carefully validated, attackers could spoof the request to access data without proper permission.

Read more about Broken Access Control.

6. Security Misconfigurations

Web application security controls every infrastructure element, for example, application frameworks, all kinds of servers, and the whole system itself. The default settings of server components are often insecure and open up opportunities for leaks. For instance, the theft of a session cookie via JavaScript in an XSS attack becomes possible thanks to the cookie http only setting, which is disabled by default. If the server is configured correctly and the cookie http only option is enabled, it is impossible to receive a session cookie through JavaScript, but often this simple and important setting is missing in such critical places as personal accounts of payment systems.

Another illustration of this OWASP Top 10 weakness is default settings in database servers, like Redis, Memcached, and so on. It relates to private services that may become available on the public IP or passwords mounted by the manufacturer for default use. It makes it possible for intruders to easily read and modify data. This also allows hackers to make an XSS invasion.

Also, the program and applications must be updated, as weaknesses appear every day in a wide range of program components. Even if your app is commonly well protected, correctly written, and carefully checks all incoming data, you still can't guarantee that no weaknesses will be found in the OS or Web server at any time.

Read more about Security Misconfigurations.

7. Cross-Site Scripting (XSS)

Cross-site scripting is another user data validation error that allows injecting JavaScript to the browser of the user for execution. To assail in such a way is similar to HTML injection, as the mechanism of their injection is very similar to SQL injection, however, unlike the last one, the injected script is performed in the browser of the user. This allows hackers to steal session cookies.

But it's worth noting that not any app servers are weak and vulnerable to this. Further, data entered into forms on the vulnerable site can be thieved. Susceptible to theft data can be confidential and personal, as well, credit card info along with its CVC code. The next possible case is that through JavaScript hackers can transform the information located on a specific website page, like changing details of a bank transfer, so hacker will be glad to fake and replace them.

Read more about OWASP Top 10 Cross-Site Scripting (XSS) or learn even more about Cross-Site Scripting XSS [CWE-79] vulnerability in our CWE Knowledge Base.

8. Insecure Deserialization

Serialization and deserialization are important concepts in object-oriented programming frameworks, such as Java and .Net; and are consequently common to many web applications.

An insecure deserialization vulnerability exists when an application doesn’t properly secure this process. If a deserialization implementation is left to its default settings, an application can have little to no control over what data is deserialized. In the most extreme cases, this can include any incoming serialized data from any source, with no verification or precautions.

Read more about Insecure Deserialization.

9. Using Components with Known Vulnerabilities

Oftentimes, web applications are developed using special libraries or "frameworks" that are provided by third parties. In most cases, these components are open source, which means that not only you but also millions of people around the world are studying their source code, and for vulnerabilities too. They are also looking for weaknesses in lower-level components of the system, like different servers or the components of the OS down to its kernel. It is very important to use the latest components and keep an eye on emerging known vulnerabilities.

Read more about Using Components with Known Vulnerabilities.

10. Insufficient Logging and Monitoring

The problem of insufficient logging and monitoring covers the entire IT infrastructure and not just the internet-facing web application – as does the solution. For that reason, we will not limit this discussion to just logging and monitoring web apps.

One of the primary problems is that there are so many logs – almost all contemporary systems generate their own logs. Log management thus becomes a major problem. By the time that all the different logs are gathered together and preferably collated, the sheer size of the data set becomes too large to effectively monitor manually.