OWASP Top 10 Deep Dive
NOTE: This is a living document that I am constantly going to be changing and adding to. If you happen upon it during one of the times I am currently updating it, and see references to links that are not posted yet, do not fret, it means I am currently in the process of loading them as you read this! Happy Hacking!
Today we are going to do a deep dive, where we take a subject and really dig into it and hopefully come away with a much deeper understanding then when we started. This particular deep dive is going to be on the OWASP list of Top 10 vulnerabilities. I am assuming if you are reading this blog you are familiar, but if not the quick run down is this. OWASP (Open Web Application Security Project) is a world wide non-profit organization focused on improving the security of software. Founded in 2001, they have been curating a list of the top software vulnerabilities since 2003, which has become the industry standard. You can learn more about them and everything they do Here
Before we go deep into each of the items on the list, here is a visual representation and general overview as well as a link to the OWASP Top 10 PDF.
Alright lets get into it!
10. Unvalidated Redirects and Forwards
Most notably used in phishing scams, this is where an attacker can take a valid site (www.trustedsite.com) and craft a URL that redirects someone to a different, malicious site (www.trustedsite.com/redirect.jsp?fwd=evil.com). Perhaps the malicious site looks identical to something like a login page, but is being run by the attacker to steal your login credentials. Although this is lowest on the list of vulnerabilities it is still very serious and can lead to much more then just the theft of users credentials.
Depending on the stack and its implementation, an attacker can use unvalidated redirects to access things like admin functionality as well. Think of something like this, www.trustedsite.com/whatever.jsp?fwd=admin.jsp. If there is no validation happening this could potentially allow an attacker access to privileged functionality. Below are some links to language specific examples of redirects as well as proper ways to avoid them when crafting your software.
IMB Video Explanation and Examples
Extensive Slide Presentation by: Shane Stanley of Southern Polytechnic
Hacking Tips: There are various tools that can be used to try and quickly detect unvalidated redirects. First you will need to know at least some of the basic logic flow and can then start playing around with simple examples and see what you get. Resources and further information have been listed below.
9. Using Components with Known Vulnerabilities
This is an extremely broad and wide ranging vulnerability. Almost every single piece of software built today includes multiple different third party libraries and components. In my experience building web apps we used TONS. There are package managers that make the process of including third party functionality trivial and even though strange things like the left-pad fiasco have come along and broken tons of peoples software, people still use this system and will continue doing so for the foreseeable future. In fact, its on the rise, so as a developer you always need to be researching and making sure you aware of all the security risks and factors involved with every piece of third party code you introduce into your development environment.
Component vulnerabilities can lead to almost every type of risk imaginable. Components almost always run with full privilege to the rest of the application and are more and more playing an instrumental part on some of the most important aspects of securing an application, for example, session management or authentication. Imagine if whatever library you decided to use for session management/authentication ended up having an exploit? Not good.
Although there is no one-stop-shop for searching known vulnerabilities in third party software, CVE and NVD are both making strides to change this (links below). Because this type of vulnerability is so broad and vague the solution isn't as cut and dry as some of the others on this list. At the end of the day you really need to make sure you know about all the third party code being used in your application and then also stay on top of the latest news and information involving those components. If you can, establish governing policies that your team can follow when it comes to using external components and when appropriate, use security wrappers, or reduce privilege to any third party component.
Great In-Depth Video on the Subject
Hacking Tips: Exploiting these flaws starts with good recon. The more you know about how the application is built, and what it is built with, the easier it is to find known vulnerabilities. Using tools like Maltego, which can be found on Kali Linux 2.0, are a great help in determining what the stack consists of. Also keeping on top of the latest info sec news is key. People are finding new exploits everyday.
8. Cross Site Request Forgery (CSRF)
This is one of the bigger ones with some serious ramifications. At first it may sound a bit confusing but the idea is really simple. An attacker making a request on your behalf without your knowledge or consent due to the fact that modern browsers retain users authentication for extended periods of time. Remember the last time you actually logged into Facebook? I sure don't. That is because most applications now-a-days want to be as user friendly as possible and don't want you to have to hassle with logging in every time you close the tab. So, if your browser has you currently authenticated to any site, someone else could trick you into making requests to that site.
Since the internet is primarily stateless and any action or change must occur via the submission of a HTTP method, attackers can forge these requests, hide them in a malicious link or on a malicious site and trick you into making these requests. Think submitting a comment to a blog, or clicking to load a photo. The type of request forgeries is boundless. At a low level think deleting an account. At a much more serious level think transferring money from a bank account! Since browsers are stupid and do not have the mechanisms to determine whether or not a request is malicious, CSRF is extremely easy to pull off when no measures are taken to mitigate it.
With that being said the solution is rather simple and elegant. The use of CSRF tokens can greatly reduce the risk of CSRF. These tokens should be unique and generated for every user and every request and should only be used once per request. This means an attacker cannot in theory guess or steal the tokens value and when they try and make those same fraudulent request, the server disallows it. The other, less elegant option, is to require users to reauthenticate for important and high risk requests.
Awesome Computerphile Video on CSRF
Hacking Tips: Begin by looking for obvious mitigation techniques such as a CSRF token. If you don’t see one of those, start mapping the application and gathering information as to exactly what, if any, techniques the application is using to prevent simple CSRF. Most modern browsers come with some prevention measures built in, but these can be bypassed. Check the resources below for more information.
7. Missing Function Level Access Control
Simply put, this vulnerability is all about whether or not regular users can access things they aren't supposed to, such as admin functionality. Admin functionality isn't the only functionality that needs to considered though. Many applications have other random functionality that regular users shouldn't have access to. An easy way to think about this is to imagine an authenticated user being able to change something like a URL parameter to gain access to something like the admin dashboard. The admin dashboard should only be able to be accessed by, well, an admin. If all it takes is some crafty URL manipulation, and the server doesn't validate exactly WHO is making the request, then you have a venerability.
Some basic questions you want to ask yourself are, does the UI show navigation to unauthorized functions? Are the server side authentication or authorization checks missing? If you do have server side checks, are they solely relying on information provided by the user? All of these things can and will lead to unauthorized access control. Once an attacker has gained a foothold and started gaining access to simple things like the admin dashboard, things can escalate quickly.
Mitigating this problem is fairly straight forward. Obviously you should never display links or buttons to what should be private functionality. Always make sure you have some sort of system in place to have the server validate the authorization of a request and only provide the appropriate information. Never hard code these types of functions on the client side code. Anyone can look at the client side code with todays browsers and will quickly and easily find and exploit this flaw. Also you should regularly and routinely check to make sure the steps you have put in place to safe guard access are working properly.
Real Examples from GitHub Bug Bounty Program
Burp Suite Tutorial on How to Test for Missing Access
Hacking Tips: The name of the game is trying to gain admin privileges. Forcing browsers to target specific URLs can be a great way to find these type of bugs. Mapping the application and making note of how the functionality works will give you insights and ideas as to ways you might start trying to mess around with access control. It will almost always require some guess work on the part of the hacker. Burp Suite can be used to speed up this process up. Check out the resources below.
6. Sensitive Data Exposure
The first thing you need to think about here is what exactly is your sensitive data? Passwords, account numbers, credit card numbers and personal information are some of the usual suspects here but, you should always make sure you are fully aware of any data that could potentially be viewed as sensitive. When it comes to the exposure of sensitive data, there are many different vectors of attack. The first is the transmission of data. If you have insufficient transport layer protection, an attacker can easily perform a man-in-the-middle attack and start picking off data. You should not only be using an encrypted channel but also encrypting the data itself.
This topic, like the last, can be very broad in scope. Transmission isn't the only time you should be thinking about sensitive data exposure. How you store data, how you log data and how you account for session management all play a pivotal role in making sure you are keeping all of your sensitive data secure. If you are storing information such as password or credit card information in clear plain text, you are at risk. You have to assume this not only an external threat but an internal one as well. Making sure you are using strong encryption is key here.
Always assume that your sensitive data can be stolen. With that in mind you want to make sure that if it does fall into the wrong hands, that is has been sufficiently encrypted using strong encryption and hashing algorithms. If you are dealing with cryptographic keys you need to make sure you are properly implementing them and using strong algorithms and rotation. Again, this can be a broad area to make sure you have covered but it is extremely important.
Great Blog About Encryption, Encoding, Hashing and Obfuscation
Khan Academy Cryptography Course
Hacking Tips: Data exposure can be a great link in a good exploit chain. Obviously, sometimes it means you have found a way to expose passwords and such, but many times that sensitive data you find will be used to dig deeper into the application. Utilities like Burp Suite can help to automate the initial finding of these bugs. Check the links below for more resources.
5. Security Misconfiguration
This is again another broad area. Misconfiguration can happen at any level of the application, from the server and database to frameworks and front end components. Although all of these areas can contain security misconfiguration, the main areas attackers will look are development features such as debugging, file permissions, default credentials , etc. This is again an attack you should assume can come from within as well as from the outside.
Proper security hardening should be implemented throughout the stack and you should be extra aware of any external libraries or components that may pose a threat. Making sure all of your operating software is up to date is an easy and important step to keeping your application secure. Beyond that make sure you check other simple things such as open ports, debugging functionality and default credentials. One other important aspect that can easily be forgotten is dealing with errors. Do your error messages, and the way you handle errors reveal stack traces or other important information? You would be surprised at how much information can be procured from improper or default error handling.
Standard error messages tend to be verbose so that the developer can easily identify the problem. If you leave these messages verbose, attackers can easily use this information to make assumptions about important key features of your application and exploit them. Your team should always make sure everything is up to date, proper QA testing is happening on a regular basis and that strong architecture choices have been made in the design of your application. Scanning and doing frequent self assessments is also very helpful and can quickly expose holes that you may have.
Video Example of Security Misconfiguration Exploit
OWASP Cheat Sheet for Testing Error Codes
PC Mag Article on Server Best Practices
Hacking Tips: Security Misconfiguration is one of those bugs that generally requires research into the technologies used by an application. Doing code review or decompiling applications can be in order, especially when dealing with mobile applications. Below I have linked to some great resources to help you keep on top of the latest security research as well as methods for decompiling.
4. Insecure Direct Object References (IDOR)
This exploit, like several before it, boils down to, what things can an authenticated user can access. Most all applications need to make logic decisions and load information based on user input. If anyone can change reference to objects in the logic flow, via the URL for example, you are exposed. This exploit refers specifically do being able to reference objects that do not belong to that specific user. For example, an attacker might be able to make a call to your database and reference someone else's account information or make changes to a their profile.
Beyond being able to simply reference another users information via object reference, with todays modern web techniques I also include reference to functionality objects as well. Being able to find and reference objects that are responsible for application logic and functionality need to be considered as well. The solution for this problem is to always be checking and testing access as well as using per user and session indirect object references. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
Good Video Description on IDOR
OWASP Guide for Testing for IDOR
HackerOne Disclosed IDOR Example
Hacking Tips: Insecure Direct Object Reference can be one of those vulnerabilities that can lead to higher priority bugs. When you find an IDOR in an application it can very well be a sign of weak design. Again, this is one of those bugs that will be exposed by using good mapping techniques and understanding logic flow as well as the technologies used in the application stack. Below are some great resources when it comes to IDOR.
3. Cross Site Scripting (XSS)
XXS is probably the most well known of all the OWASP vulnerabilities and is also one that a lot of research has been done on. From filter by-pass to Polyglot payloads, there is a lot to cover with XXS. If you are unfamiliar, Cross Site Scripting, or XSS, is when an attacker sends text-based scripts to exploit flaws in the interpreter. This can lead to many different issues, such as the ability to load malicious scripts to the server that loads the application so that anyone who visits the page after the attack is now vulnerable. Imagine all the things an attacker can do when allowed to load malicious scripts on your application!
There are two main type of XXS. Reflected(non-persistent) and Stored(persistent). Reflected XXS is by far the most common web vulnerability. The attack consists of a malicious and malformed URL that the user is tricked into clicking. When they do, the script added to the URL runs. This only happens once, any time someone clicks on the specific URL. Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.
Stored or persistent XXS is far more dangerous and far reaching. It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read. Persistent XSS vulnerabilities can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.
Great Computerphile Video on XXS
OWASP XXS Filter Evasion Cheat Sheet
HackerOne Disclosed XXS Example via Uber
Hacking Tips: XXS is a great place to start if you are new to hacking or Bounty programs. There is a treasure trove of easy to find information on the subject and much like injection, it can be fairly easy to find. Polyglot payloads are a great way to save time during testing as well. Most bounty programs today only pay out for stored XSS, as they feel anything that requires social engineering is not their responsibility.
2. Broken Authentication and Session Management
A very serious vulnerability indeed. Being able to bypass authentication gives an attacker free rein over your application. Usually applications implore the use of usernames and passwords which then generate a session id or token. Imagine now what happens when an attacker gets their hands on that session value. They can easily impersonate other users or even admins, depending on the specific flaws.
There are several ways your application can be vulnerable. Unencrypted connections, predictable login credentials, session values that do not time out, unencrypted stored credentials and last but not least, session IDs that are used in the URL. If some of these look familiar, it is because we have seen them before. You can now start to paint a picture of how, if you are exposed to any of these vulnerabilities, they can be chained together and things can escalate quickly.
The best mitigation for this weakness is to have a single set of strong authentication and session management controls. OWASP lays out a great road map for how to deploy this, which I have linked to below. Also, having a simple interface for developers is helpful as well. This is also where being exposed to XSS can lead to the ability to steal session information. If an attacker can load a script, persistent or not, that the application trusts and gives the session token to, the attacker can easily steal and reuse it to make actions on behalf of the victim.
In-Depth Video on Broken Authentication
OWASP Cheat Sheet for Lost Password Functionality
Hacking Tips: Broken Authentication can be tested for in many ways. Making sure you have properly mapped the entire application and understand the logic flow is the first and most important step. Using an intercepting proxy such as Burp Suite here is key. Below I have linked a couple great resources and examples to help you get started breaking applications authentication and session management.
1. Injection
Here we are at the top of the list. Injection is still to this day the most serious and prevalent vulnerability facing applications. So simple that Troy Hunt has a presentation where he has his 6 year old son performs SQL injection on a live site. When speaking about injection, SQL injection is what most people are talking about. Almost every single application utilizes several SQL style databases so you can see why it remains at the top of the list. Application logic generally boils down to calls for information stored in a database, which presents a large attack vector. Any user input that interfaces with your database should be assumed to be malicious. These flaws are particularly prevalent in legacy code bases.
Preventing injection requires keeping any user input or untrusted data seperate from commands and queries. Preferability you should utilize safe APIs which use a parameterized interface. If you are not going to use a safe API, then making sure to sanitize any and all user inputs using escape syntax is another method. Beyond that implementing a "white list" of acceptable characters is something you can consider. Using all three is best though. Attackers have become extremely crafty when it comes to injection methods and whole suites have been developed, such as SQLMap, to speed up and automate the process of finding SQLi.
Example of an SQL Injection Attack
Hacking Tips: When looking for injection flaws, starting with a scanner or something like SQLMap is usually best. All user inputs should be tested along with any URL based functionality that makes calls to the database. Below are links to some examples and resources.