Start building your own chatbot now

The reality is that every single web application is vulnerable to something. Knowing what types of vulnerabilities are the most exploited and how to mitigate the risks will give you an advantage in securing your web application.

In this article, we will try to fill the gaps in security awareness by breaking down the top 10 web security vulnerabilities according to the Open Web Application Security Project (OWASP).

OWASP is an online community that creates free articles, methodologies, documentation, tools, and technologies in the field of web application security. Every three to four years, OWASP releases a list of the top 10 most common web application vulnerabilities. OWASP also provides  a scale that measures the exploitability, detectability, and technical impact score.
OWASP uses its own risk rating methodology to rate every vulnerability with a score that helps the audience understand the severity and the impact of the attacks.

In this article, we will focus on 3 out of 4 score metrics.  You can learn more about it on their website.

OWASP ratings

  • Exploitability: Refers to how easy or how difficult it is for an attacker to exploit vulnerabilities. The score can be “Easy”, “Average”, or “Difficult”.
  • Detectability: Refers to how easy it is for attackers and other users to find vulnerabilities.
    The score can be “Easy”, “Average”, or “Difficult”.
  • Technical impact: Refers to what the damage would be if the vulnerabilities are successfully exploited.
    The score can be “Minor”, “Moderate”, or “Severe”.

Okay, now that we have established the rating categories of these vulnerabilities, let’s dive into the top 10 vulnerabilities.

1. Injection 

sql-injection

Exploitability score: Easy
Detectability score: Easy
Technical Impact score: Severe

What is it?

An injection of code happens when an attacker sends invalid and untrusted data to the application as part of a command or query. The attacker has the malicious intention to trick the application into executing unintended behavior to collect data or create damage.

Some of the more common injections are:

  • SQL
  • OS command
  • ORM
  • LDAP
  • Expression Language (EL) or OGNL injection

Example of an attack

According to OWASP, one of the most common examples is the SQL query consuming untrusted data.

string-query-sql-1

This query can be exploited by modifying the “id” parameter value as follow:

string-sql-query

This makes a request to the application to return all records from the account table, other similar and more severe injections can modify the data, and even cause a loss of data.

How to prevent it?

The main reason for injections to happen is the lack of validation and sanitation of data consumed by the application. The recommendations to prevent injection depends on the technology you are using. In general, you have to make sure that your development team is following security requirements when writing code.

Some pointers to prevent the injection of code:

  • Keep data separate from queries. This is the main key to prevention.
  • Use safe APIs to eliminate the use of an interpreter. This lowers the risk of SQL injections.
  • Create a “white list” for server-side input validation.
  • Use LIMIT and other SQL controls to prevent mass disclosure in case of an attack.

2. Broken Authentication

broken-authentication

Exploitability score: Easy
Detectability score: Average
Technical Impact score: Severe

What is it?

Broken authentication vulnerabilities allow attackers to use manual or automatic ways to gain control over any account in a system and even gain total control.

Web applications are one of the most vulnerable and common targets. Attackers have access to and information about hundreds of millions of combinations of usernames and passwords for default administrative accounts. This access allows the attackers to easily perform dictionary attacks, automated brute force and others GPU cracking tools in other to gain access to a system.

Other types of broken authentication include poor session management such as the lack of properly validating sessions ID.  Correct session management can include, for example, making sure that authentication tokens, especially the single sign-on token (SSO), are properly invalidated when the user logs out or after a period of inactivity.

Example of an attack

“According to OWASP, “Credential stuffing” which is the use of lists of known passwords, is one of the most common attacks. If an application does not rate limit authentication attempts, the application can be used as a password oracle to determine whether the credentials are valid.” – OWASP

How to prevent it?

The development team must implement the best practices for web security followed by external security audits and testing the code before shipping it out.

Other common pointers include:

  • Do not deploy any default credentials
  • Store passwords using a modern one-way hash function
  • Implement weak password checks against a list of the top 10000 worst passwords.
  • Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes
  • Implement multi-factor authentication to prevent credential stuffing, brute force, and stolen credential attacks.
  • Log authentication failures and alert administrators when attacks are detected.
  • Limit the attempts for authenticating
  • Secure your password storage

