Open Web Application Security Project – OWASP Top 10 Vulnerabilities

What is the OWASP Top 10?

Humans like lists. Say this to someone at Buzzfeed, and they would probably look at you like you just stated that water is wet. Lists have the valuable quality of distilling complex, and sometimes varied, information into an easily digestible format.

These qualities are especially valuable in topics like information security, where the field of knowledge is too broad for a single human to have a complete grasp of. To this end, the Open Web Application Security Project (OWASP) has published a list of their top ten web application vulnerabilities every few years (starting in 2003) with the most recent release occurring in 2017. As OWASP’s name would suggest, the list focuses on 10 web application vulnerabilities judged by OWASP and the security community at large to be significant enough to earn a spot on the current list.

Honestly, you’ll probably already have at least passing familiarity with the list if you’ve spent any time researching web application security, so let’s jump right into:

What Are the OWASP Top 10 Vulnerabilities for 2017?

The 2017 OWASP Top 10 list is:

– A1 Injection

– A2 Broken Authentication

– A3 Sensitive Data Exposure

– A4 XML External Entities (XEE)

– A5 Broken Access Control

– A6 Security Misconfiguration

– A7 Cross-Site Scripting (XSS)

– A8 Insecure Deserialization

– A9 Using Components with Known Vulnerabilities

– A10 Insufficient Logging & Monitoring

If you’ve looked at the Top 10 from previous years, you’ll see some familiar faces in this list, along with some new categories. We’ll get into the changes in a later section, but first I wanted to touch on each of the current categories.

A1: Injection: At this point, injection is synonymous with “A1”. It was first placed at the top of the list in 2010 and has stayed there since. While SQL Injection (SQLi) is the most well known form of injection attack (see the XKCD comic referencing SQLi), it goes well beyond just forgetting about Little Bobby Tables. Anytime untrusted input is being used as an execution parameter, injection is a concern.

A2: Broken Authentication: Authentication is a broad topic, and so there are numerous ways in which it can be broken. This category covers a range of issues, including Credential Stuffing, Insecure Password Reset, Session Management issues, and Insufficient Password Complexity.

A3: Sensitive Data Exposure: Data handling can be boiled down pretty simply, what data do you have, what data do you need, how sensitive is it, and how do you protect it? User passwords are one example of sensitive data. To protect this sensitive data, the actual value of a user password should not need to be stored. Rather, only the string resulting from a properly salted and hashed password needs to be kept to perform authentication. Also, does an application need to collect the last 4 digits of a user’s Social Security Number? If not, then it really shouldn’t. An attacker can’t steal data that doesn’t exist.

Additionally, this category covers data in transit. All too often, applications don’t implement transport security, which leaves data vulnerable to man-in-the-middle attacks. At this point, Transport Layer Security (TLS) implementations are easy and cheap, especially with the help of groups like Let’s Encrypt. So in my opinion, every site should use HTTPS.

A4: XML External Entities (XEE): XML parsers generally allow loading of external entities, such as a file or network location. While this is normally not as issue as most modern XML processors disable this by default, many older processors are configured to allow external entities out of the box. In this situation, an attacker can upload malicious XML to the application in an attempt to steal data, perform denial of service attacks, or map out the application and its environment.

A5: Broken Access Control: The second “auth”, authorization, is just as broad a topic as authentication. Due to this, the Broken Access Control category covers a range of vulnerabilities, all centered around a user having access to data and application functionality that the developers did not intend.

A6: Security Misconfiguration: This one’s pretty straight forward. Anytime an insecure default setting goes ignored or a service or application is configured without security in mind, then Security Misconfiguration is a risk. Does a server return stack traces or other detailed error messages to the client? Perhaps it’s vulnerable to Web Cache Deception? Maybe the default administrator account is still enabled. All of these issues are examples of Security Misconfiguration.

A7: Cross-Site Scripting (XSS): Cross-Site Scripting, like Injection, has been on the top 10 for ages. Similar to Injection, this problem occurs when an application does not properly handle untrusted input. In this case, the untrusted input is rendered in a user’s browser. The two most common “flavors” of XSS are Persisted and Reflected, with the category being dependent on where the data comes from. A short, general rule for this is: does the data come from the application’s data layer (e.g. database)? Then it’s persisted. If the data comes from the request (e.g. a URL query string parameter), then it’s reflected.

