No-one would accept such a shoddy design in an OS, yet in today's web apps it is apparently standard practice...
It has been proposed a number of times to put it all behind an API. I do not know if this has been finished yet. I remember an epic diff comment thread which only ended after the author defended her solution with a mathematical proof of correctness.
Can you share anything more about this anecdote? I feel like there's a really interesting story there.
That said, Facebook should have addressed this problem seriously by now.
Maybe it was too limiting (slow dev) to have change two things anytime they needed different data? Or perhaps at one point there were performance concerns?
The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac state where we're suddenly careless.
So if you have an URL like /{username}/year/{year}/profile_lists you would in a declarative style, say that "username" must match an existing Facebook user ID, and that the page viewer must be able to view certain privacy related settings of the username. When your code runs, you get the current user, the username from the URL is mapped to another user object, year is mapped to an integer etc.
It's an error to declare an API which needs access to a resource without saying what type of access is required. In Facebook's case maybe I'd go one step further and create a proxy object for the user that codifies those rules. So if you ask for "view profile friend stats" access, and it's granted, the user object your function gets cannot start modifying things.
Be careful with simple "experimentation" like this. You can fall afoul of the CFAA for exactly this.
IMO, the tradeoff of reducing phishing effectiveness is worth the small amount of additional effort needed to find this bug.
Especially since Android just launched a (proper) bug bounty program [0]. A ton of old problems are new again on Android, especially due to the fact a significant percentage of the OS stuff is being re-implemented in Java (IPC, sandboxing, etc). The more I dig into it the more I'm convinced very few people are conducting serious security reviews outside of Google.
Take this bug as an example: http://seclists.org/fulldisclosure/2014/Nov/81 An apk with system privileges (the settings app) would accept IPC messages from any unprivileged app and relay them with system privileges.
[0] http://techcrunch.com/2015/06/16/google-launches-bug-bounty-...
1. Monitor https://hackerone.com, https://bugcrowd.com and Twitter for announcements of new programs.
2. When looking for bugs in sites with existing programs like Facebook your best chance is when they announce a new feature or product. This includes acquisitions (Facebook paid out over $100,000 for bugs when they added the Oculus websites to their program).
In terms of how to get started, I definitely suggest monitoring the various bug bounty sites to see what's new and if a bounty's scope has expanded.
There's also a bunch of guides, tutorials, and tools listed on Bugcrowd's Forum: https://forum.bugcrowd.com/c/security-research
I have some clients with relatively small scale (small budget) projects. Is it better to post a bounty program on HackerOne? Or force them to budget to hire a security researcher consultant for a day to find high-level issues? Or both?
Bug bounties require a lot of time to keep on top of the submissions (essential in providing a good experience for researchers) and to filter out the noise of invalid and working-as-intended bugs.
Having a consultant come through will mean that your bugs will be the exception rather than the rule. Instead of every form field and parameter having a cross site scripting bug only that deprecated status page that you'd forgotten about will be vulnerable. A good consultant will also be able to help you fix the bugs and avoid them in the future.
Getting the low hanging fruit out of the way before launching This difference can easily pay for the consultant, since each XSS can be worth >$500 (or thousands in the case of the bounty programs I've worked on) so getting the low hanging fruit out of the way before launching is definitely worth it.
