OWASP Top 10 Vulnerabilities, Application Security Attack Examples (With Recommendations)

What is OWASP?

OWASP stands for The Open Web Application Security Project. It is a non-profit foundation that works to improve application security for software. Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications. Please read our article to learn more about the OWASP top 10 vulnerabilities with examples.

To view a concise version of this article, we invite you to watch our video on the same topic.

What are the OWASP Top 10 vulnerabilities?

The OWASP Top 10 is a standard for developers and web application security, representing the most critical security risks to web applications. By using the OWASP Top 10, developers ensure that secure coding practices have been considered for application development, producing more secure code. We have included OWASP top 10 risks with examples to equip the reader within the context of application security attacks.

We have included OWASP Top 10 attacks and defences in this article. For API security, read OWASP API security Top 10 article. 

OWASP Top 10 Testing Guide

OWASP has been releasing testing guides for a few years, detailing what, why, when, where and how of web application security testing. 

This includes testing techniques explained, covering the following areas:

• Manual Inspections & Reviews
• Threat Modelling
• Source Code Reviews
• Penetration Testing

OWASP Top 10 Testing tools and processes that help identify vulnerabilities and fix the risks include:

• Web Application Penetration Testing
• Source Code Reviews
• Manual Inspections & Reviews

What are the OWASP Top 10 Application Security Risks? How to prevent Web Application Attacks?

Injection  

Injection flaws in the security world are one of the most famous vulnerabilities. Injection flaws such as SQL, NoSQL, OS, LDAP, HTML, JS occur when untrusted data or untrusted input is sent to an interpreter as part of a query or a command. If it’s sent as a query, then it’s known as script injection (SQL, HTML). If it’s sent as part of a command, it is known as command injection (for example, OS, LDAP). Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.

Due to the attractiveness of databases containing secret information, unfortunately, SQL injection attacks have been a prevalent attack vector in the recent past.

Example

An example of SQL injection vulnerability would be UNION or Blind SQL injection attacks to enumerate information from the database. In OS command injection, some of the useful commands are whoami, uname -a (Linux), ver (windows), netstat, ping, etc., for initial information about the underlying system. Further exploitation is performed by attackers leading up to compromise by initiating connections to attacker owned systems outside or escalating privileges on the underlying system.

How do you prevent injection flaws?

The core concept behind injection flaws is the lack of input validation and sanitisation of data used by the application. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.

To protect web applications against SQL injection attacks, it is important to separate data from commands and queries. The use of prepared statements (with parameterised queries) is how developers should write database queries. This allows first to define all the SQL code and then pass each parameter to the query, distinguishing between code and data irrespective of user input (malicious or legit).

Broken authentication

A broken authentication vulnerability could allow an attacker to utilise manual or automatic methods to take over a user account, leading to complete control of the underlying system. Broken authentication and session management flaws are often identified during web application penetration testing projects. These flaws relate to authentication mechanisms such as login mechanisms, keys, session tokens, or implementation flaws that may allow an attacker to compromise passwords by launching brute force attacks, take over user sessions, enumerate legitimate user information, and related implications.

Examples of broken authentication vulnerabilities

• Username enumeration based on changes observed in the application’s behaviour to identify valid usernames.
• Brute-force attacks where an attacker uses a trial and error method to guess valid user credentials using wordlists of usernames and passwords.
• Applications allowing password attacks such as credential stuffing where stolen credentials from another database are tested against your application user accounts
• Allowing default, weak or trivial usernames and passwords
• Flawed two-factor verification logic where the application fails to verify the same user during the second step of the authentication mechanism

How to prevent broken authentication attacks?

Implement multi-factor authentication to prevent automated, brute force, credential stuffing attacks

• Do not allow username enumeration opportunities on forgot password, login forms, registration pages.
• Use input form such as secure captcha against automated attacks
• Do not allow new user registrations without verification of the new account
• Ensure password complexity is checked on the server-side, in line with password policy requirements

For the popular CMS (Content Management Systems), it’s quite easy to stop a large number of attacks that target default paths, installations or settings. For instance, you can restrict administration interface access to the visitors of the website (only needed for your developers):

