Sensitive Data Exposure tutorial – OWASP Top 10 training
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.
- Firstly, we will install tcpdump on our OWASP Top 10 training VM box.
sudo apt install tcpdump -y
- Then, we will list our network interfaces to listen to only the one which is connected to our target network.
ip a
- From the output above, we are interested in the docker0 interface since that’s the one transmitting the target HTTP traffic.
- 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'
- Now, let’s go to the WebGoat challenge under the Sensitive Data Exposure menu, challenge 2. Then, click on the login button.
- You will immediately see a POST request showing up in the tcpdump output.
- 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 http://10.14.3.54:3000/ftp/order_XXXX.pdf
. What if there is a directory listing enabled on the /ftp directory? Let’s try that out!
- Go to
http://owasp-vm-box:3000/ftp/
- 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.
- 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.
- 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 tohttp://10.14.3.54:3000/ftp/coupons_2013.md.bak%2500.md
- Notice that we successfully accessed the list of coupons in plaintext.
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
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.
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.