Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I recorded user behaviour on my competitor’s websites

dejanseo.com.au

Post reply on HN
Print view View original

301–310 of 329 posts

Re: How I recorded user behaviour on my competitor’s websites

#301

Post by Ajedi32 »

Xeanort wrote: post #299
Ajedi32 wrote: post #248

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…

To make 4. useful, links with the domain different than the open one should not be allowed to be added to History, otherwise you can bypass it with a different domain. And without 4. this new limitation could be bypassed with a redirect (from the same domain).

> links with the domain different than the open one should not be allowed to be added to History

This is already the case, and AFAIK it's always been this way.

From [the HTML standard for pushState][1]:

> Compare newURL to document's URL. If any component of these two URL records differ other than the path, query, and fragment components, then throw a "SecurityError" DOMException.

[1]: https://html.spec.whatwg.org/multipage/history.html#dom-hist...

Re: How I recorded user behaviour on my competitor’s websites

#302

Post by sctb »

davidsergey wrote: post #145

Wow. A) You are a creep. B) However thanks for sharing this. C) I'm not sure if you shared this for google to fix, or to brag about it - so still a creep. D) Next time just apply for a bounty. E) Creep.

We ban accounts that post like this so please stop and read the guidelines: https://news.ycombinator.com/newsguidelines.html.

Re: How I recorded user behaviour on my competitor’s websites

#303

Post by joveian »

UncleMeat wrote: post #262
dorgo wrote: post #100

Earlier quoted context omitted.

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.

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.

Re: How I recorded user behaviour on my competitor’s websites

#304

Post by bhelkey »

hw_penfold wrote: post #9

In many ways this is malicious deception. In any instance where a login form is included in the scraped mirror, that represents an attacked user, and a phishing attempt. If someone did this in the wild, in an uncontrolled situation involving random strangers, it risks serious misinterpretation, and worse.

> I had this implemented for a very brief period of time (and for ethical reasons took it down almost immediately, realising that this may cause trouble)

The author did this in the wild, involving random strangers.

Re: How I recorded user behaviour on my competitor’s websites

#305

Post by SquareWheel »

AndrewKemendo wrote: post #282
SquareWheel wrote: post #195

Earlier quoted context omitted.

>Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue. Sure, I agree. But what does it have to do with the parent comment's claim? I've read much of the discussions involving the early push for HTTPS, and the developers involved were very fastidious.

The point is that google should be penalizing sites that do that in search results, or at least in chrome with some kind of browser recognition - as the OP states in the article.

They should do more than penalize them in search. They should add them to their malicious site list.

Re: How I recorded user behaviour on my competitor’s websites

#306

Post by yashap »

Ajedi32 wrote: post #285
yashap wrote: post #278

Earlier quoted context omitted.

Another possibility - if the referring page is a different domain, overriding back is ineffective (the browser just does a “real” back in these cases).

I don't understand. Are you suggesting that if you arrive at a site from Google, the history API should just not work? For example, let's say a user arrives at a single-page application from Google, and clicks a link on that page to get more information. The site adds a history entry with pushState, but doesn't reload the entire page. Are you saying that in this case, when the user clicks back they should get sent ba…

Hmm touche, this wouldn’t fix much

Re: How I recorded user behaviour on my competitor’s websites

#307

Post by Xeanort »

Ajedi32 wrote: post #301
Xeanort wrote: post #299

Earlier quoted context omitted.

To make 4. useful, links with the domain different than the open one should not be allowed to be added to History, otherwise you can bypass it with a different domain. And without 4. this new limitation could be bypassed with a redirect (from the same domain).

> links with the domain different than the open one should not be allowed to be added to History This is already the case, and AFAIK it's always been this way. From [the HTML standard for pushState][1]: > Compare newURL to document's URL. If any component of these two URL records differ other than the path, query, and fragment components, then throw a "SecurityError" DOMException. [1]: https://html.spec.whatwg.org/mu…

You are right that they cannot be added to History, but the code used here changes the back button functionality with

  $(window).on('popstate', function() {
    window.location.href = 'https://example.com';
  });
I just tested it and it works with different domain in latest Firefox.

Re: How I recorded user behaviour on my competitor’s websites

#308

Post by Ajedi32 »

Xeanort wrote: post #307
Ajedi32 wrote: post #301

Earlier quoted context omitted.

> links with the domain different than the open one should not be allowed to be added to History This is already the case, and AFAIK it's always been this way. From [the HTML standard for pushState][1]: > Compare newURL to document's URL. If any component of these two URL records differ other than the path, query, and fragment components, then throw a "SecurityError" DOMException. [1]: https://html.spec.whatwg.org/mu…

You are right that they cannot be added to History, but the code used here changes the back button functionality with $(window).on('popstate', function() { window.location.href = 'https://example.com'; }); I just tested it and it works with different domain in latest Firefox.

Fair point; popstate allows you to do pretty much anything when the history entry is for the current domain.

That's not really an issue for this particular attack though, which relies on the reverse scenario: the user remaining on the current domain when they expected to navigate back to the third party search engine.

Re: How I recorded user behaviour on my competitor’s websites

#310

Post by user3359 »

brlewis wrote: post #173
SmellyGeekBoy wrote: post #137

Earlier quoted context omitted.

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

Post reply on HN