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.
I can imagine you could work around that issue just by once redirecting onto your own site first.
On the surface, sounds like a difficult problem to solve safely. On a related note, I often have the back button not work because I hit back and chrome cached a redirect to some other page and it immediately redirects again before i can even spam back again. Need to long press back to get a longer history to go back further.
Because there's a 300-comment thread on Hacker News[1], where people complain that modern web-apps don't respect the back button (Those people want it to go 'back' in state, inside the webapp, instead of bouncing you back to the previous website they visited.)
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.
Most people are just going to hit back until it looks like they're at the right site, so I don't think you'd have to change the previous history, just add your own entry after the one for the site they came from.
That would require storing where they came from as well as waiting for--or forcing--them to visit at least one more page on the attacker's site. So it'd still make backjacking harder.
Maybe pages that immediately redirect on first arrival should also not count toward back history.
Now a more perfect solution would require browsers snapshot where the user cane from then block or warn about pages at the destination that look too similar. Though that seems unnecessarily complex for most users.
