OWASP Top 10 Security Vulnerabilities – How To Mitigate Them

This is a complete guide to OWASP (Open Web Application Security Project ) Top 10 Security Vulnerabilities and how to mitigate them:

In this article, we will discuss OWASP’s Top 10 security vulnerabilities that you will find around. We will see what causes these weaknesses and their effect on us.

We will also talk about what we can do to mitigate these security vulnerabilities.

Let us begin by understanding OWASP.

What Is OWASP

OWASP is an acronym for Open Web Application Security Project. It is a non-profit foundation that has the sole aim of improving the security of software through the use of community-developed open source applications, creation of local chapters all over the world with members, training events, community meetings, and conferences.

What Is OWASP Top 10

OWASP Top 10 Vulnerabilities is the list of the 10 topmost vulnerabilities that affect applications in the world. These are arranged according to their impact, the security risk involved, and how to mitigate against these vulnerabilities.

OWASP was first released in 2003 and thereafter every three to four years. The latest OWASP Top 10 was released in 2017.

OWASP Top 10 List

The list includes the following:

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

Let us understand these security vulnerabilities in detail below.

#1) Injection

Example: SQL injection, OS command injection.

Injection attack is all about injecting SQL, NoSQL, OS, and LDAP into the application. It can be as SQL queries through the input interface of the application. Successful SQL injection can lead to sensitive data from the database being exposed.

With SQL injection, it is possible to modify database data through the use of Insert, Update and Delete statements, and even the DBMS (Database Management System) can be shut down with just an SQL injection.

Injection occurs when data is inserted into a program from an untrusted source because of the lack of input validation and data sanitization, which can directly expose input into the query.

This injection vulnerability is present in almost all websites and this shows the critical level of this vulnerability because anything that accepts parameters as input can be vulnerable to injection.

Let’s analyze the following SQL query used to compare the username and password in the database. The name and password parameter is the one you give as input, which is directly inserted into the query.

SELECT * FROM credit_login WHERE user='admin' AND password='anything 1' OR '1' ='1'

This query means username = admin, where the password is anything or 1=1.

1=1 will always result in true and the query result is the user with the name admin and password = true.

Another example is a web application that allows users to retrieve user information just by entering firstname into a form field. The input by the user is inserted into a SQL query, which is processed by an SQL interpreter.

The SQL query to retrieve the user information will be:

"SELECT * FROM users WHERE name = '" + firstname + "'";

The variable firstname receives the input from the user and it gets injected into the query.

Let assume that the input was “Mich” the query would then become the below:

"SELECT * FROM users WHERE name = 'Mich'";

And this query will be processed and retrieve all data for the user with the name Mich.

If an attacker inputs data containing characters or strings that have a special meaning to the SQL interpreter, like (;, —, or ‘), and the data is not properly sanitized or validated, the attacker can modify the intended behavior of the SQL query in order to perform a malicious intent on the database.

Here is an image of the input field which will better explain how the query changes.

• If the Firstname supplied is Mich’ OR ‘1’ = ‘1 The Injected SQL will be like SELECT * FROM users WHERE name = ‘Mich’ OR TRUE. This will return all entries from the user’s table.
• If the Firstname supplied is Mich’ OR 1 = 1; — The Injected SQL will be like SELECT * FROM users WHERE name = ‘Mich’ OR TRUE;–‘; This is also like the first example, which will return all entries from the user’s table.

The below image depicts a high-level diagram of a SQL Injection Attack:

[image source]

Injection Mitigation:

• Making use of Prepared Statements with Parameterized queries.
• Making use of Stored Procedures.
• Implement input validation and sanitization.
• Make sure you are escaping all user-supplied input.

#2) Broken Authentication

Example: Session Time-out, Credential Stuffing

Among the OWASP top 10 critical vulnerabilities, is the broken authentication where attackers exploit to impersonate a legitimate user online.

This vulnerability is always in two areas: session management and credential management. These two are classified as broken authentication because either of these two can be used to hijacked session IDs or can steal login credentials.

[image source]

Attackers employ different means to take advantage of these weaknesses, which range from credential stuffing to some other highly targeted ways of gaining unauthorized access to someone’s credentials.

According to OWASP this form of vulnerability can come in various ways. Your web application has a broken authentication if it does the following:

1. Allows automated attacks such as brute-force attacks, where an attacker tries different usernames and passwords to carry out an attack.
2. Allows default and weak passwords. Example: password, admin.
3. Allows a weak credential recovery system or forgot password workaround.
4. Allows plain text, unencrypted passwords.
5. No multi-factor authentication system is in place.
6. If your session ID gets exposed in the URL.
7. If it fails to renew session ID each time for a new session.
8. If it fails to kill every session ID or tokens after application log out or after the time specified for inactivity expired.

