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
Burp Suite, FoxyProxy
To start this challenge I first went to the expanded description, where I noticed a few curious notes:
- I need to steal the data of a user who has previously placed an order.
- HTTP request fiddling would be insufficient.
- 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 (email@example.com), with no order history, I received the data from a long-time customer (firstname.lastname@example.org).
Prevention and Mitigation Strategies:
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.