2

I hope this is the right place to ask this question. I am currently discussing with a colleague if it's possible to get the browsing history of a visitor of my site with a special HTML5-Application.

Let's say the user visited Amazon.com, Facebook.com and then navigates to my site example.com where he uses an HTML5-App.

My Colleague claims that using the History-API (https://developer.mozilla.org/en-US/docs/Web/API/History_API or http://diveintohtml5.info/history.html) I should be able to see that the user visited Amazon.com and Facebook.com before. Why? Because in order to manipulate the browsing history, the HTML5-App needs to read the history first. Is this true? I can't really believe it.

If it's not true, can you explain to me how exactly this History-API works?

3

I should be able to see that the user visited Amazon.com and Facebook.com before.

No, you can't arbitrarily access the browsing history.

  • You can find out how many entries the history has (history.length).
  • You can navigate back to any of these history entries (e.g. history.go(-2)).
  • You cannot learn what these entries are, neither the domain nor the URL.

in order to manipulate the browsing history, the HTML5-App needs to read the history first.

Well, details of the previous entries exist in memory, but the browser hides them from content scripts. Otherwise, being able to access the history cross-domain would obviously cause massive privacy problems. Just imagine one of the previous sites had a password reset token in the URL.

If it's not true, can you explain to me how exactly this History-API works?

In HTML5 you can manipulate the state of the history stack, e.g. using history.pushState(). This is particularly useful for websites with lots AJAX interaction that want to change the URL without reloading the entire page.1 But you can only change the URL to paths that belong to the same domain and you can only access the state objects for the current page. You can find additional security considerations in this security review of the API by Mozilla.

(Note that in the past there have been lots of browsing history leak vulnerabilities that could disclose visited URLs through side channels, e.g. by abusing CSS properties. But these attacks aren't directly related to the API.)

1It can also be useful for an attacker who wants to hide reflected XSS in the URL by dynamically changing the path to something less suspicious. That's why back then this extension of the API has been somewhat controversial.

  • I have heard that facebook know a lot about us using the history of pages we visited, it also keeps a tracks of all the tabs that are open while using facebook in one of tab. Also i have heard that the scripts that facebook leaves in our browser keeps updating facebook about our details etc... are these all fake ? Rumours ? Thanks in Advance – Surendra Patil Feb 18 '17 at 19:04
  • @SurendraPatil Facebook isn't capable of doing that. It has no more permissions in your browser than any other website. – Arminius Feb 18 '17 at 19:10
  • So all the data mining, all the survey it does is totally based on activites ( photos likes, clicks, advertisment etc.. ) only ??? Is it possible for a android app to access the broswer history of our normal browser(default) ? – Surendra Patil Feb 18 '17 at 19:12
  • 1
    Third party websites add Facebook's Like or Share or other buttons on their own websites. You visit Facebook, and then you visit this third-party, facebook knows that you visited it, because of its code running on it. – DavChana Feb 18 '17 at 20:31
  • facebook runs code on most pages since the like button is a whole iframe'd HTML page/app, not just a simple <button> on the embedding page. This lets FB execute code, set cookies, phone home, etc, on myraid sites. If you run their code, they will know. – dandavis Feb 19 '17 at 9:43
0

Your coworker is wrong. The JS history API is not allowed to cross-platform access previous history items. When you look into the API, you'll find no reading calls, just deleting, replacing, adding to the history. There's history.back(), but that will actually leave the current page, and also, doesn't give you any info you wouldn't have gotten through the HTTP referrer.

So, no, to modify something you don't need to read it. The browser internally needs to keep the history, but there's no need to expose that content to the modifying JS application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.