OWASP Top 10 Overview

OWASP is a very cool community dedicated to helping organizations build software that can be trusted. It came online in 2001 and was established as a non-profit in April of 2004.

Its core purpose is to be the thriving global community that drives visibility and evolution in the safety and security of the world's software. And its core values are to be open, innovative, global, and to have integrity.

There have been several iterations of the OWASP Top 10 since 2003. You can think of the Top 10 as basically a list of how not to get hacked. The official document provides information about determining your vulnerability, prevention strategies, examples, and testing strategies.

Caroline Wong (@CarolineWMWong) first learned about the OWASP Top 10 years ago while she worked at ebay, where she launched her infosec career. These days, she's Chief Strategy Officer for Cobalt.io and teaches the subject on LinekdIn Learning. You can learn in much more detail about the OWASP Top 10 through her courses there.

To teach this subject matter, Caroline makes use of memorable analogies, which is what the rest of the talk will cover.

#1 Injection

Injection, loosely speaking, involves tricking systems into interpreting untrusted data as trusted commands (e.g. SQL injection)

To understand this, think of a file cabinet, and a robot that you tell to fetch files. "Robot, give me all files from 2019." With an injection attack, the attacker alters the instructions to the robot to "give me the files from 2019… and also all of the other files."

#2 Broken Authentication

Broken authentication happens when functions related to authentication are implemented incorrectly and can be exploited.

As an analogy, think of a Hide-A-Key that looks like a rock. Except, you don't actually hide the key very well at all. And then, a burglar just stumbles across the Hide-A-Key left, say, on your door mat, extracts the key, and uses it.

#3 Sensitive Data Exposure

In this scenario, sensitive data, such as PII, lacks adequate protection within a system.

Think of baby gates. With a baby gate, you limit the area to which the baby has access, allowing you to baby-proof a smaller area of the house. With sensitive data, put it somewhere special, and implement lots of security there.

#4 XXE (XML External Entities)

This is a category that has to do with over-extending trust, like category 1. In this case, the system puts too much trust in the information in an XML resource.

There is XXE attack called "billion laughs," also known as an XML bomb. In this scenario, an attacker submits a small, harmless string, but it begins to expand into many more such strings, which do the same until the system experiences a denial of service.

#5 Broken Access Control

This happens when restrictions on what users are allowed to do are not properly enforced.

Imagine that you're at the airport and you present your boarding pass and ID to the gate agent. This person then authenticates you and allows you into the boarding area, which ultimately grants you access on the plane to your seat. You're not allowed to, say, wander into the cockpit, unless access control is broken.

#6 Security Misconfiguration

Security misconfiguration happens when you have manual, ad hoc, or incorrectly configured controls.

Many applications come insecure out of the box. For instance, imagine your phone. You have to go in and setup a passcode, fingerprint, or facial recognition. Without that, you have a de facto misconfiguration.

#7 Cross Site Scripting (XSS)

Cross site scripting allows attackers to execute scripts in the user's browser. It's another scenario where trusting data you shouldn't can cause issues.

For instance, Caroline's daughter attends a pre-school where some children have severe food allergies. Parents can't send children to school with food. This effectively represents XSS-prevention, in that a parent can't create an issue for another child via their own child's lunch.

#8 Insecure Deserialization

This happens when an application receives hostile serialized objects and doesn't properly guard against them.

To understand insecure deserialization, imagine someone messing with a puzzle in the box. They're swapping out pieces, breaking them, and otherwise tampering. When another person then attempts to do the puzzle, it has been vandalized.

#9 Components with Known Vulnerabilities

This occurs when libraries and components run with the same trust-level as the application, and have known issues of their own.

Consider product recalls. The NHTSA allows you to search for all kinds of different recalls in automobiles. And, just as you'd want to keep yourself apprised of safety issues in things such as your car, you should do the same with your software.

#10 Insufficient Logging and Monitoring

Most security breaches are not discovered by the organization that has been breached, but rather by its users. Insufficient logging and monitoring means that the organization is not taking enough steps to become aware of breaches.

For a final analogy, think of this screenshot from Toy Story 3.

While logging is important, logging without monitoring is useless. To make an escape, the characters disable the monitoring monkey's ability to notify anyone about what's happening. So the escape is logged, but the alert mechanism (the monkey) doesn't work, meaning there is effectively no monitoring.

This is the OWASP Top 10...as they stand today. Expect this list to change.

This post was written by Erik Dietrich. Erik is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. This breadth of experience has allowed him to speak to all industry personas and to write several books and countless blog posts on dozens of sites.

Photo by Magda Ehlers