• /wp-admin/ on WordPress
• /index.php/admin on Magento
• /umbraco/login.aspx on Umbraco
• /admin for OpenCart
• /user/login on Drupal
• /administrator on Joomla!

Sensitive data exposure

Insecure APIs and web applications do not protect sensitive user data such as PII (Personally Identifiable Information), payment information, application-related session tokens, or user accounts. This offers attackers an easy opportunity to commit identity fraud and other crimes using the information exposed by the application. To prevent these exposures, data transmission and data storage requires protection utilising encryption mechanisms and ensuring the application is free from logic flaws. This OWASP top 10 risk is mainly due to insecure coding practices and a lack of secure hardening measures.

Example

• Hard-coded credentials, internal IP addresses, API, access tokens, and other useful information the code
• Unprotected sensitive information found in cloud databases or online leading to credit card frauds and identity thefts 
• Providing access to source code files via backup or other directories via directory listing flaws
• Database tables, column names in error messages
• Examples of sensitive information include credit card numbers, personally identifiable information (PII), credentials, medical information, national insurance numbers, social security numbers and any other personal information that may lead to identity or financial fraud.

How to prevent sensitive information exposure?

The two types of data, i.e. data in transit and data at rest, should be secured against unauthorised access at all times. Protecting data in transit is often linked to the usage of secure channels when data is transported from one place to another. On websites, this is done by ensuring a secure encryption mechanism in SSL/TLS certificates. SSL is an obsolete protocol now replaced by TLS (Transport Layer Security) certificates. These certificates help protect the integrity of data in transit between the web server and a user’s web browser. Enforce perfect forward secrecy ciphers, cipher prioritization by the server and secure parameters. Directives such as HTTP Strict Transport Security (HSTS) shall support all communications over HTTPS. 

Data at rest is protected based on multiple factors surrounding the environment it is stored in. OWASP recommends preventing sensitive data exposures using the following ways:

• Classifying the data processed, stored or transmitted by an application where data sensitivity is defined as per local privacy laws, regulatory requirements or business needs.
• Applying controls relevant to the data classification.
• Ensure sensitive data at rest is encrypted at all times.
• Store passwords using strong salted hashing functions with a delay factor such as Argon2, scrypt, bcrypt, or PBKDF2.
• Use PCI DSS compliant tokenization or truncation where sensitive data storage is required. This ensures part data is stored and can’t be used if stolen.
• Verify the effectiveness of your controls utilising independent penetration testing services. 

XML External Entities (XXE)

XML external entities (XXE) injection, also known as XXE, is a web application vulnerability that allows a threat actor to inject XML containing a reference to an unauthorised external entity and is processed by XML parser (either older or misconfigured). This could allow an attacker to perform internal port scanning, remote code execution or Denial of Service attacks. In some cases, an attacker can exploit XXE flaws to compromise the entire server to perform server-side request forgery (SSRF) attacks.

Example

Examples of XML external entities (XXE) attacks would involve exploiting External Entities to perform data exfiltration, retrieve files in the application’s response, and perform SSRF attacks.

An attacker would attempt to perform command injection through a vulnerable application as:

<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
&xxe;

The above request, when processed successfully, shall run the OS command file:///etc/passwd returning us results for xxe entity.

An attacker would probe an internal network by changing the ENTITY

<!ENTITY xxe SYSTEM https://192.168.100.100/private >]>

A no brainer for an attacker to attempt a denial of service attack would be:

<!ENTITY xxe SYSTEM file:///dev/random >]>

How to prevent XML External Entity (XXE) attacks?

Unfortunately, many XML parsers are vulnerable to XXE attacks by default. 

OWASP recommends the following measures to prevent XML External Entity attacks:

• Use less complex data formats such as JSON and avoid serialisation of sensitive data.
• Upgrade all XML processors and libraries in use by the application.  
• Update SOAP to 1.2 or higher versions.
• Implement server-side checks to prevent dangerous input within XML documents.
• Disable XML external entity and DTD processing in all XML parsers.
• Refer to the excellent OWASP Cheat Sheet on XXE Prevention for extensive help.