3. Sensitive Data Exposure

sensitive-data-exposure

Exploitability score: Average
Detectability score: Average
Technical Impact score: Severe

What is it?

Sensitive data exposure has been one of the most popular vulnerabilities to exploit.  It consists of an attacker compromising data that should have been protected.

The Gemalto’s breach level index shows that just in the first half of 2018, there were 945 data breaches that led to 4.5 billion data records being compromised. This data shows how rapidly global data breaches have accelerated, with a 133% increase over the 3 years.

Sensitive data such as passwords, credit cards numbers, credentials, social security numbers, health records and PII (Personally identifiable information) require extra protection. Hence, it is critical for any company to understand the importance of protecting users’ data.

Example of an attack

According to OWASP, one of the most common and serious situations is when a site doesn’t use or enforce TLS for all pages, or if it supports weak encryption.

“An attacker can simply monitor the network traffic, intercept the TLS, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. This attack can be modified in other ways such as changing the recipient of a money transfer.” – OWASP

How to prevent it?

Data should be protected at all times –  while at rest and also while in transit. Not encrypting sensitive data is the main reason why attacks are so common nowadays.

However, even encrypted data can be broken into due to weaknesses in:

  • Password hashing storages
  • Key generation process
  • Key management
  • Protocol usage

Some other pointers:

  • Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
  • Classify data processed, stored, or transmitted by an application.
  • Apply controls according to the classification.
  • Don’t store sensitive data unnecessarily.
  • Discard data as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
  • Make sure to encrypt all sensitive data at rest.
  • Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
  • Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters.
  • Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
  • Disable caching for responses that contain sensitive data.
  • Ensure that stored passwords have a strong adaptive algorithm such as Argon2, scrypt, bcrypt, or PBKDF2.
  • Verify independently the effectiveness of your settings.

4. XML External Entities (XXE)

Exploitability score: Average
Detectability score: Easy
Technical Impact score: Severe

What is it?

An XML attack happens when an application that parsers XML input is attacked. The attack can occur when XML input contains a reference to an external entity and when the reference is processed by a weakly configured XML parser. Such an attack may lead to the disclosure of sensitive data, DOS attack, server-side request forgery, and so on.

Example of an attack

DTDs: XXE attack
The red circles indicate the evil entity inside a request.

xxe-attack

xxe-attack-steps

How to prevent it?

  • Most XML parsers are vulnerable to XXE attacks. This is why it is so important to train the  developers, so they can learn to identify and mitigate risks.
  • The safest way to prevent XXE is always to disable DTDs (External Entities) completely depending on the parser. The configuration method should be something like the following:
    As a bonus, disabling DTDs also makes the parser secure against a denial of service attack. If you want to learn more about prevention guidance for a specific language and commonly used XML parsers, I recommend taking a look at the OWASP XML cheat sheet.
  • Implementing positive or “whitelisting”: input validation, sanitation, and filtering can help to prevent hostile data within XML documents, headers or nodes.
  • Patch or upgrade the latest XML processors and libraries in use by the application or by the operating system. Use dependency checkers to manage the risk from necessary libraries and components for any integrations.
  • Verify that xml/xls file upload functionality validates the XML using XSD validation or something similar.

5. Broken Access Control

Exploitability score: Average
Detectability score: Average
Technical Impact score: Severe

What is it?

Access control or authorization in web application means that the app puts a limit on what content and functions should be available to different users. Broken access control is the problem that emerges when the application doesn’t have a centralized access control thus resulting in every complicated scheme that can lead to developers making mistakes and leaving open vulnerabilities.

Example of an attack

The application uses unverified data in a SQL call that is accessing account information:

sql-query-string

An attacker simply modifies the ‘ACCT’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

http://example.com/app/accountInfo?acct=notmyacct

