Challenge: 

Name: GDPR Data Theft

Description: Steal someone else’s personal data without using Injection.

Difficulty: 4 star

Category: Sensitive Data Exposure

Expanded Description: https://pwning.owasp-juice.shop/part2/sensitive-data-exposure.html

Tools used:

Burp Suite, FoxyProxy

Resources used:

Solution Guide

Methodology: 

To start this challenge I first went to the expanded description, where I noticed a few curious notes:

1. I need to steal the data of a user who has previously placed an order.
2. HTTP request fiddling would be insufficient.
3. The server responses will be key to solving the challenge.

The first thing I did was log into an account which I knew had placed orders and requested an export of personal data from the Account -> Privacy & Security menu and tracked the packets using Burp Suite. The export gave me a JSON object with a few data fields filled in concerning the user and past orders, but there was nothing worth mentioning in the packets or browser’s developer tool tabs.

Then, I decided to try making an order and seeing what changed about a user’s account when an order was created. What I found was that that there was an order number created, allowing the system to track that order.

From here, I checked Firefox’s Developer Tools Network tab to see what data was being sent to me.

Taking special note of the format of the “email” field (and the Solution Guide), I opted to make a new user with an email with all consonants and vowels in the same positions, but with vowels replaced with different characters. If those asterisks acted as wildcard characters, then creating a nearly-identical user might trick the server into sending me the wrong user’s data.

Then, I went back to the “Request Data Export” form.

And from an entirely new user (jam@juice-sh.op), with no order history, I received the data from a long-time customer (jim@juice-sh.op).

Prevention and Mitigation Strategies:

OWASP Privacy Protection Cheat Sheet

Lessons Learned and Things Worth Mentioning:

Honestly I’m not sure what I was supposed to learn from this. That the email address was slightly obfuscated doesn’t necessarily imply that the asterisks are wildcard characters, nor that a second email account with those wildcard characters filled in differently would or should lead to the exploitation of a vulnerability. I try to look for every possible lesson in the challenges where I use the Solution Guide, but in this case I just don’t see what the intended lesson is.