OWASP Top 10- Web Application

OWASP Top 10 is the best reference guide for web application testing. Based on a large number of data sets, it ranks the ten most severe security weaknesses in web applications.

In this article, I will give a simple overview of all the top 10 vulnerabilities and how to mitigate them.

A1. Injection

[Injection]

The injection is a basic attack used to either gain unauthorized access to a database or retrieve information directly from the database.
This is the flaw of the web applications and not a database or web server issue.

Cause of Injection

The cause of injection vulnerabilities is the failures of the website to filter, validate, or sanitize a user’s input. Web apps always have some functionality that enables user’s input to work as intended ways like searching for any product in e-commerce or login into some portals. But while developing the applications, some developers forget about the malicious users who attempt to exploit these functionalities by sending some unexpected or unintended data.

Why this vulnerability is important?

This type of vulnerabilities is an alarming issue for all database-driven websites. The injection can be used to implement the attacks mentioned below:

• Authentication Bypass- Using this attack, an attacker logs onto an application without providing a valid username and password and gain administrative privileges.
• Information Disclosure- Using this attack, an attacker obtains sensitive information that is stored in the database.
• Compromised Data Integrity- An attacker uses this attack to deface a web page, insert malicious content into web pages, or alter the contents of a database.
• Compromised Availability of Data- An attacker can delete the database information, delete logs, or audit information that is stored in a database.
• Remote Code Execution- It assists an attacker to compromise the host OS.

Let’s see an example of the injection attack.

In the above image, Assume the login form is connected with the SQL database and if a web developer doesn’t sanitize the data provided in the input, the login form can accept special characters like hyphens (- -) and the single quotes(‘). As the form accepts these special characters, the form is vulnerable to SQL injection.

How?

The unsanitized data can change SQL queries to give more information as compared to normal queries written by developers.

SELECT * FROM USERS WHERE username = '$username' AND password = '$password'

The above query is a normal SQL query that most developers write to get information regarding the users and the above query will return the specific user data depending on password and username.

[Figure-1]

But there is a downfall to this, as shown in figure[Figure -1], as the data is not sanitized, we can change the query to get the list of all users and their data stored in the user’s table. See below

So in the form, if you pass a certain string in the username input field like
‘ OR 1 = 1 — -

the query will like below

SELECT * FROM USERS WHERE username = '$username' OR 1 = 1 -- 'AND password = '$password'

As we know in the SQL (- -) means comment the line after these hyphens, the above query will return the data as the where clause will return always true because of ‘1 = 1’. And by this, you will get the list of all users in the database.

How to Mitigate Injection attacks

1. Filtering, Validating, Encoding and Escaping

