Top 10 most important threats for web applications

Grey Wizard
GreyWizard
Published in
4 min readJan 25, 2018

One of the most useful documents published cyclically by OWASP (Open Web Application Security Project) is a list of the 10 most-important errors in the security of web applications.

Apart from DDoS attacks on network infrastructure (network and transport layer according to the OSI model) attacks on the application layer are becoming more and more popular. Just look at Akamai’s last report to see that in the second quarter of 2015, the number of such attacks increased by 17.65% compared to the first quarter.

If we compare it with the number of attacks in the same period last year, it will turn out that it increased by as much as 122.22%. To be able to resist such attacks, it is undoubtedly worth knowing the OWASP list of top 10 threats for web applications.

A1. Injection

The first place was injection errors, including SQL, OS, LDAP, XPath Injection, etc. If the application does not apply appropriate data filtering, the attacker will be able to send an exploit in text form using the appropriate syntax of the target interpreter. The values ​​will be treated as commands, which may result in unauthorized access to confidential information and even taking control of the system being attacked.

A2. Broken Authentication and Session Management

Correct implementation of the functions related to authentication and session support in the application is not easy. An attacker may use not only the technical defects discovered by him in the implementation or configuration of the software, but also design and organizational errors.

The consequences of an attack are usually serious and include obtaining unauthorized access to the session, taking over passwords or tokens, executing commands on the rights of the logged in user, etc.

A3. Cross-Site Scripting (XSS)

XSS vulnerabilities, unlike the above-mentioned injections, do not affect the logic of the application on the server side, but allow the attacker to execute malicious scripts in the victim’s browser. This happens when the application downloads untrusted data and sends it to the browser without prior validation.

The effect of using such errors may be, for example, capturing a logged-in user session, dynamic substitution of the page content, as well as hosting malware using the attacked application.

A4. Insecure Direct Object References

In applications where there are different levels of permissions, there are problems resulting from the possibility of direct access to various objects in the system (such as files, directories or database keys).

If there are no defined accessibility rules, the attacker can manipulate the references appropriately to access confidential data. For example, if the application does not check user rights at the function level that accepts the object identifier, and these are created in a predictable manner, then the knowledge of the identifier will be sufficient to perform the same operations on the site as an authorized user.

A5. Security Misconfiguration

Security configuration errors can occur in every application layer — not only in its own code, but also in other elements that make up the entire system, including in libraries and frameworks used by programmers, database engines, application servers or network devices.

The attacker typically uses default accounts, unused pages, unpatched vulnerabilities, or unprotected files and directories to gain unauthorized access to data. It may happen that it will enable him to completely take control of the system being attacked.

A6. Sensitive Data Exposure

When discussing this threat, first of all, we should mention insufficient cryptographic security and improper security of data exchange. Many applications still store confidential data (such as user passwords or credit card numbers) using incorrectly implemented encoding or hashing without the so-called. somersaults.

As a result of the attack, such data may be stolen and disclosed. Equally often, applications send data over the network, not caring about their confidentiality and integrity. They can, for example, use expired certificates or weak encryption algorithms, which creates a wide scope for abuse.

A7. Missing Function Level Access Control

Applications often handle page queries without proper validation. Failure to check if the person should have access to the requested page, allows the attacker to perform actions without authentication or with the rights of another user. The main purpose of this type of attacks are of course administrative functions.

A8. Cross-Site Request Forgery (CSRF)

This vulnerability is often confused with XSS, as it allows attacking the user’s browser, not the server part of the web application. In this case, the attacker’s goal is to use the victim’s power to perform the unauthorized actions of interest to him.

This is done thanks to the exchanged HTTP requests. The success of the attack depends on whether the attacker is able to predict what the request should look like, which will be accepted by the server.

A9. Using Components with Known Vulnerabilities

The vast majority of applications currently being developed is based on ready-made libraries and frameworks, which — like any software — may have errors. In theory, you can remedy this by installing the patches made available by the manufacturers.

Often, however, it turns out that the updated components will not work with those that have not received patches. As a result, the application remains unpatched, allowing you to perform more or less sophisticated attacks.

A10. Unvalidated Redirects and Forwards

The last threat in the OWASP statement concerns situations in which web applications redirect users to other websites, using untrusted data. If there is no valid validation, the attacker may add a string of characters to the original reference that will lead the victim to a page with malicious software or phishing confidential data.

The above-mentioned errors are among the most critical and most frequently used ones, so it is worth having them in mind when creating and protecting your own internet applications.

Originally published at greywizard.com.

--

--