3 ms·

Rewriting history in general is pretty dumb that it’s allowed.

• quickthrower2 4y ago
  This attach is similar to linking to g00g1e.com and setting up a mock page there. Impersonating sites is going to be hard to secure technically at all.
• notriddle 4y ago
  As much fun as it is seeing everybody reiterate the "SPAs are stupid and we should all go back to native apps" argument for the thousandth time with exactly the same arguments again... It's all a moot point, because you can reproduce this particular attach using nothing but 2001-era DHTML. Start with a page that has a hidden iframe, a link that targets it, and a timer that polls the contents of the iframe. When the page first loads, use JS to click the link to add a new item to the back stack. If clicking the link with JavaScript doesn't add a back stack item, make the link visible, but also attach an onclick event handler to it so that the link can simultaneously do what you want and also do what the victim wants. After you've poisoned the back stack, you can detect that the user clicked "back" when the iframe gets reset back to its initial page. Once this is done, use `document.body.innerHTML = whatever` to set up your fake SERP.
  • astura 4y ago
    Doesn't X-Frame-Options in the response header prevent this attack?
    • notriddle 4y ago
      No, you're thinking of clickjacking. The "attack" I'm thinking of is hijacking the back button, but done using iframes instead of history.pushState. It doesn't involve any third-party origins, so x-frame-options doesn't matter, because a domain owner that wants to launch this attack has control of all the HTTP headers.