• Encoding: the process of encoding ‘bad’ characters after they have been submitted by the user to make them harmless. The most common example of this is by using HTML entity encoding, whereby characters such as ' and " would become ' and " respectively.
• Escaping: the process of ‘escaping’ specialized characters (such as "’%)to make them be interpreted as string literals rather than functioning in their intended way. Typically this is done with backslashes but varies depending upon the language at play.
• Blacklisting: the process of rejecting/stripping known ‘bad’ input. However, this has limitations, since you’re essentially always fighting an uphill battle against attackers with this method of mitigation. Let’s say a developer strips any user input containing " or ' as a means of preventing query alteration. An attacker could encode these characters — say with URL encoding — to %22 or %27 to circumvent the blacklisting. For this reason, blacklisting is never going to be an effective mitigation method when used alone.
• Whitelisting: the process of only accepting the desired input. In the case of an e-mail address, this may have certain restrictions such as requiring an @ symbol, . as well as potentially limiting length. In practice though, this can become difficult to implement in web apps where the intended function by design should allow the user to input a broad range of characters — such as a job posting website.

2. Query Parametrization.

As recommended by OWASP, using parameterized queries is the best — and the cleanest — way to mitigate SQL injection attacks (in combination with the aforementioned mitigation steps). Also known as a prepared statement, it is a query whereby only the parameters are supplied at execution, heavily reducing the ability for a determined attacker to alter or ‘break’ the query itself. Below is a simple example of a parameterized query from W3’s page on SQLi:

For more information on preventing injection attacks, check out the following OWASP cheat sheets: Injection Prevention Cheat Sheet & SQL Injection Prevention Cheat Sheet.

A2. Broken Authentication

This vulnerability covers flaws in authentication and session management. An attacker uses vulnerabilities in the authentication and session management functions such as exposed accounts, session IDs, logout, password management, timeouts, remember me, secret questions, account update, and others to impersonate the users.

How does it happen?

There are various contributing factors to Broken Authentication, listed below:

• Denial of automated attacks(Brute-forcing, credential stuffing, etc.)
• No proper password policy — Allowing users to have weak passwords or well-know passwords eg — password123
• Exposing the username/password information based on error messages/ response times.
• Weak credential recovery and forgotten-password measures
• Exposing Session IDs in URL — Web application creates a session ID for the respective login when a user logs in to a website like http://www.example.com. An attacker uses a sniffer to sniff the cookie that contains the session ID or tricks the user to get the session ID. When the attacker gets the session id, he/she can enter that URL in the browser for eg
  http://example.com/products/?item=1&jsessionid=xxxx
This redirects the attacker to the already logged in the page of the victim. The attacker successfully impersonates the victim.
• Timeout Exploitation — If an application’s session timeouts are set for a longer duration, the sessions will last until the specified time mentioned in the session timeout. When the user simply closes the browser without logging out from the site accessed through a public computer, the attacked can use the same browser later to conduct the attack, as session IDs can be valid still and exploit the user’s privileges.
  Example-
  A user logs in to www.example.com using her credentials. After performing certain tasks, he/she closes the web browser without logging out of the page. The web application’s session timeout is set to two hours. During specified session interval, if the attacker has physical access to the user’s system, he may then launch the browser, check the history, and click the www.example.com link, which automatically redirects him to the user’s account without needing to enter the user’s credentials.

How to Mitigate Broken Authentication

• Two-factor authentication for all logins. This prevents accounts from being brute-forced easily.
• Ensure to have a strong password policy like the minimum number of characters in the password and required special characters to increase the strength of the password.
• Blacklisting of IP addresses having suspicious activities.
• Don’t include the session IDs in the URL.
• A response delay can be implemented to slow down the attacker’s brute-force attacks
• Rate Limit Logins — If a user attempts to log in 20 times per minute as the same user from the same location, regardless of having the correct credentials, the rate limit will come into effect. When this happens, the user can make 10 attempts per minute.

A3. Sensitive Data Exposure

This attack takes place when an application uses poorly written encryption code to securely encrypt and store sensitive data in the database, the attacker can exploit this flaw and steal or modify weakly protected sensitive data such as credit card information, SSNs, and other authentication credentials.
This attack target flaws like insecure cryptography and information leakage.

How does it happen?

• Data is being transmitted in cleartext.
• Sensitive data is stored in the database in cleartext without ay encryption.
• Using a weak cryptographic algorithm for encryption like MD% or SHA-1
• Default/weak key used in the cryptographic process.

How to Mitigate Sensitive Data Exposure

• Do not store the data which are sensitive and no longer needed.
• Use tokenization for sensitive card data.
• When storing the sensitive information, encrypt them with some strong cryptographic algorithm using keys which are not a default or standard.
• Ensure data transmission is happening on secure channels using TLS.

A4. XML External Entities (XXE)

XML External Entity is a Server-side Request Forgery(SSRF) attack where an application can parse XML input from an unreliable source because of the misconfigured XML parser.
An attacker will send a malicious XML input containing a reference to an external entity to the web application and when this XML is processed by the weakly configured XML parser, it enables the attacker to access protected files and services from the servers or connected networks.

When Does it Happen?

• The web application supports the XMLs and upload of XML files without any validation of the source of the request.
• if the document type definitions are enabled
• SOAP version < 1.2 are vulnerable as XML entities are directly passed to the framework.

How to Mitigate XXE

• Disable the XML external entities and DTD processing by XML parsers.
• Use JSON instead of XML.
• Avoid the serialization of sensitive data.
• Run Static Application Security Testing programs over relevant code to identify potential vulnerabilities.

A5. Broken Access Control

Access control refers to how a web application grants access to its content and functions to some privileged users and restrict others.
Broken access control is a method in which an attacker identifies a flaw related to access control to bypass the authentication and then compromised the network by allowing the attacker to act as an administrator or user.

How does It Happen?

• Metadata manipulation (tampering with JWTs or cookies)
• A privileged escalation vulnerability, which allows a lower privileged user to gain high privileges.
• CORS misconfigurations.

How to Mitigate Broken Access Control

• Minimize the implementation of CORS
• Logging activity for the access of the important files and identifying the vulnerability in your server.
• All the access token should be invalidated on the server-side as soon as the user logs out of the system.
• Prevent expose of the Webster directory listing and ensuring the metadata and backed up files are not accessible.

A6. Security Misconfiguration

Developers ad network administrators should ensure that an entire application stack like platform, web server, application server, framework and custom code are configured properly otherwise it will lead to misconfiguration and help attackers to gain unauthorized access to default accounts, read unused pages and read/write unprotected files and directories, etc.

How Does It Happen?

• Unvalidated Inputs- It refers to a web application vulnerability where the input from the client is not validated before being processed by the applications and backend servers.
• Parameter/Form Tampering- It involves the manipulation of parameters exchanged between the client and server to modify the data.
• Improper Error Handling- It gives insight into the source code such as logic flaws, default account, etc. Using the information from error messages, an attacker can identify the vulnerability and can launch various attacks.
• Insufficient Transport Layer Protection- It supports weak algorithms and uses expired or invalid certificates. It exposes the user’s data to untrusted third parties and can lead to account theft.

How to Mitigate Security Misconfiguration

• If a feature, framework, or function is not required in the application, remove it.
• Review all the permission for cloud storage.
• Ensure all the HTTP headers are secured (Free Scanner to check this)
• Make an automated process to check misconfiguration routinely.

A7. Cross-Site Scripting(XSS)

Cross-Site Scripting attacks exploit vulnerabilities in dynamically generated web pages, which enables attackers to inject client-side script to web pages viewed by other users.

How Does It Happen?

• This occurs when invalidated input data is included in dynamic content that is sent to a user’s web browser for rendering.
• Attackers can inject malicious scripts for execution by hiding it in legitimate requests.

How to Mitigate XSS

• Enforce secure headers (such as X-XSS-Protection: 1; mode=block and Content-Security-Policy).
• Use frameworks that automatically escape XSS (RoR, ReactJs)
• Use a combination of validating, filtering, encoding, and escaping method to prevent any malicious user input from executing on the web app.

A8. Insecure Deserialization

[src: PortSwigger]

Data serialization and deserialization is a process of linearizing and de-linearizing data objects to transport the data to other network or system.
Attackers inject malicious data into serialized data and forward this malicious request to the victim.
Insecure Deserialization deserializes the malicious data along with the injected malicious code and compromises a network or a system.

How to Mitigate Insecure Deserialization

• To do Integrity checks(like checking digital signatures) on the data to prevent data tampering or creation of new malicious data.
• Use the deserialization process in a low-privileged environment.
• Monitoring the incoming and outgoing network call from containers or servers that deserialized it or restrict it.
• Logging, monitoring, and alerting when a user repetitively deserializes. This style of attack will make the attacker noisier.

A9. Using Components with Known Vulnerabilities

Components such as libraries and frameworks that are used in the web applications always execute with full privileges and flaws in any of the components can result in serious data loss or take over the control of the server.

How Does It Happen?

• Not aware of all the version info and components running on the web application.
• If the component is vulnerable, unsupported, or out of date.
• No routine checks for updates and patches.

How to mitigate

• Subscribe to security forums or email notification for the components that are being used in the application to get the latest version or security update.
• Keep all the components, libraries, and frameworks up to date and remove the unsupported and unused libraries from the web application.

A10. Insufficient Logging and Monitoring

Insufficient logging and monitoring vulnerability makes the detection of malicious attempts of the attacker more difficult and allowing the attacker to perform malicious attacks like password brute force etc. to steal confidential data.

How does it happen?

• When important events are not logged like login information, significant transactions, etc.
• No or inadequate warning and error log messages.
• Storing logs only on the local client-side system, that will make the logs unuseful.
• There is no process of alerting or escalating if there are any discrepancies in the network or the system.

How to Mitigate?

• Creating effective policy for alerting system and escalating for potential threats
• Proper access-controls are enforced
• Proper logging and monitoring of important events, transactions, and server-side input validation failures.

I hope this article will give all the web developers a basic knowledge about the OWASP Top 10 that they have to keep in mind while developing the application.