271–280 of 329 posts
Surprisingly few comments about the actual attack mechanism here. IMO discussion of whether the author's PoC was ethical is interesting but far less important than the question about how to handle the actual vulnerability; this kind of attack could be used for far more damaging things than just recording user behavior. (Such as phishing.) IMO "get rid of the browser history API" (as the article author recommends) isn…
> I had this implemented for a very brief period of time (for ethical reasons) and then moved to one of my disposable domains where it still runs after five years and ranks really well, though for completely different search terms. Am I reading this correctly? He's been doing this since 2013 and still wants to use the white hat card?
Earlier quoted context omitted.
"I could have told Google directly about the problem, but then I'd have no cool story to publish on my blog" First of all, you definitely would. Standard practice is 1) report the bug privately, 2) wait for a fix, 3) get the go-ahead to publish your report and take credit publicly. That's how it always works; that's how security researchers build their reputations and careers. I guess you just weren't aware of that.…
I fail to see how dejanseo put the people at risk. Exposing how a tool is dangerous and poorly conceived isn't the same as conceiving a dangerous tool. In this case, Google put millions of people at risk, and dejanseo actually contributed saving them.
Earlier quoted context omitted.
I mean, Google has been told (over and over) for a long time that HTTPS doesn't fix trust on the web being broken, and that the back button shouldn't have an API. These are both well documented security problems. What has happened now is that Google is under public pressure and scrutiny to actually fix these things. A fire has been lit under their bum, and rightly so.
I believe they did remove the green lock from https sites to avoid implying trustworthiness. And removing the back button API is something Google can't decide on their own; it has to go through the standards process.
Nope. I'm on build 68.0.3440.106, the latest public stable build and as I'm writing this comment, little green lock and "Secure" right next to https://news.ycombinator.com.
What's concerning is that the post author seems not to see the problem with trying to sit on both sides of the fence at once. As others have said, the way this was done is likely to be against numerous laws in most major jurisdictions. If you wish to do this as a PoC then simply put a notice up on the page that initiates it and use dummy "competitor" content, so you've got some semblance of user content/transparency…
Not sure what you read, i read about a guy who was aware of it and handled it good enough.
What causes me to consider that the post author's handling was not "good enough" is that this demonstration needn't have gone ahead with what seems to have been content copied without permission and then served up to people without their knowledge when they rightly expected it to be genuine content that had not been interfered with.
I didn't for a moment suggest he wasn't aware of it, I suggested he seemed to think he was able to do a bad thing whilst being good. This wasn't a scenario where the only option was to test it for real.
Why do browsers allow changing the back button history before the visitor arrived at the domain? Seems like a subtle cross origin attack if that is truly what's happening.
They say that it's easy to build a webapp that correctly uses the back button, to go back in state inside the application.
What they don't realize is that it opens up the security hole outlined here. When you allow the page you're on to overwrite your back button's behaviour, you get shit like this.
Somewhat related, Google AMP is also destroying the ability for users to trust URLs. In fact it’s kind of the inverse problem; the URL bar says google.com when the user expects to be on another website. I wouldn’t be surprised if observing the AMP pattern subconsciously made users less suspicious of the trick in OP. It’s also a bit rich to see all the outrage here and deranking by google, since hijacking/proxying to…
Surprisingly few comments about the actual attack mechanism here. IMO discussion of whether the author's PoC was ethical is interesting but far less important than the question about how to handle the actual vulnerability; this kind of attack could be used for far more damaging things than just recording user behavior. (Such as phishing.) IMO "get rid of the browser history API" (as the article author recommends) isn…
Earlier quoted context omitted.
Is this that different than publicizing bugs? He tested it for a small amount of time, noticed a real security vulnerability (he could collect leads), and publicized his findings knowing Google would likely punish him for it. It's mildly unethical at worse, considering he could have happily done profitable leadgen at scale and it would have likely never been caught if he kept quiet.
Except he would have been caught by a few of his users. If I notice a scummy page impersonating Google, I'm gonna alert Google so they can do something about it. (For example add the page to the safebrowsing list)
Earlier quoted context omitted.
I hope so, and I also hope Chrome gets a fix for this.
I read the article, but still don't get what's Chrome-specific about this vulnerability, or what a good fix would look like. My reply to someone who proposed making the back button always go to the previous URL: https://news.ycombinator.com/item?id=17826406