Hacker News Reader

Comment by sim0n | Hacker News Reader

How could you take advantage of the leak without JavaScript?

You would use background-images for the links - they will trigger the parametrized GET to the server. Present browsers only load the image if it is visible and not hidden ("display:none"). They can be transparent 1px - they just need to be turned visible one by one if a slecetor fits.

For example: you'd hide every link, except the one that should trigger a GET to the attackers server to leave the information there. Easy - and with cascaded :NOT and ~ selectors you can accomplish this on scale. The links would look something like this:

A while back i demonstrated that a website without JS can trigger GET-requests BY HOVERING A LINK. My coworkers didn't believe me - they were wrong. Caveats: When caching is enabled this attack will trigger just once - but that is enough in that case.

I found the codepen, that i had made back then: http://codepen.io/teamgroove/pen/mIxfg

USE LYNX: Turns out one shouldn't just turnoff JS - but images also. Maybe then better use: lynx as a browser (with all cookie-stuff-deavtivated and behind a tor-proxy or better: proxy-chains) if concerned about privacy. Even that will NOT be "secure enough" - of course - it just wouldn't expose your browsing-history in the first place - which was the topic.

If you turn JS off, you'll still see a mole in the position which signifies your visited subset of tested-for addresses. If you inspect the code, each position has multiple anchor elements, the last of which has an onclick right now. All you'd have to do is add a href to it.

How do you send this information back to the browser then? You can't embed it into forms nor send requests to the server. While this information is always there (unless you disable CSS), there is no way to extract it (unless you use JavaScript).

This is why OPs point is still true. Without JavaScript, this information is worthless.

The point is that you can use the technique on a legitimate link on the page, e.g. a log-in button. The browser will then make a request anyway, through which you can pass the information back to the server. That is what paxcoder means by saying using a href instead of an onClick. No JavaScript is needed for this.

Put 10 links on the page, each with a slightly different href. Use CSS to make 9 of the links invisible, based on the browser history, so the user sees only one link. When they click on that link, the URL of the page they visit reveals which pages are in their history. The server can store that information, and you can tie it up with the session. To prevent spiders crawling the links, you could use buttons instead, making POST requests.

No JS required, just CSS and HTTP.

The `href` attribute of the visible mole could pass the data back to the server.

Oooh, that's clever. So the mole I clicked on in the author's POC was in a position that was unique to my combination of visited and non-visited sites. The evil attacker has no way of knowing that though, until I play the "game", click on the mole, and trigger a GET request with the info. Do I have that right?

Even with JS the the attacker has no way of knowing it until a user-initatied event, such as a click. But yes, in the non-JS case it must cause a full page reload, but as pointed out in a sibling thread, that could just be on a legitimate link (like, say, a link to elsewhere on the site, just passing the data in the query string).

Reply on news.ycombinator.com