Hacker News Reader

Comment by dorgo | Hacker News Reader

I think noindex is nice to have but not neccessary for this trick.

The only solution is to fix the back-button bug/vulnerability in Chrome.

It doesn’t seem like there is a fix, short of removing the history API.

Maybe restrict the history API to the same-origin-policy? Javascript could/should be allowed to manipulate browser-history only for the same domain. Just an idea.

That’s already the case! The history API only supports the current origin. From MDN:

> The new URL does not need to be absolute; if it's relative, it's resolved relative to the current URL. The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception. This parameter is optional; if it isn't specified, it's set to the document's current URL.

https://developer.mozilla.org/en-US/docs/Web/API/History_API...

The exploit in this article clones the appearance of Google results and competitor websites but leaves the user on the exploiter’s domain, so users who are savvy enough to notice the URL wouldn’t be fooled.

Why should anything be able to change the behaviour of the back button? If I click back it should take me back to the previous URL. If it breaks your one page 200MB JavaScript masterpiece then tough luck, come up with your own navigation.

Suppose we did what you said, and the back button only ever took you back to the previous URL.

I could still make a JS app that, on your first interaction with the page, moved you forward from https://example.com/ to https://example.com/#home. Then it sets a variable such that when you go back to https://example.com/ it shows a fake SERP. This is not an easy problem to solve.

This is a redirect, and would be trivial to detect and override at the browser level.

Actually, the back button should auto negate redirect pages

It just change `windown.location`.

And it would be very limited if JS can't change `window.location` to outside its current domain.

This exploit uses the history API, which allows JavaScript to change the URL in the browser URL bar to another URL with the same origin without actually causing a new full page request. The same-origin policy has always been in place, because it would obviously be a huge vulnerability to allow any web page to pretend to be a different website.

Changing window.location is different: it allows you to change the browser URL bar to any URL (including google.com, etc.), but it actually causes the browser to do a normal page load of the new URL, just like if the user had clicked a link to the new URL. Thus there is no spoofing vulnerability exposed by the window.location feature.

That's not even a solution.

User clicks on your site. You redirect to a fake search page and then redirect to your page after setting a cookie. Now back button sends them to the fake search results.

Independent of anything else, allowing the back button to take you back to a page that redirected you previously is bad UI. It is almost never the desired behavior.

Back button is not the only way to end up at noindex site.

? Sure, you can just call the URL directly in browser. Which other way do you mean?

The problem is not to end up at "noindex site" (btw: noindex is not a neccessary part of this scheme). The problem is to end up at "noindex site" thinking that the "noindex site" is a competitor site. And I don't see how such deception is possible without the backbutton-bug.

> The problem is to end up at "noindex site" thinking that the "noindex site" is a competitor site

And there is no solution for that, it seems. The solution for the problem <red in address line>'hey, that's noindex site!'</red> is obvious and simple.

> And I don't see how such deception is possible without the backbutton-bug

You told it yourself - 'you can just call the URL directly in browser'. And there are many ways and scenarios how that clicking on a link could happen.

Reply on news.ycombinator.com