A Lesson in Predictable Identifiers

Authorization can be a fickle thing, especially when you want to perform authorization without performing authentication immediately beforehand.  The situation I'm speaking of came front and center for Oink as they created an export tool to allow users to download their data.

The export tool worked as followed:

1. User logs in and begins export process
2. User receives an email with a link to download their data
3. 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

Security 101 OWASP Community

A few weeks back I posted a thread in the OWASP leaders community regarding several security talks I'd presented at various developer groups.  The talks individually went great, but I left with a feeling that I'd missed an opportunity to establish a continued method of interacting with the new group. We'd covered lots of new security topics and there would mostly likely be continued questions or discussion over the coming days.

In response we've now created security101@lists.owasp.org. This OWASP mailing list has been created with the specific purpose of helping individuals new to security with basic security questions.  The goal is to have a place where any type of new security question could be asked.  The answer could be a brief explanation of security concepts or perhaps a link to existing OWASP material or presentations on the topic.  And if we don't have OWASP material available, that's a good indication we've got a gap to address.

So, if you're new to security and have a question, please jump in.  If you've got some cycles to help out we need you too. 


https://lists.owasp.org/mailman/listinfo/security101


-Michael Coates - @_mwc