According to OWASP most of these vulnerabilities are because of a lack of security requirements before kick-starting an application development project.

Many organizations today put more emphasis on the functionality test of the application and cannot conduct a non-functionality test like the security test of the application, which is very important.

Broken Authentication Mitigation:

• Making use of captcha.
• Reduce the number of tries for a particular user based on the session ID or the IP.
• Blocking multiple requests coming from the same IP.
• Making the admin login page inaccessible to the public.
• Implement multi-factor authentication to prevent brute-forcing and credential theft.

#3) Sensitive Data Exposure

Example: Unencrypted data

This is one of the most critical OWASP Top 10 vulnerabilities to compromise data that needed protection.

This is also known as information disclosure or information leakage. This usually occurs when an application or website unknowingly discloses sensitive data to users who do not have the privilege of view or access.

According to OWASP, these are some of the information that may get leaked to the public:

• Financial information
• Login credentials
• Commercial or business data
• Health record
• Technical details about the application or website.

Even though you may not be using DEBUG=True, but you need to be careful when administering the configuration setting. Always make sure that all sensitive variables use one of these keywords:

1. TOKEN
2. API
3. PASS
4. SECRET
5. SIGNATURE
6. KEY

Sensitive Data Exposure Mitigation:

• Always identify and classify which data is sensitive according to the privacy laws and the regulatory requirements.
• Immediately remove any data that is not needed to be stored.
• If you are going to be store any sensitive data, make sure it is encrypted at rest.
• Use proper key management.
• Make sure you encrypt all data in transit with security protocols such as TLS and SSL.
• You can enforce encryption on your application simply by using HTTP Strict Transport Security (HSTS).
• Do not cache sensitive data.
• Always store passwords with different encryption methods.

#4) XXE Injection

Example: File Retrieval, Blind XXE

OWASP lists XML external entity injection (also known as XXE) as a security vulnerability that gives a malicious user access to an application that processes XML data or parses XML input.

This attack is always successful because of XML input containing a reference to an external entity which is processed by an XML parse that was configured improperly. When this vulnerability is successfully exploited, it allows an attacker to view files on the application server and to interact with any other back end or external system that the application can access.

This XXE attack can further be escalated to compromise other back-end or underlying servers through Server Side Request Forgery (SSRF) attacks.

When you send data to the server in XML form, it is not vulnerable, but the actual vulnerability lies in the way the XML is parsed.

When XML parsers that allow DTD retrieval (Document Type Definition) do not have a proper input validation of the XML data in place then it could be vulnerable to XXE injection allowing an attacker to inject command or content within an XML document.

[image source]

According to the OWASP Top 10, the XML external entities (XXE) attack can exploit these:

1. Vulnerable XML parser that allows an attacker to upload XML or include a hostile command in an XML document.
2. Vulnerable integration.
3. Vulnerable dependencies.
4. Vulnerable code.

XXE Injection Mitigation:

• You must disable DTD and XML external entity features.
• All the XML processors and libraries used within the application must always be updated and patched.
• There is a need to put a proper validation in place for every user inputs.
• Use good XML parsers that are not vulnerable by default.
• Make use of a very good SAST tool that can help detect XXE in your source code.
• Make sure XML and XSL file upload functionality validates every incoming XML by using XSD validation.
• Make use of API security gateways
• Make use of WAF (Web Application Firewall) to detect, block any XXE attacks and can be used for closed monitoring.
• You can start making use of JSON data format, which is less complex.

#5) Broken Access Control

Example: Privilege Elevation, JWT Invalidation

Access control sometimes referred to as authorization, is how a web application grants access to users while denying access to other users. It can also control access to contents and functions on an application.

These access control checks are usually done after authentication has been completed, as this will authorize what a user may do on an application. The application could function in a system where there are groups set up with different roles and privileges.

Broken access control always provides access to user accounts to an attacker, and the attacker can act or operate like the administrator and access unauthorized data, sensitive files, and even change access rights.

The following are examples of Broken Access Control:

• Access to an admin panel.
• Access to a server via FTP / SFTP / SSH.
• Access to a website’s control panel.
• Access to other restricted applications on your server.
• Access to a database.

Broken Access Control Mitigation:

• Use a proper session management method.
• Use a token for authorization of users like JWT.
• Always deny public access by default except in rare cases for some resources that needed to be accessed publicly.
• Regular audit and test access controls should be conducted to confirm its functionality.
• Disable the web-server directory listing and confirm backup files are not present in the web roots.
• Make sure you have an access control set up that will enforce the right to every user like what each user can perform and not that the user can create, update, delete and read any record.
• There is a need for domain models that will enforce business limit requirements.

#6) Security Misconfiguration

