OWASP Top 10 Security Risks – Part II

The OWASP Top 10 list consists of the 10 most seen application vulnerabilities:

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

Today, we are going to explore items 3 and 4: sensitive data exposure and XML External Entities (XXE).

3. Sensitive Data Exposure

Sensitive data exposure is one of the most widespread vulnerabilities. It consists of compromising data that should have been protected.

Examples of Sensitive Data

Some sensitive data that requires protection is:

• Passwords
• Credit card numbers
• Credentials
• Social Security Numbers
• Health information
• Personally Identifiable Information
• Other personal information

It is vital for any organization to understand the importance of protecting users’ information and privacy. All companies should comply with their local privacy laws.

Responsible sensitive data collection and handling have become more noticeable especially after the advent of the General Data Protection Regulation (GDPR). GDPR is a new data privacy law that came into effect May 2018. It mandates how companies collect, modify, process, store, and delete personal data originating in the European Union for both residents and visitors.

There are 2 types of data:

• stored data – data at rest
• transmitted data – data that is transmitted internally between servers, or to web browsers

Protecting Data in Transit

Both types of data should be protected. When thinking about data in transit, one way to protect it on a website is by having an SSL certificate.

SSL is the acronym for Secure Sockets Layer. It is the standard security technology for establishing an encrypted link between a web server and a browser. SSL certificates help protect the integrity of the data in transit between the host (web server or firewall) and the client (web browser).

What Are the Risks?

According to OWASP, here are a few examples of what can happen when sensitive data is exposed:

Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text.

Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, 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. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

Why is Sensitive Data Exposure so Common?

Over the last few years, sensitive data exposure has been one of the most common attacks around the world. Some examples of data leaks that ended up in exposing sensitive data are:

• The Brazilian C&A retail fashion retail clothing chain gift card platform cyberattack that happened in August 2018.
• The Uber breach in 2016 that exposed the personal information of 57 million Uber users, as well as 600,000 drivers.
• The Target store data breach that occurred around Thanksgiving exposing credit/debit card information and contact information of up to 110 million people.

Not encrypting sensitive data is the main reason why these attacks are still so widespread. Even encrypted data can be broken due to weak:

• key generation process;
• key management process;
• algorithm usage;
• protocol usage;
• cipher usage;
• password hashing storage techniques.

How to Prevent Data Exposure

Some of the ways to prevent data exposure, according to OWASP are:

• Classify data processed, stored, or transmitted by an application.
• Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
• Apply controls as per the classification.
• Don’t store sensitive data unnecessarily.
• Discard it 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.
• Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
• Verify independently the effectiveness of configuration and settings.

4. XML External Entities (XXE)

According to Wikipedia,

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.

Most XML parsers are vulnerable to XXE attacks by default. That is why the responsibility of ensuring the application does not have this vulnerability lays mainly on the developer.

What are the Attack Vectors?

According to OWASP, the XML external entities (XXE) main attack vectors are:

• exploitation of vulnerable XML processors if malicious actors can upload XML or
• include hostile content in an XML document;
• exploitation of vulnerable code;
• exploitation of vulnerable dependencies;
• exploitation of vulnerable integrations.

Example of an XML External Entity Attack

Here is an example of an XXE Vulnerability

A security flaw or weakness found in software or in an operating system (OS) that can lead to security concerns.

" aria-describedby="tt" style="box-sizing: inherit; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-style: normal; font-variant-caps: normal; font-weight: normal; text-size-adjust: auto;">vulnerability that sends content in a POST request to the application.[code]

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

<Prod>

<Prod>

<Type>abc</type>

<name>Bugcrowd</name>

<id>21</id>

</Prod>

</Prod>

[/code]

How to Prevent XML External Entity Attacks

Some of the ways to prevent XML External Entity attacks, according to OWASP are:

• Whenever possible, use less complex data formats such as JSON, and avoid serialization of sensitive data.
• Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system.
• Use dependency checkers (update SOAP to SOAP 1.2 or higher).
• Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
• Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
• Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
• SAST tools can help detect XXE in source code – although manual code review is the best alternative in large, complex applications with many integrations.

If these controls are not possible, consider using:

• virtual patching,
• API security gateways,
• Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks.