The export tool worked as followed:
- User logs in and begins export process
- User receives an email with a link to download their data
- User visits link within 48 hours and obtains all their data
above image and original report from (cristina cordova)
The problem occurs in step 2 with the created link. In this situation the link was predictable. The link was built in the format of "<username>-export.zip". So, if you have a list of usernames (perhaps you were able to perform a username enumeration attack on the site or just guessed usernames based on the naming pattern) then you could script the requests to download everyone's data.
There is one caveat to consider, the victim account must have activated the export tool and the attacker must attempt their attack against the particular victim within 48 hours.
I should state that the oink site was designed with all user data as publicly accessible, so this isn't exactly a major data breach. However, even when the data is technically already public, an issue like this can still cause surprise to users and cause them to question overall data handling and impact site reputation.
How could this system been designed better?
There are a few options that can be considered:
1. The URL should contain a large random nonce. This approach would prevent an attacker from easily guessing a valid URL.
2. Force the user to authenticate before the download starts to ensure it is the authorized user for the requested data.
Let's assume option #2 wasn't a valid design choice due to other factors (cause it's really the simplest way and there must have been some reason they didn't pick it). Is option #1 on its own enough? If the nonce is large enough then the answer is yes.
Why is a large nonce good enough?
Sure, you can attempt to brute force any nonce values in hopes of finding a valid value. But if these tokens are sufficiently large and short lived, you really don't have a chance. Remember we happily rely on large nonce values as session IDs for every authenticated transaction. If it was realistic to brute force a valid session ID then attackers would simply do that and not worry about trying to compromise users, applications, or the browsers.
-Michael Coates - @_mwc