A8: Insecure Deserialization: Here we have our final “attack” category. Deserialization is a process where structured data (e.g. JSON), is taken and turned into an object. Insecure Deserialization takes advantage of applications that use weak deserialization methods to perform this state change. During this process, it is possible that data will be interpreted as code, or at the very least, in a way that an attacker can take advantage of. Use of native language serialization formats are often to blame for this issue.

A9: Using Components with Known Vulnerabilities: This category says it all in the title. Using 3rd party code is a necessary part of modern development. However, just like in any in-house code, vulnerabilities can pop up in externally-sourced code. Ideally, any discovered problems could be fixed with a patch, but that’s not always the case. Sometimes vulnerable components are buried and forgotten by development teams (you can’t patch what you don’t know about). Other times, these components are no longer supported by their original developers, and then the only solution is to replace the component or build some other work-around.

A10: Insufficient Logging & Monitoring: Logging and monitoring is incredibly important to any holistic security plan. Unfortunately this is often overlooked, hence its place on the OWASP Top 10. Proper logging and monitoring provides developers and security teams with valuable data to improve possible weak points in their application or infrastructure. However, the benefits don’t stop there. In the event of a breach, this data can assist with quicker response times, allowing quicker identification how the breach occurred and general reduction of impact.

Notable Changes in OWASP Top 10 from 2013 to 2017

So what’s changed from the previous list? Early versions of the 2017 list were met with a ton of discussion (even within our company’s chat rooms). Over the course of 2017, the list was refined until it became what we have today. In a lot of ways, 2017’s list looks like the 2013 list, but it also makes some general improvements and modernizations.

For simplicity’s sake, I’m going to break this down by each entry, comparing each rank from 2013 with 2017’s. OWASP has a visual representation of this in the PDF itself, which I’ve also included off to the side.

  • A1:
    • As I hinted at earlier, Injection retains its top spot from 2013
  • A2:
    • Broken Authentication and Session Management remains in the second spot. However, its name has been shortened in 2017 to simply “Broken Authentication”.
  • A3:
    • Now we get to some substantive changes. Previously, Cross-Site Scripting (XSS) occupied A3. As of 2017, it is now Sensitive Data Exposure, which moves up from its previous spot of A6.
  • A4:
    • This spot is now occupied by XML External Entities (XXE). The previous entry, Insecure Direct Object References, was combined with 2013’s A7 to become 2017’s A5 Broken Access Control.
  • A5:
    • As mentioned just before, 2013’s A4 (Insecure Direct Object References) has joined with 2013’s A7 (Missing Function Level Access Control) to become 2017’s Broken Access Control. In 2013, the A5 spot went to Security Misconfiguration.
  • A6:
    • Previously at A5, Security Misconfiguration has been pushed to A6. As mentioned in A3, Sensitive Data Exposure occupied this spot in 2013.
  • A7:
    • As of 2017, this spot goes to Cross-Site Scripting (XSS). The now merged Missing Function Level Access Control was here previously.
  • A8:
    • A newbie, Insecure Deserialization, has settled here. Prior to 2017, Cross-Site Request Forgery (CSRF) sat here. I have a professed love of CSRF, so I’m sad to see it drop off the list, even if it’s the right choice to make.
  • A9:
    • Like A1, Using Components with Known Vulnerabilities is unmoved.
  • A10:
    • Unvalidated Redirects and Forwards is the second and final removal. It has been replaced by the new A10, Insufficient Logging & Monitoring.

Summary

I always try and close out any discussions on the OWASP Top 10 with an explicit reminder that the list does not cover every web application security vulnerability. An issue being removed from the list does not mean that it is not a problem (CSRF is still an issue in many web applications). Likewise, an issue being downgraded does not mean that it is a lower priority. The OWASP Top 10 is a fantastic baseline, a strong foundation upon which to build an application security plan with considerations for the needs of the application and the organization. Security is a hard and sometimes messy topic, and while what I’ve stated here is probably obvious to every security professional, it may not be as obvious to those who don’t spend all day trying to break applications.

One final note before I leave, OWASP is a non-profit and is always looking for volunteer assistance for its various projects, including the Top 10. You can find their website here if you want to check out the other resources they have, or are curious about helping out.

References:

  1. “OWASP Top Ten Project” https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
  2. “OWASP Top 10 – 2017” https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
  3. “OWASP Top 10 -2013” https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf

 

 

About The Author

Steve Kosten

No Comments

Leave a Reply