Example: Misconfigured HTTP Headers, Default configuration

OWASP also lists security misconfiguration as one of the Top 10 vulnerabilities that can affect an application today. This attack can happen at any level of an application stack, which can be a web server, database, network services, platforms, application server, frameworks, custom code, virtual machines, containers, and even storage.

One tool that is very good at detecting this type of weakness is an automated scanner, which will always detect any misconfiguration, default accounts, and configurations.

This kind of configuration flaw can give attackers unauthorized access to some system data or functionality, which can lead to a complete system compromise and the entire system shut down.

[image source]

According to OWASP, an application might be vulnerable if the application is:

• Missing an important security hardening across any part of the application stack, or the cloud services permissions is not configured well.
• When you enabled or installed features that are not required (e.g. ports, services, privileges, accounts, and pages).
• When all default accounts and their passwords are still enabled and can be reached.
• When the latest security features are disabled or not configured securely on an upgraded system.
• When libraries, frameworks, application servers, databases are not set to secure values.
• When the server does not send security headers or they are not set to secure values.
• Make use of a component that is out of date or vulnerable to attacks.

Security Misconfiguration Mitigation:

• A regular hardening of the application environment is very important, and it’s fast and easy to deploy another environment that is properly locked down. Each environment should be configured identically, but with different credentials.
• Make sure you review and update all the configuration settings appropriate to all security updates and patches that are part of the patch management process.
• Making sure you send security directives to clients, e.g. Security Headers.
• Create automated process environments to verify the effectiveness of the configuration settings.

#7) Cross-Site Scripting

Example: Session Hijacking

According to OWASP, Cross-Site scripting, otherwise known as XSS is a client-side code injection.

In this form of attack, the attacker tries to inject malicious script into a trusted site. This script is in the form of JavaScript code, which can redirect a victim from their legitimate site to an attacker site without their knowledge.

This weakness in an application allows an attacker to steal cookies, steal user sessions, and thereby gaining illegitimate access to the system. Sometimes Cross-Site Scripting can join other vulnerabilities to create a greater attacking impact on an application.

According to OWASP Top 10 we have three types of cross-site scripting:

• Reflected XSS
• Stored XSS
• DOM XSS

Reflected XSS: This type of attack happens when the user inputs are returned by a web application error message, webpage search result, or other response that includes some or all of the input provided by the user as part of the request without making that data safe to be rendered in the browser.

Stored XSS: This usually occurs when user input is stored on the target server as the database, message forum, and comment field. A victim can get the stored data from the web application without the data safe to be rendered in the browser.

When a vulnerable XSS payload is injected, then every user that visits that page or comment section would see the impact of the posted XSS.

DOM XSS: This type of XSS is when JavaScript receives a user-controllable code and passes it to a sink for code execution. Some examples of sinks are inner Html, document.write, window.location. Cross-site scripting attacks include session hijacking, account takeover, 2FA, and MFA bypass.

One basic JavaScript code to prove XSS exploit is <script> alert(“You are Hacked”) </script>.

When you perform a search query with this payload, you will see that the browser can render the script tag and execute JavaScript and this will pop up “You are hacked” as the message and confirmed XSS exploit.

Cross Site Scripting Mitigation:

• We can encode the following characters with HTML entity encoding to prevent any execution of any form.
  • & –> & amp;
  • < –> & lt;
  • –> & gt;
  • ” –> & quot;
  • ‘ –> &# x27;
• CSS encode and make sure it’s validated before Inputting untrusted data into HTML Style Property Values.
• Using frameworks like Ruby on Rails and React JS that escape XSS with ease.
• JavaScript encode Before Inputting untrusted data into JavaScript data values.
• HTML encode JSON values in an HTML context and read the data with JSON.parse.
• URL encode Before Inputting Untrusted Data into HTML URL Parameter Values.
• Implement Content Security Policy.
• Use HTTPOnly cookie flag.
• Deploy firewall that protects against XSS.

#8) Insecure Deserialization

Example: Remote Execution

This vulnerability is included in the OWASP Top 10 list based on an industry survey carried out.

We have some ready-made tools that can discover insecure deserialization weaknesses, but to validate the authenticity of this flaw, human assistance is required. More reports for deserialization flaws will continue to increase as we now have different tools that are now being developed to help identify and address this problem.

Even though the discovery of this security flaw is not rampant but the impact of deserialization flaws cannot be underemphasized. These security weaknesses can cause an RCE attack (Remote Code Execution) which is one of the major attacks available.

The impact this has on the business lies in the protection needs of the application and its data and this can lead to the two types of attacks below:

• Data and object attacks where the attackers change the application logic or perform an arbitrary remote code execution if there are classes available to the application that can change behavior during and after deserialization.
• Data-tampering attacks like access control attacks.

