Learn about the 2017 OWASP Top 10: the top ten most critical security risks to web applications.

2017 OWASP Top 10

A hacker stares at a textbox on their screen, finger hovering over the <kbd>enter</kbd> key. In the input box is a malicious query. They hit the <kbd>enter</kbd> key, and the website freezes for a moment before displaying the credentials of every administrator account. The website’s owner is about to have a very bad day.

*Injection* is when an attacker injects malicious code into an interpreter in order to gain access to information or damage a system. This is often accomplished by inserting malicious characters into an input field on the website, and this malicious input is then sent to the interpreter. Sometimes, this will cause the interpreter to crash, but it can, in the worst case, cause the interpreter to start running code supplied by the attacker.

Interpreters for query languages such as SQL are a common target, but not the only one. In some cases, Injection attacks can even target the operating system the webserver is running, passing data that is executed as a terminal command.

Here is an example of normal Java code that searches for a product by name:
```java
query = "SELECT product_name, product_cost FROM
product_table WHERE product_name = " + USER_INPUT + "'";
```
Here is a malicious query that searches for the product "soap" while attaching a `UNION` command to steal usernames and passwords:
```
soap' UNION SELECT username,password,NULL FROM user_table;-- -
```
Here is what the code interpreter sees when the malicious query is added:
```sql
SELECT product_name, product_cost FROM
product_table WHERE product_name = 'soap' UNION SELECT username,password,NULL FROM user_table;-- -';
```

Injection attacks are usually mitigated by sanitizing and validating all user input as well as writing code so that the interpreter can’t get confused about what is and isn’t data.

Injection

When it comes to vulnerabilities, the unknown is scary, but sometimes it’s the known you have to worry about. If an attacker wants to attack you with a new vulnerability, the attacker first has to discover this new vulnerability and then figure out how to exploit it. With known vulnerabilities, it could be as simple as the attacker pressing <kbd>enter</kbd>.

_Using Components with Known Vulnerabilities_ means using software or package versions that are known to be vulnerable. Vulnerabilities are common in software, but they usually get patched as new updates are released. However, older versions of the software remain vulnerable!

