OWASP Top 10 Web Application Security Risks

The OWASP Top 10 is a global standard of the most important security risks to today's web applications. For any developer or software company, security is paramount to maintain customer trust, your product's reputation, and your own professional integrity. Customers all over the world are ready to entrust you with credit cards, addresses, emails—all kinds of sensitive data. This article should serve as a kind of cheat-sheet reference tool for those wanting to review the security of their applications.

1. Injection attacks

This is (still!) the number one threat to digital products. If you simply take a user's input and plug it into an SQL query like this:

email = getRequestString("email");
query = "SELECT * FROM users WHERE email = " + email;

Then a user can potentially break into your database by entering the email: "asdf@sdf.com OR 1=1". That injected OR statement means the WHERE clause is always true, and every user in the database will be returned by the query.

Prevent these attacks by sanitizing your user input, and escaping any code characters.

2. Broken Authentication

Have you ever tried "Username: admin; Password: admin" on a website? Perhaps on a router? Default credentials, or common passwords such as "password", "qwerty", and "111111" make your site's security very weak. A bot can quickly run through a dictionary of most common passwords and breach your security—if you let it.

The first step against this, of course, is not to have any "admin admin" type credentials yourself. The second step is to encourage users to choose better passwords. I am personally a big fan of multiple-word passwords instead of requiring 1 symbol, 1 capital, etc etc. (relevant XKCD below)

On top of better passwords, you can also set limits to how often a device can attempt to sign in. A human with the worst memory does not need 5000 attempts per second, but a brute force attack would certainly welcome that flaw in your application.

3. Sensitive Data Exposure

HTTP calls sending clear text, the intern storing envvars in your git repo, or my personal favorite: putting all email addresses in a mass-email in the "CC" field, so that every recipient can see everyone else's information. There are many ways to expose your data. The key principle here is "don't show anything more than you need to".

This can include matters of encryption. Are you storing credit cards or passwords in plain text on your database? That means you are one injection attack away from a lot of angry customers. "Why would anyone be that naive??" You might be saying. Well, I've seen it, it happens. That's why this security risk is #3.

4. XML External Entities (XXE)

Poorly configured XML processors can evaluate external entity references within XML documents. A good example of this is the "Billion Laughs" attack. You can define a simple document like this:

<!DOCTYPE TEST [
 <!ELEMENT TEST ANY>
 <!ENTITY LOL “LOL”>
 <!ENTITY LOL1 “&LOL;&LOL;&LOL;&LOL;&LOL;&LOL;&LOL;&LOL;&LOL;&LOL;”>
 <!ENTITY LOL2 “&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;&LOL1;”>
 <!ENTITY LOL3 “&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;&LOL2;”>
 <!ENTITY LOL4 “&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;&LOL3;”>
 <!ENTITY LOL5 “&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;&LOL4;”>
 <!ENTITY LOL6 “&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;&LOL5;”>
 <!ENTITY LOL7 “&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;&LOL6;”>
 <!ENTITY LOL8 “&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;&LOL7;”>
 <!ENTITY LOL9 “&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;”>
]>

<TEST>&LOL9;</TEST>

An XML processor trying to evaluate this will get stuck trying to resolve the ~3Gb document that it generates with all the (3*10^9) references. This becomes a DoS (Denial of Service) attack.

The main security fix for this is to update all your XML processing tools (or better yet, move on to more modern data formats). Another way is to whitelist expected XML fields.

5. Broken Access Control

Scenario: A user sees a request for his information being sent like this:

myapp.com/user?id=123

On a whim, he tries another id:

myapp.com/user?id=124

If this second call returns user 124's data, then you have a big breach in security.

How do you prevent this? Most modern applications use a login session to verify the user logged in. Beyond that, you need to check at each request whether the logged in user has access to the record they are asking for.

The main thing here is whether you have every case covered. And this comes down to having a proper test suite. If each of your controller actions is tested for all kinds of contexts, then no broken access should exist.

6. Security Misconfiguration

This is any misconfiguration (or unchanged default configuration) of your tools. Perhaps when you first set up your database there is an "admin admin" user that you forgot to remove. Or perhaps any error gives a full stack-trace to the user (including any sensitive information along the way). It can be as simple as having out of date libraries with known vulnerabilities.

To prevent this, you need to know the tools you are working with. Keep things update to date, and it may also be healthy to schedule a regular time to review the configuration of your application.

7. Cross-Site Scripting XSS

Client-side code injection. An example of an XSS attack is a site that executes code injected into a url, like this:

https://my-site.com/search?message=<script>/* send all my information to a 3rd party */</script>

These can then be shortened by a service like tinyurl, and presented on social media as "Hey, click this link! tinyurl.com/1234", which redirects to a site (where the user is automatically logged in from previous browser sessions) and runs the XSS script.

To prevent XSS attacks, you need to separate untrusted data from active browser content. This means escaping any user input, and ideally using frameworks that are XSS safe by default (such as Ruby on Rails, React, etc),

8. Insecure Deserialization

This issue follows the common thread throughout this list—a site not validating untrusted (user given) data. If serialized data is sent to a server, there is always a chance that the user was able to altar that data in a way that deserializes into something malignant.

One way to prevent this attack is to simply not accept serialized data from a source you don't trust. If that's not possible, then use serialization tools that only allow primitive data types (this will stop code injections, but not value-swapping).

9. Using Components with Known Vulnerabilities

Exploiting a known vulnerability is as simple as googling "known vulnerability for X". Moreover, some vulnerabilities can be tested by an automated tool crawling through the web—no human needed. This is why it's important to always update your libraries, tools, gems—any 3rd party software your application depends on. Those pieces of code will have bugs and flaws just like your own projects. By keeping up to date, you get all the latest fixes.

10. Insufficient Logging & Monitoring

Yes, this is a security flaw! Many times a breach is detected as late as 200 days after it occurred. Many times that breach is detected by a third party, and not by the owner/developer of the site itself. This happens because malicious users and software use your application however they like, and you have no idea what they are doing.

This problem can be fixed by:

• Logging login and access control failures and server-side input validation failures.
• Making the logs easy to consume (by tools or humans), and actually consuming them (plenty of monitoring software out there).
• Setting up an alert system so that suspicious activity is responded to in real time.
• Having an incident response plan, so you can react appropriately to any attack as soon as you become aware of it (hopefully not 200 days after it happened!).

Conclusion

So there you have it—the top ten security flaws for web applications, and how to prevent them. A good practice for your organization is to set up a regular security audit, where developers take this list and review how their code lines up to each of these points.

Stay safe.