Is anyone else kind of shocked that this particular vulnerability exists given that Facebook employs "the best and brightest" in the industry?
This isn't one of those vulnerabilities that relies on numerous seemingly unrelated steps and makes you wonder how the person ever thought it up.
Instead, this is security 101 stuff. Facebook simply wasn't making sure userFor(appKey) == owner(albumId). I would've assumed obvious holes like this don't even exist in the API. So, props to the author trying it out. Wish I had.
That is not how a scalable architecture looks like. You don't want to handle authorization in the same service that's responsible for deleting the resource. Yes, there should have been tests in place, but no it's not a missing if condition.
Couldn't you have a service which checked you were allowed to delete something, then handed a deletion order back (essentially a signed xml blob) which would then get passed on to the actual deletion service (and here validated)? That way no issue with scalable architecture and no issue with hacks like this.
This isn't one of those vulnerabilities that relies on numerous seemingly unrelated steps and makes you wonder how the person ever thought it up.
Instead, this is security 101 stuff. Facebook simply wasn't making sure userFor(appKey) == owner(albumId). I would've assumed obvious holes like this don't even exist in the API. So, props to the author trying it out. Wish I had.