So for this to work you need to know the document ID, and also the person who owns this document. You then need to trick them into looking at their document on your domain, and then from there, need to persuade them somehow to press the send feedback button.
I'd also note that the feedback button is a button that I suspect very very few people ever press. I certainly never have. I also don't know the IDs to any documents I might find interesting but can't read, and if I find a document via some random google search that I can't look at, I generally have no way of knowing how to contact the owner so I can try to send them phishing emails to get them to look at their document on a non-google URL.
There's been a bunch of cases where google has paid out very substantial bounties, and given the extreme difficulty of both meeting the attack prereqs and then managing to pull off a very sketchy exploit process at the same time I think the sum paid is more than fair.
$3.3k is about a week's worth of time for a poorly-paid developer before overhead.
It's not reasonable. At those rates, the only people who will be able to afford to be paid to do security work on Google products will be ones who sell on the gray/black market. The whole point of bounties was to give a path without the need for that.
These exploits are often not so interesting as written and with current normal setups, but eventually become more interesting if never fixed.
1. You need to know the document ID you're targeting (Stack Exchange once worked the ID out to ~256 bits).
2. You have to get the victim to interact with a Google doc on a site that you control (you need to re-dress the Google Docs interface, get the victim to your site, and then have them treat your site as if it was Google Docs).
3. You need to get the victim to use the Google feedback feature in order to trigger the vulnerable postMessage.
What's a scenario in which an attacker gets these stars to align? (I'm sure there is one).
1. I go to a job interview at a company that uses a chromebook with a restricted account. The interviewer sits next to me as I go through the process.
2. As we go through the steps in a google document, I need something from my resume on my website. I fumble with the URL bar slightly which hopefully has the doc ID, possibly because I once closed the document "by accident" and brought it back up.
3. While discussing whatever brought us to my website, I click on something but act like I am switching tabs.
4. At the end of the process in their document, I point out how strange the Google Docs looks now and press the feedback button to show my corporate soft skills.
5. The companies hiring interview document is now floating around my school and in 10 years half of their engineering is my Alma Mater.
All three of those conditions are independently rare. The equivalent conditions are rare in all CJ bugs, which is a reason CJs are sort of a running joke in appsec. This bug isn't a joke (look at the target and the impact), but condition (3) is also way more unlikely than the median CJ report somewhere else.
If I understand the bug correctly --- maybe I don't --- this researcher got what might perhaps be the largest bounty ever paid for a CJ bug.
Are you sure this impacted multiple products? Reading the article the main reason he was able to exploit this for Google docs was the X-Frame-Options header. It's not clear that other products have this.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Whereas the previous comment was accusing the other one of lying about testing it.
Or most/all bug bounty programs, actually.
What would you suggest, a bounty calculated via a multiple of company stock price?
They could have also offered nothing, which was common up until a decade ago or so. Moreover there isn't a market for security bugs like this, so it's not like Google is underpaying relative to some independent valuation.
The only reason to pay more is out of some ethos that the reporter "deserves" more, but that's not how business works. The value Google obtains by finding any given vulnerability approaches 0. This is why, among other reasons, good product security teams spend most of their time doing things other than searching for vulnerabilities in existing code.
It’s almost as bad as Apple’s reward program