Earlier quoted context omitted.
Well actually you can look at it exactly like a kernel, where the backend is the kernel and http clients are the processes, and access control is done at resource level access, by the kernel. The things is, you couldn't even model facebook access with unix perms, and if you've played with acl, I think you realize that the problem is not solely due basic soft architecture. That said, Facebook should have addressed thi…
But Facebook permissions can be modelled. They may not be direct mappings to UNIX permissions or ACLs, but that's taking my OS analogy too literally. The point is, Facebook should have a shared component that does the permission checks, rather than giving each page global access and relying on the author to do the checks themselves.
The easiest bug bounties I have won
11–20 of 29 posts
Re: The easiest bug bounties I have won
#12Re: The easiest bug bounties I have won
#13I've been wanting to start doing bug bounties for a while now, but I have only been able to find serious bugs in sites without bug bounty schemes. I was starting to think that it would be impossible to get any bug bounties because of the number of people searching, but this post gives me some confidence.
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).
Re: The easiest bug bounties I have won
#14It is quite saddening that there is a recent trend of hiding the complete URL from the user when the URL itself conveys much information. When the URL is hidden the user is not given the incentive to look at the URL, let alone modify it. This kind of bug should have been discovered much sooner when the user is given the opportunity to directly look at the URL and experiment with it.
Be careful with simple "experimentation" like this. You can fall afoul of the CFAA for exactly this.
Re: The easiest bug bounties I have won
#15I've been wanting to start doing bug bounties for a while now, but I have only been able to find serious bugs in sites without bug bounty schemes. I was starting to think that it would be impossible to get any bug bounties because of the number of people searching, but this post gives me some confidence.
I've been doing bug bounties for the past few years, here's some advice to get started: 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 Ocul…
Re: The easiest bug bounties I have won
#16Earlier quoted context omitted.
But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions. 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 stat…
Given the relentless appearance of this style of security bug in multiple Facebook pages, I think your description of a careless, amnesiac state is spot on.
At least they're not a bank.
Re: The easiest bug bounties I have won
#17Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
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?
Re: The easiest bug bounties I have won
#18Earlier quoted context omitted.
I've been doing bug bounties for the past few years, here's some advice to get started: 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 Ocul…
In general do you need to register or anything like that? I think it'd be a fun thing to try, but also don't want any of the bad legal repercussions that can come with it
All bug bounty programs have rules that outline what parts of their site/product you can test and what kinds of bugs they are looking for (here's Facebook's https://www.facebook.com/whitehat/). As long as you follow the rules you won't have any legal problems.
Re: The easiest bug bounties I have won
#19I 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?
Re: The easiest bug bounties I have won
#20Can anyone comment on when is a good time to start a bug bounty program? 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.