Broken access controls

A broken access control attack is amongst the most known OWASP Top 10 web application vulnerabilities. This flaw relates to the lack of security restrictions around the access management process, allowing users to access, view or modify information they aren’t authorised under their current privileges. 

This could lead to horizontal or vertical privilege escalation flaws allowing the user access to other users information or higher privileged accounts information. Broken access controls are one of the dangerous flaws around due to privileged access possible after the exploitation.

Example

An example in a real-world application would be a standard nurse practitioner account in a hospital web portal that can approve/reject data records meant for approval from clinical leads (approver) only. Therefore, a low privileged user can access data that only a high privileged user should be able to access.

Another well-known broken access control would be an attacker gaining access to a server via file transfer mediums such as FTP, SFTP, SSH, Telnet. Similarly, an attacker could access hosting control or administrative panels such as CMS login.

This would allow an attacker to deface the website easily, change the settings or access underlying data.

How to prevent broken access controls?

• Review the server functionality against a secure hardening checklist to find flaws related to configuration, user accounts, privileges, and other access points. Ensure all basic practices are deployed to reduce the attack surface.
• Limit internet exposure of administrative panels (front end and back end) to specific IP addresses/ranges/locations.
• Apply logging and monitoring controls to keep an eye on various activities performed by users, including failed access attempts.
• Make use of reputed security resources. Some of these are free, such as Cloudflare, sucuri WordPress plugin.
• Utilise multi-factor authentication where possible.
• Based on the tech stack and underlying technTheren measures required. Please check and consult with your vendor based on the tech stack and underlying technologies. Get in touch for further help.

Security misconfigurations

A widespread security flaw often found during web application security assessments is security misconfiguration. These flaws result from insecure configurations, default settings or installations, verbose error messages containing sensitive information, insecure cloud storage, misconfigured settings on web servers.

Example

An example of this flaw is leaky Amazon S3 buckets disclosing databases leaking thousands of records online. In 2018, the Exactis data breach exposed a server database containing nearly 340 million individual records. The information exposed included personal information records, which were entirely preventable as the company failed to implement access controls on internet-facing Elasticsearch infrastructure used for data search and analytics.

How to prevent security misconfigurations in a web application?

• Ensure technical security baseline guides are at hand for IT and security teams to secure all installations with hardening measures.
• Ensure separate credentials for development, staging, QA, production environments.
• Follow multi-tier architecture that provides separation between different components. Follow the same principle against backend teams accounts, where corporate and production environment accounts are separate and enforced with different passwords.
• Regular audits to validate the security controls so that gaps are covered in time.

Cross-site scripting (XSS)

Cross-site scripting (XSS) flaws occur when an application processes untrusted data submitted via a web page without strict validation or when application updates record with user-supplied input. Cross-site scripting could allow an attacker to hijack sessions, deface websites, redirect to attacker-controlled/malicious websites.

Example

A high profile attack example is the XSS attack linked to Zoom’s sign-up page vulnerability. The application failed to validate the user input submitted, resulting in the execution of the injected script. XSS flaws are a very helpful attack vector for cybercriminals carrying out phishing campaigns because the link in a phishing email is from a legit website.

How to prevent XSS vulnerabilities?

The core reason for these vulnerabilities is server-side routines failing to sanitise the user input. This input is then processed by the users’ browser, leading to XSS attacks.

Reliable mitigation against Cross-site Scripting Attacks (XSS) involves correctly handling input validation and output encoding. A strong input validation involves the application rejecting any invalid characters (not needed in the input fields) using white-listed characters (needed for valid input, for example, numbers and alphabets in the username field). Output encoding/escaping should be performed on all special characters in HTML and JavaScript. An excellent source from OWASP to prevent Cross-site Scripting Attacks is a good read.  

Insecure deserialization

Serialization is a programming concept where an object is converted into byte strings to store or transmit to a memory location (for instance, database). Deserialization is the reverse of serialization, where bytes are converted back into an object for transfers. From URLs, web directory structures to serialized objects, security researchers look at all possible opportunities for vulnerabilities that can be exploited to gain access. 