How to prevent it?

  • Follow the Principle of Least Privilege, where the user should only have access to the minimum privileges that are necessary to perform actions. Nothing more than what their role is intended to do.
  • Implement access control mechanisms once and re-use them throughout the application.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update or delete any record. For example, a user should only be able to modify or delete data that is their own. If I log in to an application, I should only be allowed to modify my data.
  • Domain access controls are unique to each application, but business limit requirements should be enforced by domain models.
  • Disable web server directory listing, and ensure file metadata such as git is not present within web roots.
  • Monitoring and logging are extremely important when access control fails the incident should be logged and send an alert to admins.
  • Use Rate limiting API and controller access to minimize the harm from automated attack tooling.
  • It is recommended for developers and QA engineers to include functional access control unit and integration tests.

6. Security misconfigurations

system-hacked

Exploitability score: Easy
Detectability score: Easy
Technical Impact score: Moderate

What is it?

Just as the name implies, security misconfigurations happen when vulnerabilities or security configurations are overlooked. This includes:

  • Having unprotected files on public servers
  • Having unpatched dependencies
  • Leaving credentials with default authentication
  • Anything that should be properly secured but is not yet mitigated.

This vulnerability often happens when security checks or SDL (Secure development lifecycle) is not in place.

Example of an attack

According to OWASP, one of the most common scenarios is the following:

“Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.” – OWASP

How to prevent it?

  • A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down.
  • Development, QA, and production environments should all be configured identically (with different credentials used in each environment). The process can be automated to minimize the effort required to set up a new secure environment.
  • Remove or do not install any unnecessary features, components, documentation, and samples.
  • Remove unused dependencies and frameworks.
  • Establish a prioritizing system to deploy all updates and patches in a timely manner to each deployed environment. This process needs to include all frameworks, dependencies, components, and libraries (free of vulnerabilities).
  • Promote a strong application architecture that provides effective secure separation between components, with segmentation, containerization, or cloud security groups.
  • An automated process to verify the effectiveness of the configurations and settings in all environments.

7. Cross Site Scripting (XSS)

cross-site-scripting

Exploitability score: Easy
Detectability score: Easy
Technical Impact score: Moderate

What is it?

Cross Site Scripting is one of the most common vulnerabilities that affect many web applications. XSS attacks are essentially malicious injections (client-side) that are added to a web page or app through user comments, form submissions, and so on. The main danger behind XSS is that it allows attackers to inject content into the web app. The injected content  can modify how it is displayed, forcing the browser to execute the attacker’s code.

Example of an attack

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

html-snippet-cc-parameter

The attacker modifies the ‘CC’ parameter in the browser to:

cc-parameter

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the victim’s current session.

How to prevent it?

  • Use safer frameworks that automatically escape for XSS by design, such as in Ruby 3.0 or React JS.
  • Escape untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) to resolve Reflected and Stored XSS vulnerabilities. The OWASP XSS Prevention Cheat Sheet has details on the required data escaping techniques.
  • Apply context-sensitive encoding when modifying the browser document on the client-side to act against DOM XSS. When this cannot be avoided, similar context-sensitive escaping techniques can be applied to browser APIs as described in the OWASP DOM based XSS Prevention cheat sheet.
  • Enable a Content Security Policy (CSP), which is a defensive, in-depth mitigating control against XSS. This assumes that no other vulnerabilities exist that would allow placing malicious code through local files including path traversal overwrites, or vulnerable libraries in permitted sources, such as content delivery network or local libraries.

8. Insecure Deserialization

deserialization-processExploitability score: Difficult
Detectability score: Average
Technical Impact score: Severe

What is it?

When data is stored or transmitted, the bits are serialized so that they can later be restored to the original structure. Deserialization is the process of reassembling a series of bits back into a file or object. Insecure deserialization can allow deserialized data to be modified to include malicious code that will likely damage the application if the data source is not verified.

Example of an attack

A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other states:

php-super-cookie

An attacker changes the serialized object to give themselves admin privileges:

serialized-object

How to prevent it?

  • Implement integrity checks or encryption of the serialized objects to prevent hostile object creation or data tampering
  • Isolate code that deserializes, such that it runs in very low privilege environments, such as temporary containers.
  • Log deserialization exceptions and failures such as where the incoming type is not the expected type, or the deserialization throws exceptions.
  • Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitor deserialization to sound alerts if a user deserializes constantly.

