Securing Web Applications: OWASP Top 10 Vulnerabilities and what to do about them

For business, applications have become a matter of life or death. They come in different forms—sites, online services, mobile apps—and make it possible to get more done with greater efficiency.

But web applications have a downside too. Constantly evolving web threats can put entire companies at risk. Positive Technologies research in 2018 showed that web applications are one of the most frequent attack vectors against companies and individuals. Once compromised, a site can be used to spread malware, steal data, post unsavory information, commit fraud, or sneak onto the company's internal network.

In this article, we outline the OWASP Top 10 threats to web applications and describe how companies can act to make their applications better protected.

All sites, no matter their industry or sector, are attacked on a daily basis. Pulling off an attack is not difficult. Rather, the question is the amount of effort involved and potential payoff. Most popular attack techniques and methods are thoroughly detailed in public sources. And for anything else, attackers can turn to the darknet, where they can purchase all the necessary tools and software, instructions, and even technical support.

Attackers always look for vulnerabilities in target systems. They scan for typical gaps in protection (these might even be hiding in frameworks or libraries). Positive Technologies research on corporate security shows that just one or two vulnerabilities are enough to penetrate a company's internal network. Weak website security was behind 75 percent of penetration vectors found by our company in security testing.

Vulnerabilities in web applications can have disastrous consequences. So which vulnerabilities are the "popular" ones used by attackers most often?

The Open Web Application Security Project (OWASP) maintains a rating of the 10 most common threats. The OWASP Top 10, while not being an official standard, is a widely acknowledged document used to classify vulnerability risks. The list was last updated in 2017.

For each of the 10 threats in the list, here is our take on the causes and remediation measures that deserve the most attention.

Injection

An attacker can use entry fields to inject grammatically valid constructions that subvert application logic. This is a way to inject malicious code into an application, most often based on SQL, NoSQL, OS, or LDAP.

Positive Technologies analysts have identified SQL injection as the most popular attack on web applications (27%).

Most commonly, injection attacks occur when a web application fails to restrict user input in site forms and entry fields. Malicious code introduced to the application in such fields can yield access to sensitive information or even administrator rights.

Here is an example of an insecure application with such vulnerabilities. In the video, SQL injection is used to get access to sensitive data (employee salary information).

What to do:

• Automate the process of detecting vulnerabilities in code by using purpose-built analysis tools (such as PT Application Inspector).
• Check that output corresponds to the application logic (if the application asks to enter a name in an entry field, it should ultimately output a name and not, say, an entire database).
• Sanitize inputs. When entering a phone number, the user should be able to enter only numbers, plus signs, and parentheses—and definitely not characters such as / or %. Usernames should not contain sequences such as "—".

Broken Authentication

Obtaining information about the accounts of other users, or authenticating as another user, is an obvious but all-toо-common issue.

In these cases, an attacker can perform a brute-force attack. Many sites fail to enforce password complexity requirements. Particularly when the number of password attempts is not limited (an account is not frozen after three unsuccessful attempts, for example), a number of attack vectors become feasible.

In this video, an attacker can learn where and how an application is deployed. This information is used to fine-tune the attack vector accordingly.

What to do:

• Use reCAPTCHA to slow down automated attacks.
• Strengthen password quality and reduce the ability of an attacker to guess passwords:

Restrict the maximum number of password entry attempts and/or enforce a delay after each attempt.

Do not allow standard or default username/password combinations (such as "admin/admin" or "admin/password").

Do not allow credentials that have been compromised on other sites and leaked.

• Enforce password complexity requirements (at least eight characters, including both uppercase and lowercase letters).

Sensitive Data Exposure

Poor implementation of cryptography and use of insecure protocols can be an invitation to hackers. Using indirect indicators and side channels, attackers may be able to infer encryption keys or encryption methods. In timing-based attacks, the speed with which the application processes and responds to certain queries indicates information of value to an attacker.

What to do:

• Limit access to confidential data so that illegitimate users cannot access it.
• Use strong encryption to protect connections and data.

XML External Entities (XXE)

By targeting the XML parser, an attacker can inject external entities into a document that lead to reading of local files and, in some cases, even execution of arbitrary code.

This attack is possible if the application uses XML for transmitting data between the server and user's web browser. The XML specification is potentially dangerous and can be abused to access any server files that are available to the application itself.

This video illustrates the process of injecting a document with a malicious entity into an application. In a real attack, this would lead to a compromise of user accounts.

What to do:

• Disable processing of external entities in the XML parser.
• Use methods that allow detecting and ignoring external entities, such as file paths or URLs.

Broken Access Control

When access control is broken, an attacker with access to an account can make use of privileges that the account is not intended to have. An ordinary account could read and copy files that should be accessible only to the administrator.

How does that happen? Rights for administering and managing an application can be misconfigured (or, as occasionally happens, not configured at all). This lets attackers forge an administrator session or obtain administrator rights.

What to do:

• All accessible business logic functionality should clearly delineate the rights of each role (administrator, user, guest).
• Access control must be implemented on each layer:

Presentation: Hide information about inaccessible functionality.