Example of an insecure deserialization attack

An example attack scenario (out of multiple possibilities) would be a PHP forum using PHP object serialization to save a “super” cookie containing user information (such as user ID, privilege level, password hash). An attacker can change the serialized object to change the privilege level that the server-side accepts, allowing the user a higher privilege role. 

The following are examples of popular security incidents involving insecure deserialization vulnerabilities:

• A remote code execution (RCE) by uploading malicious files during server-side deserialization related to Chatopera, a java application (CVE-2019-6503).
• Unauthenticated, remote code execution in the .NET app Kentico (CVE-2019-10068).

How to prevent Insecure Deserialization attacks?

, Never trust any serialized objects from untrusted parties. 

Alternatively, digital signatures to sign serialized objects should ensure data integrity against any tampering attempts. A multi-layered approach consisting of audit logs, network traffic monitoring, running isolated code in low privileges and enforcing strict type constraints during deserializing should help.

Using components with known vulnerabilities

Web applications, services/APIs requiring third party components that may have known vulnerabilities might be oblivious to providing attackers with an entry route to the application. Even the simplest of websites have dependencies in the form of third-party libraries, plugins or other modules.

The complexity of this issue is not just related to the patching challenge alone. The underlying issue with all the components is timely support as not all web developers can keep up with the pace of updates, and sometimes legacy code doesn’t work after deploying components updates. Additionally, not all IT teams have the expertise to deploy security updates in time to avoid disrupting operations.

Vulnerable applications are mainly due to the following reasons:

• The development environment and its components
• Software components such as libraries, runtime environments, APIs and relevant components are vulnerable, unsupported or out of date.
• Nested dependencies or third-party components that haven’t been updated and are vulnerable to security issues.

How to prevent using components with known vulnerabilities?

• Like the patch management process for workstations in a network, there should be a patch management process to remove unused dependencies, unnecessary features, components, files and documentation. If patching is not possible, consider virtual patching.
• Consider replacing components where vendors are not actively supporting the maintenance, and look for alternatives.
• Ensure you have up to date inventory of all primary and third-party components, versions using tools such as dependency checker.

Insufficient logging and monitoring

Most successful attacks start with initial probing around web applications. Lack of logging and monitoring allows this activity to continue, raising the likelihood of successful exploitation that may end up with estate wide compromise. A threat actor buys time with a lack of logging and monitoring, increasing chances of infiltrating further into the network.

Examples

• Incorrect auditing configuration where important events such as failed logins or high-value transactions are not logged.
• Incorrect configuration of auditing and event monitoring solutions.
• Log storage is performed locally and allowed to be overwritten within 7 days (mostly).
• Application and API log not monitored for suspicious activities.

How to prevent insufficient logging and monitoring issues?

• Review and ensure correct auditing levels are in place based on the error types. For example, server-side input validation failures, access control failures, session tampering, all login events should be logged with sufficient user context.
• Ensure that logging and monitoring processes are defined and backed by incident response plans in the event of an attack.

How do you benefit from OWASP penetration testing?

Web application penetration testing is one of our core offerings under security testing services. Our team of skilled security experts with proven industry experience ensure comprehensive coverage for web application risks, especially issues such as business logic flaws, HTTP Smuggling, SSRF (Server-side request forgery), and many other business contexts that automated scanners or less experienced consultants often miss. This also means that the web application testing methodology surpasses this OWASP Top ten vulnerabilities list, as we concentrate on understanding the application functionality first. Once the working application is understood from a user’s perspective, a threat actor perspective is mixed to ensure malicious inputs can be attempted to check the secure coding practices behind the design.

As part of our delivery process, we ensure your development teams or third-party developers are fully aware of underlying issues including fixes. This would ensure secure coding practices are in place for all your future projects and lesser risks during web development. 

Cyphere offers various cybersecurity services, from penetration testing to threat intelligence, to help businesses strengthen their cybersecurity. Get in touch to discuss your primary security concerns.