9. Using Components with Known Vulnerabilities

 

 

 

 

 

 

Exploitability score: Average
Detectability score: Average
Technical Impact score: Moderate

What is it?

As the name implies, the use of components with known vulnerabilities can put your web security at risk. When vulnerabilities are known, in most cases, vendors can fix them right way and release a patch or update. The problem is that many development teams fail to have an effective patching and tracking of 3rd party dependencies, either because they lack the awareness or because of a tight schedule.

To maximize security in your application, it is highly recommended that every development team have at least one person responsible for tracking, patching and for making sure the components are free of vulnerabilities. Security is a collective effort – thus everyone can contribute by communicating any vulnerabilities they may know to the engineering leads.

Example of an attack

“In 2017, a researcher found the vulnerability “CVE-2017-5638”, which leads to remote code execution in web applications using Apache Struts. This vulnerability has been blamed for many major data breaches.”– OWASP

An attacker can carry out some research about the components and dependencies of your application, look for vulnerabilities in those components, and try to exploit them. Cybercriminals are often looking at how to exploit the latest vulnerabilities posted in security and hacking forums, which is why patching your dependencies as soon as possible is recommended.

How to prevent it?

  • Software projects should have a process in place to remove unused dependencies, unnecessary features, components, files, and documentation.
  • Have a continuous inventory of the versions of both client-side and server-side components and their dependencies using tools like versions, DependencyCheck, retire.js, and so on.
  • Continuously monitor sources like CVE and NVD for vulnerabilities in your components. Use software composition analysis tools to automate the process.
  • Only obtain your components from official sources and, when possible, prefer signed packages to reduce the chance of getting a modified, malicious component.
  • Many libraries and component do not create security patches for out-of-support or old versions, or it simply do not continue maintenance. If patching is not possible, consider deploying a virtual patch to monitor, detect or protect against the discovered issue. Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

10. Insufficient Logging and Monitoring

dog-fire-this-is-fine

Exploitability score: Average
Detectability score: Difficult
Technical Impact score: Moderate

What is it?

A hacker’s dream is to be able to carry out malicious acts without ever getting detected. If you do not ensure that monitoring and logging are in place, you are fulfilling the hacker’s dream.

By monitoring for suspicious activities, such as failed logins, invalid input (injections), weird API calls and so on, organizations can potentially detect and stop suspicious activity.

Example of an attack

“An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although the source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.” – OWASP

How to prevent it?

  • Ensure all logins, access control failures, and input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts.
  • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
  • Establish effective monitoring and alerting such that suspicious activities are detected and responded to within acceptable time periods.
  • Establish or adopt an incident response and recovery plan.
  • Use commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as mod_security with the OWASP Core Rule Set, and log correlation software such as ELK with custom dashboards and alerting. Penetration testing and scans by DAST tools (such as OWASP ZAP) should always trigger alerts.

In conclusion

Now that we have learned more about the top 10 vulnerabilities for web security and some tips about how to avoid them, there is still some work to do for developers, security testers, managers and organizations. Remember that security is a collective effort, so the best thing you can do to protect your application is to keep learning about security. Here are a few things you can do to enhance your knowledge:

For developers

For security testers

  • Become an expert at threat modeling
  • Help managers implement the Security Development Lifecycle
  • Learn new testing strategies
  • Keep informed about the latest vulnerability trends and potential attacks
  • Do your own research on vulnerabilities

For managers

  • Be aware of your organization’s requirements
  • Negotiate a budget to cover security activities including testing and design
  • Integrate SDL as soon as possible
  • Educate Developers (refer to developers resources above)
  • Promote a security culture by creating awareness campaigns

For organizations

Thanks for reading! And don’t forget to head over to our platform to build your own chatbot.

Happy and secure bot building 🤖

Want to build your own conversational bot? Get started with SAP Conversational AI !

Follow us on
  • Ye Man Aung

    Support for the future and to be successful in the development for my account access issues permission.

  • sandsberg

    Thanks for this post.

This site uses Akismet to reduce spam. Learn how your comment data is processed.