The [Common Vulnerabilities and Exposures system](https://cve.mitre.org/) has detailed records of publicly-known vulnerabilities that have been exploited. This is usually used to help people protect themselves and patch these vulnerabilities, but this knowledge can also be used by malicious actors. There are even tools to do this research automatically, and these tools can determine what software a server is running and suggest exploit kits that could attack it.

Usually, this can be prevented by keeping software such as operating systems, hosts, database software, etc up to date. If a piece of software is abandoned, it’s time to find a new, actively-maintained replacement.

An image showing an unstable tower with blocks labeled "Deprecated Package", "2 Years Out of Date", WONTFIX", and "Missing Security Packages" trying to hold up a block labeled "Overall Security". An engineer on the side is saying "It'll be fineee..." with a thumbs up. 

Using Components with Known Vulnerabilities

Computers take things very literally; give them an instruction and they’ll follow it exactly, even when it’s not actually what you wanted. Servers are computers that have been instructed to respond to requests for data, and if you’re not careful, they’ll respond to requests like “details of every account on the OS the server is running” or “what happens if you run this piece of code?”.

Similar to Injection, _XML External Entities (XXE)_ is a type of vulnerability that allows maliciously crafted data to produce unintended behavior on the backend of a website. 

Unlike injection, where the malicious input is usually from an input field, XXE involves an attacker uploading a maliciously crafted XML file. XML is a markup language that supports potentially insecure features, and if a website is using an XML processor with those features enabled, an attacker can use XXE to wreak havoc. In the worst case, the attacker may be able to execute arbitrary code - just about the worst case scenario for security.

While XXE can be mitigated by ensuring XML processors are properly configured and updated, and that input is validated before processing, the simplest solution is to not use XML.


A snippet from an XML file that attempts to exploit XXE vulnerabilities. Two parts of the file are highlighted. The first part, which says "<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>", defines an entity pointing to the etc password file, and the second part, which specifies "&xxe;" as the methodName, calls that reference.

XML External Entities (XXE)

An image that shows a building with a broken Firewall Fencing, a sticky note showing that "1234" is the code for the safe, and sleeping dog protecting the building.

All the security software in the world won’t protect you if it isn’t properly configured. When the attacker started trying injection attacks, the alarms remained silent. When the attacker opened a backdoor to the server, the firewall didn’t block it. And when the attacker started stealing credit card data, the endpoint security software sent warning after warning, but it all went unseen until the following Monday.

_Security Misconfiguration_ has been a problem since the early days of the internet, and it continues to be a problem today. Whether due to operator error or insecure default settings, insecure configurations can severely hamper the security of an environment.

Examples of Security Misconfiguration include things like:
- Forgetting to protect cloud storage
- Leaving unnecessary features enabled on server software
- Disabling automatic updates
- Displaying overly detailed error messages that give details about the way the backend is set up

It also includes improperly configured security software, such as weak or ineffective rules for Firewalls and Intrusion Detection Systems (IDSs).

Preventing security misconfiguration requires regular review of configurations. It’s not possible to simply "set and forget" software. As the environment continues to grow and change, security and hardening needs to be treated as a continuous, ongoing processes.


Security Misconfiguration

In security, knowledge is power. Knowing what’s going on within a system is important for detecting, preventing, and responding to attacks. Early detection can mean the difference between an incident that causes an internal memo, and an incident that makes headlines for weeks.

_Insufficient Logging and Monitoring_ refers to an overall lack of tools that monitor, record, and report events within a system. Events include logins and login attempts, webpage requests, and more. Having these logs allows monitoring software to scan for suspicious behavior, such as 1000 login attempts in 5 seconds or connections to or from known malicious IP addresses.

When logging and monitoring is insufficient, it’s more difficult to investigate attacks. Insufficient logging and monitoring also gives attackers more time to do damage before they are detected, meaning that attacks can be more severe as well.

Logs should be easy to read, and they should record sufficient information and context about auditable events. Monitoring tools should be properly configured and able to respond in real-time to suspicious behavior.


Insufficient Logging and Monitoring

When data breaches happen, that’s not the end of the story. The stolen information gets sold and resold on the dark web, often ending up in sets of personal information known as _fullz_. Fullz contain information someone could use to commit the kinds of fraud that can ruin a victim’s life for years, and most of this information is on sale for $25 or less.

Most websites handle sensitive data of some sort, and _Sensitive Data Exposure_ refers to insufficient protections being put in place for that data. This is a broad category of vulnerabilities that covers things like insecure storage, the transmission of sensitive data, or revealing sensitive data to unauthorized parties. This type of vulnerability can have serious, life-altering consequences for the people whose data is exposed. 

As a broad category, there isn’t a single technique for preventing sensitive data exposure. Data privacy laws and regulations often provide a good place to start, but organizations that handle sensitive data have a responsibility to be proactive about securing the sensitive data they handle.


A webpage showing that a the username and password are shown in plaintext in the URL of the webpage, making it easy for an attacker to hack into someone's profile by just changing the url.

Sensitive Data Exposure

We know not to trust user input, but the website doesn’t necessarily know not to trust user input. The webpages themselves were made securely, but none of the engineers ever bothered to ask “Isn’t the URL user input too?”. The attacker is now changing the URL in order to grab the personal information of every profile on the website; just because there weren’t links to other user’s profiles on the homepage didn’t mean the attacker can’t request profiles by changing the URL.

_Broken Access Control_ is when authorization is improperly enforced, allowing users access to privileges they should not have. This category is more about vulnerabilities within the authorization system than it is about bypassing the system entirely.  Because broken access control is such a broad category of vulnerabilities, it can have a wide range of consequences. Access to sensitive user data is one fairly common result, but the sky’s the limit.

Broken access control has no single method of mitigation. Mitigation can involve things like rate limits for logins, ensuring server-side validation of requests, and implementing default-deny for permissions.


Broken Access Control

In summary, the OWASP Top Ten consists of:
* Injection: An attacker "injects" malicious code into an interpreter, usually through an input field, in order to gain access to information or damage a system
* Broken Authentication: An insecure authentication system allows attackers to impersonate other users.
* Sensitive Data Exposure: Sensitive data is improperly or insufficiently protected.
* XML External Entities (XXE): Malicious XML causes an insecure XML processor to access data or execute code that it shouldn’t.
* Broken Access Control: Authorization isn’t properly enforced, allowing attackers to access resources beyond their authorization.
* Security Misconfiguration: Insecure, improper, or a lack of security configurations degrade the security of an environment.
* Cross-Site Scripting (XSS): Malicious input is treated as javascript that can run on victims’ browsers.
* Insecure Deserialization: Data from an untrusted source is deserialized into an object, potentially containing malicious code or data, within a program.
* Using Components with Known Vulnerabilities: Vulnerable components, such as out-of-date packages or software, are included within an environment, allowing attackers to use existing exploits to attack.
* Insufficient Logging and Monitoring: Lack of detailed monitoring makes it easier for attackers to stay undetected, and it makes it harder to respond after an attack has occurred.


An image styled after an Old West Wanted poster that has the OWASP Top Ten crossed out with thick slashes. It says "Wanted, in connection with multiple cyberattacks: Injection, Broken Authentication, Sensitive Data Exposure, XML External Entities (XXE), Broken Access Control, Security Misconfigurations, Cross-Site Scripting (XSS), Insecure Deserialization, Using Components with Known Vulnerabilities, Insufficient Logging and Monitoring. Reward."

Review

The owners of the website made an effort to secure it, but security is only as strong as its weakest link. In this case, the weakest link was a "temporary" admin account that was created for use only while the website was being built and has since been forgotten... By everyone except the hacker who had just logged in using `admin` as the username and password.

_Broken Authentication_ is a broad term for vulnerabilities that allow attackers to impersonate other users. Vulnerabilities like insecure default credentials, lack of rate limiting for login attempts, and session hijacking all fall into this category. In the worst case, a malicious hacker would be able to gain access to an administrative account, and all the authorization that accompanies it.

There is no single cure for broken authentication; web developers and security teams need to be diligent in making sure that they follow the best practices for the technologies they’re using.


Broken Authentication

When a malicious hacker found a cross-site scripting vulnerability in a popular social media platform, they couldn’t pass up the opportunity: They crafted a self-sharing post that would rapidly spread and install malware on anyone's device who viewed it; a rather dark twist on the concept of “going viral”.

*Cross-Site Scripting (XSS)* is a web vulnerability that targets the browser-side of the website, rather than the server-side. XSS happens when a browser is tricked into running malicious javascript. It usually happens when a website allows user input without sanitizing and unarming dangerous input. If this happens, an attacker can pass input to the website that a victim’s browser will run as javascript.

XSS can be a severe vulnerability, particularly when the malicious input is stored by the website and displayed to many users. XSS has a wide range of uses, from defacing websites to bypassing authentication to stealing passwords.

Preventing XSS involves making sure that special characters like `<`, `>`, `"`, `=`, and more are properly escaped to prevent a browser from parsing them as code rather than regular text.


Cross-Site Scripting (XSS)

If there’s only one thing you take away from this lesson, let it be “Don’t trust user input”. Especially if that user input will interact directly with your server.

Serialization is the process of turning an object within a program into formatted data. Deserialization is the process of turning formatted data into an object within code. _Insecure Deserialization_ is when this process can be exploited to cause unintended behavior. 

If an attacker is able to modify the data that is going to be deserialized, they can change the resulting object, modifying data or adding malicious behaviors. In the worst case, this can allow for arbitrary code execution.

There are a few different ways to prevent insecure deserialization, but the easiest and most reliable way is to just not deserialize external data.


An image showing that, during deserialization, an object is serialized into a byte stream, then deserialized into an object. During insecure deserialization, an attacker can modify the byte stream so that the deserialized object can be modified to have malicious commands.

Insecure Deserialization

An image styled after an Old West Wanted poster that lists the OWASP Top Ten. It says "Wanted, in connection with multiple cyberattacks: Injection, Broken Authentication, Sensitive Data Exposure, XML External Entities (XXE), Broken Access Control, Security Misconfigurations, Cross-Site Scripting (XSS), Insecure Deserialization, Using Components with Known Vulnerabilities, Insufficient Logging and Monitoring. Reward."

The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) is a project maintained by the Open Web Application Security Project (OWASP). OWASP is a respected authority in the field of web security, and the Top Ten is a collection of the ten most serious vulnerabilities for web applications. 

Many of these vulnerabilities have existed for a long time, yet still pose an active and serious threat; When a website gets compromised, the chances are good that at least one exploited vulnerability will be listed in the OWASP Top Ten.

With that in mind, let’s go on a tour of vulnerabilities that are in the OWASP Top Ten.
