Re: Ajax Back/Forward History problem document state by document.save()

On Tue, 22 Nov 2005, Gorm Haug Eriksen wrote:
> 
> Could pushState also be linked with URI's?

There has been a suggestion to do this, yes. I haven't yet examined it in 
detail (there are concerns over being able to stuff URIs in the history, 
as noted in this thread, but I'm not sure they are valid concerns).


> The current WHATWG on pushState draft only take a JavaScript object. 
> Wonder if it's possible to do pushState({execute : function() { ... })

Well, when you hit "back" the UA fires a "popstate" event on the <body> 
element with the given JS object as its argument. You can put whatever you 
like in the object, and handle it as you want, including putting function 
pointers in there.


On Tue, 22 Nov 2005, Karl Pongratz wrote:
> 
> Can I use document.save() or pushState() for evil? Yes, I can, as I can 
> use a simple "a" link for evil or as I can write a simple plain text web 
> page and use it for evil.

The real question is can you use document.save() for evil in a way that is 
more serious than the way you can use those other features for evil.


On Thu, 24 Nov 2005, kenny heaton wrote:
> >
> > I am not sure this is a security risk; could you expand on this?
> 
> What I meant was that a user could visit a page and unknowingly the 
> developer of that page could them put any other URL in there history, so 
> when they press the back button, instead of going to where they were 
> (where they expect and wanted to go) there sent to some gimmicky 
> marketing page for a product they don't want, or a porn site or who 
> knows where. This is my underlining concern with messing with the users 
> history, is how will it be abused and frustrate users?

But this is already possible.

Any attacker that wants to stuff another page in the history before their 
page can easily do so by making the initial landing page redirect to the 
page the user expected when first loaded, and redirect to the hostile page 
when the user goes back. As in:

   What user thinks happened:
   [Page A] *click* -> [Page B]

   What actually happened:
   [Page A] *click* -> [Page X] redirect -> [Page B]

When the user hits back, he lands on page X, not page A.

(The inserted page can effectively be any page at all, since it can simply 
redirect to another -- i.e. this problem always simplifies to the case 
where the attacker controls all the pages except the initial one.)


The question is, why would people want to do this? What does it get them?


> My concern with pushState is the lack of ability to bookmark pages, Ian 
> said: "Yeah, one of the suggestions being considered for pushState() is 
> the ability to also associate a URI with the state so that it can be 
> bookmarked." How would this work, would the browser have to keep the 
> object passed into pushState saved somewhere so when that URL was 
> visited again, it could be retrieved?

No, it would just pretend that the given URI was the URI of the page, as 
if the author had done location.replace() without actually changing the 
page, so that if the user bookmarked the page or copied the URI or 
whatever, it would get the new "fake" URI. (Obviously this would be 
limited to URIs on the same domain to avoid phishing attacks.)


> Wouldn't it be easier to save information in the URL itself in the query 
> string?

The actual state might be much more complicated than the state that the 
URI version keeps. For example, the URI version would maybe not keep the 
day's autocomplete history.

Imagine this scenario:

   User goes to Virtual Earth (MSN's mapping service).
   User does various searches, getting various items onto his Scratch Pad.
   User does a search, then thinks "hm no that was wrong" and hits back.
   User bookmarks that URI.
   User does various searches, getting various items onto his Scratch Pad.
   On another day, user visits the bookmark.

The scratch page shouldn't reset to what it was like when he bookmarked 
the URI. It should either be blank, if the scratch pad is per-session, or 
should have whatever it had before he visited the bookmark, if it is per- 
sistent. Thus, the URI shouldn't store the state of the scratch pad.

However, when the user hits back, the thing that got added to his scratch 
pad as a result of the search he skipped, _should_ get removed, since the 
user is effetively saying "oops, wrong way". Thus the data stored in the 
session history should keep track of what needs removing from the scratch 
pad, too.

The two, IMHO, are different.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 25 November 2005 20:10:33 UTC