8 ms·

Stealing the users back button with the History API (2013)

31 points by longrod 4y ago

superb-owl 4y ago
Huh...so you can add a third-party domain to the history? That seems like a security flaw. I would have imagined you could only add history for the current domain.
- Spivak 4y ago
  They can’t. Here’s the flow. 1. User goes to example.com. 2. The site immediately replaces the history state with example.com#history. 3. The site pushes a new history state example.com At this point your history looks like … google.com example.com#history example.com <— you are here 4. The user clicks their back button and you’re taken to example.com#history 5. The JS sees the hash and does a location.replace (i.e. navigate to) to some unrelated URL.
  - Arrath 4y ago
    I despise websites that capture my back button.
thunderbong 4y ago
Didn't work for me though on Chrome or Slimjet. Worked in Firefox! On Chrome based browsers, I see this error - [Report Only] Refused to load the script 'https://ryanseddon.com/dist/app.bundle.js' because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-MdC6fOvaO+dJENLQhOoRht9sHSJ++GoMxjtC5lOpUww=' 'strict-dynamic' https: 'unsafe-inline' 'report-sample'". 'strict-dynamic' is present, so host-based whitelisting is disabled. Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
- littlecranky67 4y ago
  CSP can be set through HTTP header, so a site with an explicit CSP configuration might allow this.
car_analogy 4y ago
History API? Modifying user history should require an exploit, not be offered voluntarily by the browser!
- munk-a 4y ago
  I've never liked calling it "History API" it's more focused on modifying what the back button will do. It exists primarily to support SPAs that have hard links for different specific resource views but never actually navigate the user off the single page - the History API allows these sites to drop some breadcumbs so that users can return to different visual states they observed on their screen while never actually navigating.... That all said - I think there are much better ways to accomplish this using, I believe (it's been a bit) location.Url updates that cause micro-reloads... however if your webapp is a 300 pound gorilla this approach is significantly less appealing due to the obvious breaks in user flow.
  - usrn 4y ago
    Man I really hate SPAs. Unless it's something like a drawing app or whatever where the back button doesn't even make sense they're usually awful.
    - rootusrootus 4y ago
      I think the biggest problem with SPAs is trying to put them in a web browser. So many compromises we make just to use a technology that wasn't designed with the idea that you'd build an interactive app on top of it. I don't know the solution, but I wish I could get a normal web, and then have a dedicated generic app sandbox that I can point at a particular app on the 'net.
- ajsnigrutin 4y ago
  Yep... most of the tracking and privacy issues exist, because browser expost too much apis to websites, many of those things not really needed for sites to work properly.
- FrenchDevRemote 4y ago
fleddr 4y ago
For the interested, the successor to the History API is the Navigation API: https://developer.chrome.com/docs/web-platform/navigation-api/ https://developer.chrome.com/docs/web-platform/navigation-ap...
kurupt213 4y ago
I don’t know why people do this because this is what makes people avoid your website completely. Fool me once…never again
superasn 4y ago
I think a simple website redirect middleware can do this and much more reliably. If a site is being shady there is hardly a way to stop it. Step 1: Redirect middleware checks for a cookie say 'A' Step 2: If no cookie, set cookie and redirect to main content. Step 3: User presses back button, comes to redirect middleware which sees cookie 'A' and this time it redirects to another shady website.
jawmes8 4y ago
Never understood why sites do that. Do they expect me to stick around and click some ads? I usually just close the tab and move on
- eyelidlessness 4y ago
  Most sites (IME) do it by accident. The API as designed is a footgun, so much so that there’s an active proposal which would basically replace it. (I can’t speak to how much better the replacement might be.) Obviously it can be used intentionally to hijack your session history, but it’s also surprisingly easy to do by mistake unless your state management is effectively designed for concurrency (which the API isn’t, but it encourages the same kinds of bad patterns).

31 points by longrod 4y ago

Huh...so you can add a third-party domain to the history? That seems like a security flaw. I would have imagined you could only add history for the current domain.

Spivak 4y ago
They can’t. Here’s the flow. 1. User goes to example.com. 2. The site immediately replaces the history state with example.com#history. 3. The site pushes a new history state example.com At this point your history looks like … google.com example.com#history example.com <— you are here 4. The user clicks their back button and you’re taken to example.com#history 5. The JS sees the hash and does a location.replace (i.e. navigate to) to some unrelated URL.
- Arrath 4y ago
  I despise websites that capture my back button.

thunderbong 4y ago

Didn't work for me though on Chrome or Slimjet. Worked in Firefox! On Chrome based browsers, I see this error - [Report Only] Refused to load the script 'https://ryanseddon.com/dist/app.bundle.js' because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-MdC6fOvaO+dJENLQhOoRht9sHSJ++GoMxjtC5lOpUww=' 'strict-dynamic' https: 'unsafe-inline' 'report-sample'". 'strict-dynamic' is present, so host-based whitelisting is disabled. Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

littlecranky67 4y ago
CSP can be set through HTTP header, so a site with an explicit CSP configuration might allow this.

car_analogy 4y ago

History API? Modifying user history should require an exploit, not be offered voluntarily by the browser!

munk-a 4y ago
I've never liked calling it "History API" it's more focused on modifying what the back button will do. It exists primarily to support SPAs that have hard links for different specific resource views but never actually navigate the user off the single page - the History API allows these sites to drop some breadcumbs so that users can return to different visual states they observed on their screen while never actually navigating.... That all said - I think there are much better ways to accomplish this using, I believe (it's been a bit) location.Url updates that cause micro-reloads... however if your webapp is a 300 pound gorilla this approach is significantly less appealing due to the obvious breaks in user flow.
- usrn 4y ago
  Man I really hate SPAs. Unless it's something like a drawing app or whatever where the back button doesn't even make sense they're usually awful.
  - rootusrootus 4y ago
    I think the biggest problem with SPAs is trying to put them in a web browser. So many compromises we make just to use a technology that wasn't designed with the idea that you'd build an interactive app on top of it. I don't know the solution, but I wish I could get a normal web, and then have a dedicated generic app sandbox that I can point at a particular app on the 'net.
ajsnigrutin 4y ago
Yep... most of the tracking and privacy issues exist, because browser expost too much apis to websites, many of those things not really needed for sites to work properly.
FrenchDevRemote 4y ago

fleddr 4y ago

For the interested, the successor to the History API is the Navigation API: https://developer.chrome.com/docs/web-platform/navigation-api/ https://developer.chrome.com/docs/web-platform/navigation-ap...

kurupt213 4y ago

I don’t know why people do this because this is what makes people avoid your website completely. Fool me once…never again

superasn 4y ago

I think a simple website redirect middleware can do this and much more reliably. If a site is being shady there is hardly a way to stop it. Step 1: Redirect middleware checks for a cookie say 'A' Step 2: If no cookie, set cookie and redirect to main content. Step 3: User presses back button, comes to redirect middleware which sees cookie 'A' and this time it redirects to another shady website.

jawmes8 4y ago

Never understood why sites do that. Do they expect me to stick around and click some ads? I usually just close the tab and move on

eyelidlessness 4y ago
Most sites (IME) do it by accident. The API as designed is a footgun, so much so that there’s an active proposal which would basically replace it. (I can’t speak to how much better the replacement might be.) Obviously it can be used intentionally to hijack your session history, but it’s also surprisingly easy to do by mistake unless your state management is effectively designed for concurrency (which the API isn’t, but it encourages the same kinds of bad patterns).