Business logic: Do not have functionality that changes the state of the model prior to user authorization.

Data: Make available only the data that is needed for a specific role (row-level security).

• Object IDs should be random: attackers should not be able to guess future ID values based on ones already observed.

Security Misconfiguration

Insecure and vulnerable components can come in a number of forms: frameworks, web servers, database servers, and applications themselves.

Researchers find vulnerabilities in systems and components on a daily basis. Zero-day vulnerabilities are particularly difficult to defend against. Time and again, use of insecure components has led to theft of information and wide-ranging attacks.

When an application uses insecure components, attackers can learn everything they need to know about components, servers, and more. Check out this demonstration.

What to do:

• Enable and use standard security settings for components such as servers.
• Be sure not to include test credentials or sensitive information in release versions.
• Do not include the "Server" and "Version" headers in HTTP responses, since they provide information that is useful to hackers.
• Set the "secure" and "httpOnly" flags to increase the security of cookies.

Cross-Site Scripting (XSS)

These attacks usually take the form of injection, in which an arbitrary script is run on the client in the context of the attacked site. This bypasses the same origin policy that usually governs script sources.

Attackers inject a script into the page of a victim site. This script runs whenever the site is visited. One of the simplest examples is when a user clicks an unsafe link and enters their social network credentials, which end up in the hands of attackers. Most modern browsers scrutinize site scripts and warn of possible threats.

Take a look at how injecting entities into an application can affect code execution. In this example, injection causes a script to run in the client browser.

What to do:

• Sanitize and filter both inputs and outputs on websites.
• Enable browser-based protections.
• Install browser updates for the latest security settings.

Insecure Deserialization

When a data stream is converted into objects (deserialized), hostile or tampered objects can cause serious security issues. Attackers can use this to obtain remote code execution and run programs.

See our example in which an attacker can launch any process on the application server—in this case, the calculator.

What to do:

• Do not deserialize inputs from untrusted sources (JSON and XML are safer in such cases).
• Enforce integrity checks with digital signatures when using serialized data across HTTP requests.
• Make sure that deserialization enforces strict type constraints for all objects.

Using Components with Known Vulnerabilities

It's not enough to avoid making errors in your own code. Attackers can also target the other software you rely on. Third-party libraries and frameworks can contain vulnerabilities. Hackers may have an arsenal of known vulnerabilities in popular libraries. And in rare cases, vulnerabilities or backdoors are purposefully inserted into such components.

Our test application uses third-party libraries. See why it's not always safe to assume that somebody else's code is more secure than your own.

What to do:

• Use up-to-date versions of all third-party code.
• Minimize use of third-party components.
• Monitor for news of vulnerabilities in components that you use. When such vulnerabilities become known, act quickly to install patches. Even in the absence of patches you may still be able to secure your systems by implementing security policy updates (as was possible during the WannaCry outbreak).

Insufficient Logging and Monitoring

A tiny incident may be part of a much larger attack. Failure to obtain and keep full information prevents an understanding of the potential risks and threats. This is why it's imperative to always investigate incidents, even ones that initially seem unimportant.

What to do:

• Create procedures for handling incidents.
• Ensure compliance with relevant standards and regulations (ISO, HIPPA, PCI DSS). Incorporate new security practices as an ongoing process.
• Reinforce monitoring and protection.

Perfect security for a web application may be impossible, but there are plenty of ways to minimize the risk of external threats. Here we have looked at each of the most popular vectors for attacking applications. To stay safe, we urge deploying protection to reduce your risk profile and ability of an attacker to exploit vulnerabilities. One important step is the Secure Development Lifecycle (SDL). This is a difficult and time-consuming process that requires substantial changes in development workflows. Full implementation of SDL requires substantial investments both of finances (purchasing additional software) and of staff (hiring skilled security specialists).

Here are our core recommendations for securing web applications:

• Use a source code analyzer. This software catches code vulnerabilities and weak spots early on, in order to correct them closer to the beginning of the development process. Most code analyzers can protect your application from OWASP Top 10 vulnerabilities.

Check out the demonstration of PT Application Inspector analyzing source code and finding the vulnerabilities.

Here is the breakdown of these vulnerabilities.

• Deploy a web application firewall (WAF) to protect your site. This will keep the web application safe even if it contains vulnerabilities or new threats to it appear. A WAF can stop known attacks on the levels of application and business logic. What's more, it detects exploitation of zero-day vulnerabilities, prevents attacks on users, and analyzes and correlates events when reconstructing attack chains. Ideally, a WAF should integrate with external security information and event management (SIEM) and anti-DDoS solutions. Integrating a WAF with automated source code analysis enables virtual patching, which closes off vulnerabilities even before they have been fixed in code.
• Regularly assess the security of your web applications and fix any vulnerabilities found. When possible, opt for white-box analysis (assessment with full access to application source code). Assessments should be performed at all stages of the site lifecycle, and not only at the last minute prior to going live.
• Do not use out-of-date web server, OS, CMS, or library versions. Regularly update your systems and install the most current patches.
• Record and investigate cyberincidents. Determining the source of a threat in a timely way allows minimizing the risks.