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 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.
Since 2003, there have been several iterations of the OWASP Top 10. 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 working at eBay, where she launched her infosec career. These days, she's Chief Strategy Officer for Cobalt.io and teaches the subject on LinkedIn Learning. You can learn more about the OWASP Top 10 through her courses there.
To teach this subject matter, Caroline uses 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 occurs when functions related to authentication are incorrectly implemented and exploited.
As an analogy, think of a Hide-A-Key that looks like a rock. Except, you don't actually hide the key 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 an 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 you're at the airport and 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 to your seat on the plane. You're not allowed to, say, wander into the cockpit, unless access control is broken.
#6 - Security Misconfiguration
Security misconfiguration occurs 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 set up 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 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 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
The organization does not discover most security breaches that has been breached, but rather by its users. Insufficient logging and monitoring means the organization is not taking enough steps to become aware of breaches.
While logging is important, logging without monitoring is useless. Caroline talked about the monkey monitoring the screens in Toy Story 3. 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.
Erik Dietrich 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 ...
Tags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.