Insecure Deserialization Mitigation:

• Do not allow serialized objects from unreliable sources.
• Always carry out some integrity checks like digital signatures on serialized objects in order to prevent compromising of data and hostile object creation.
• Always carry out enforcement of strict type constraints when doing deserialization before the creation of the object.
• Make sure you isolate and run code that deserializes in low privilege environments when possible.
• Make sure that deserialization exceptions and failures are properly logged, like where the incoming type is not the same as the expected type.

#9) Using Components With Known Vulnerability

Example: Open Source Components

This vulnerability results from a developer using a component, framework, library, or some dependencies that already have a known vulnerability that may compromise the entire system.

When such components are executed with full privileges and it’s vulnerable, this will make the exploitation from an intruder very easy, which may cause some serious data loss or server takeover.

There is also a get version feature that will always inform you of the version of the library the app uses. You can as well Google a library with the present version and get the POC and vulnerability details.

Components with Known Vulnerability Mitigation:

• Always remove any unused dependencies, unnecessary features, components, and files.
• Always obtain your application components from approved and official sources with secure links. This will reduce the chance of including any malicious component in your application.
• Always check and avoid frameworks, libraries, and components that are not maintained and do not have security patches for older versions.
• Always use library scanners to test for any vulnerabilities in the application packages you are using.

#10) Insufficient Logging & Monitoring

Example: Missing Security Information, Missing Log

The importance of securing a website or application through sufficient logging and monitoring cannot be underemphasized because improper logging can result in information disclosure.

Even though 100% security is uncertain but there are ways we can keep our website or application monitored regularly and when we noticed something strange, we can quickly take action to prevent any attack.

If your website does not have an efficient logging and monitoring process, it is prone to be exploited and can damage the reputation of an application or website. So there is a need for keeping an audit log because this is very important if we want to know or discover any suspicious change to our application or website.

This audit log is a system put in place that records every event going on the website and you can be able to spot any anomalies and it can be quickly remediated.

OWASP always recommends that you cannot leave your website or application unattended or unprotected where there is no patching available you can still make do with virtual patching which can save your day in the event you are running out of date components on your website or application.

If you are using WordPress for your websites, there are some WordPress security plugins available that you can use for logging and monitoring your websites, as this will save you a whole lot of stress in getting an audit log system in place.

Insufficient Logging & Monitoring Mitigation:

• Always ensure that every log is captured in a way that a management tool can easily use it.
• Every transaction on an application should have an audit trail with integrity controls in place so that transactions cannot be manipulated, even delete.
• There is a need to implement a very effective and efficient monitoring and alerting system which will always inform us of any malicious or suspicious activities so that they can be immediately remediated.
• Make sure the audit log does not store your password and any other sensitive content, as this is very risky.

Frequently Asked Questions

Q #1) What are OWASP’s top 10 security vulnerabilities?

Answer: These are listed below:

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 Vulnerability
10. Insufficient Logging & Monitoring

Q #2) What are OWASP standards?

Answer: OWASP standards are always released to help in the actualization of building secure applications.

One of OWASP standards is the Application Security Verification Standard (ASVS) this standard provides security control guidelines for testing web applications and provides a requirement that will assist the developers to build secure software.

Q #3) What is OWASP security risk?

Answer: The OWASP Top 10 is a list of application vulnerabilities for developers and web application security experts. It is a list that contains some of the major and critical vulnerabilities that affect applications and websites.

Q #4) Why is OWASP Top 10 important?

Answer: The OWASP Top 10 is very important because it gives a headway to organizations on how to treat the security of their applications and it helps them with priority over which security risk to focus on.

This document help organization understand, identify, mitigate, and fix vulnerabilities in their technology stack according to impact and exploitability.

Q #5) How does OWASP work?

Answer: The Open Web Application Security Project (OWASP), is a non-profit organization that has the sole aim of helping the global community on improving the security of software through the use of community-developed open source applications, creation of local chapters all over the world.

Q #6) Is OWASP a framework?

Answer: OWASP itself is not a framework rather, the foundation develops the OWASP-SKF (OWASP Security Knowledge Framework) which is an open-source web application that every organization can use for their secure coding practices and it is in multiple programming languages.

Conclusion

We have now covered OWASP’s Top 10 security vulnerabilities that exist globally. We have discussed what could cause these vulnerabilities, the effect these security weaknesses can bring, and what can be done to mitigate these vulnerabilities.

Note that OWASP is not making any rule or law behind the OWASP’s Top 10 security vulnerabilities and they are not forcing anybody to follow their security guide.

They only released this list to help individuals or organizations on what to look for when they are developing websites or web applications and how they can always develop secure applications for the public.