Re: [whatwg] "first script" and impersonating other pages - pushState(url)
Justin Lebar wrote: > Mike Wilson wrote: > > The result is that the address bar URL can't be trusted, as > > any page on the site can impersonate any other without > > consent from that page or part of the site? > > Someone will correct me if I'm wrong, but I think this is already > pretty much the case with today's same-origin policy, albeit with a > bit more work. My understanding is that if A and B have the same > origin, they can do whatever they want to each others' documents, > including modifying content. So if you can control script at > http://google.com/~mwilson , and a user has both your site and > http://google.com/securesite , then your malicious page can do > whatever it wants to the secure page. > > That's why it's important that you trust all the javascript which runs > on your origin. Ian Hickson wrote: > The Web has a same-origin security model. If you're sharing > one origin between two untrusted authors, you've already lost. > > For example, today you could already do what you describe -- just use > window.open() to open the topclientsonly/login page, and then inject > script to grab the password. Yes of course, should have thought about that :-P. As you say, it is trivial to add a frame that displays the victim page and then patch it to my needs. Well, if there will ever be a path-based security mechanism (as suggested in my other thread) I guess it could apply to pushState as well. Thanks Mike
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
Mike Wilson wrote: > The result is that the address bar URL can't be trusted, as > any page on the site can impersonate any other without > consent from that page or part of the site? Someone will correct me if I'm wrong, but I think this is already pretty much the case with today's same-origin policy, albeit with a bit more work. My understanding is that if A and B have the same origin, they can do whatever they want to each others' documents, including modifying content. So if you can control script at http://google.com/~mwilson , and a user has both your site and http://google.com/securesite , then your malicious page can do whatever it wants to the secure page. That's why it's important that you trust all the javascript which runs on your origin. -Justin
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
On Fri, 4 Sep 2009, Mike Wilson wrote: > > Let's say that I have rights to post to a blog on: > www.corporatesite.com/fan/blog > Assuming I can get some JavaScript inside one of my blog > posts, I can then pretend I am redirecting the user to: > www.corporatesite.com/topclientsonly/login > while I am really impersonating that page through pushState > and harvesting their passwords. The Web has a same-origin security model. If you're sharing one origin between two untrusted authors, you've already lost. For example, today you could already do what you describe -- just use window.open() to open the topclientsonly/login page, and then inject script to grab the password. > The result is that the address bar URL can't be trusted, as any page on > the site can impersonate any other without consent from that page or > part of the site? That's already the case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
Ian Hickson wrote: > > On Thu, 3 Sep 2009, Mike Wilson wrote: > > > > - calling pushState(..., "/pages/section1/thing2") when > > first script's basedir=/pages/section1 will be ok > > > > - calling pushState(..., "/pages/section2/thing2") when > > first script's basedir=/pages/section1 will not be > > allowed (and throw). > > > > Is any of these wrong? > > The path part of the URL is ignored when deciding whether or > not to allow the call. Rereading the spec again I see that. Sorry, my bad :-S I see now that the first script's url is only used to keep pushState on the same origin, while I was expecting it to keep pushState urls on the same "sub branch" path. But doesn't this open up a fairly bad security exploit? Let's say that I have rights to post to a blog on: www.corporatesite.com/fan/blog Assuming I can get some JavaScript inside one of my blog posts, I can then pretend I am redirecting the user to: www.corporatesite.com/topclientsonly/login while I am really impersonating that page through pushState and harvesting their passwords. The result is that the address bar URL can't be trusted, as any page on the site can impersonate any other without consent from that page or part of the site? Best regards Mike
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
On Thu, 3 Sep 2009, Mike Wilson wrote: > > - calling pushState(..., "/pages/section1/thing2") when > first script's basedir=/pages/section1 will be ok > > - calling pushState(..., "/pages/section2/thing2") when > first script's basedir=/pages/section1 will not be > allowed (and throw). > > Is any of these wrong? The path part of the URL is ignored when deciding whether or not to allow the call. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
Ian Hickson wrote: > > On Mon, 31 Aug 2009, Mike Wilson wrote: > > > > Ian Hickson wrote: > > > > > > On Fri, 21 Aug 2009, Mike Wilson wrote: > > > > > > > > [...] > > > > Imagine that I want my loaded page: > > > > /pages/section1/thing1 > > > > be able to impersonate: > > > > /pages/section2/thing2 > > > > how do you envision this to be structured? > > > > > > > > Something like this? : > > > > > > > > /pages/section1/thing1: > > > >
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
On Mon, 31 Aug 2009, Mike Wilson wrote: > Ian Hickson wrote: > > On Fri, 21 Aug 2009, Mike Wilson wrote: > > > > > > I'm currently wrapping my head around the notion of > > > "first script" in the spec [1]. It's description is > > > a bit terse and the subject seems non-trivial, so > > > maybe the text could be fleshed out some? > > > > > > Section 6.1.5 "Groupings of browsing contexts" > > > says: > > > | Each unit of related similar-origin browsing > > > | contexts can have a first script which is used to > > > | obtain, amongst other things, the script's base > > > | URL to resolve relative URLs used in scripts > > > | running in that unit of related similar-origin > > > | browsing contexts. Initially, there is no first > > > | script. > > > > > > Does this implicitly say that this set of browsing > > > contexts should never execute script in parallel? > > > > No, that is implied by the event loop mechanism. > > > >http://www.whatwg.org/specs/web-apps/current-work/#event-loops > > Ah thanks, that made it clear. 6.1.5 might get a little easier to > understand if some text mentioned the shared event loop for this set of > browsing contexts, or linked to 6.5.4. Done. > > > /pages/page1.html: > > >
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
Ian Hickson wrote: > > On Fri, 21 Aug 2009, Mike Wilson wrote: > > > > I'm currently wrapping my head around the notion of > > "first script" in the spec [1]. It's description is > > a bit terse and the subject seems non-trivial, so > > maybe the text could be fleshed out some? > > > > Section 6.1.5 "Groupings of browsing contexts" > > says: > > | Each unit of related similar-origin browsing > > | contexts can have a first script which is used to > > | obtain, amongst other things, the script's base > > | URL to resolve relative URLs used in scripts > > | running in that unit of related similar-origin > > | browsing contexts. Initially, there is no first > > | script. > > > > Does this implicitly say that this set of browsing > > contexts should never execute script in parallel? > > No, that is implied by the event loop mechanism. > >http://www.whatwg.org/specs/web-apps/current-work/#event-loops Ah thanks, that made it clear. 6.1.5 might get a little easier to understand if some text mentioned the shared event loop for this set of browsing contexts, or linked to 6.5.4. > > /pages/page1.html: > >
Re: [whatwg] "first script" and impersonating other pages - pushState(url)
On Fri, 21 Aug 2009, Mike Wilson wrote: > > I'm currently wrapping my head around the notion of "first script" in > the spec [1]. It's description is a bit terse and the subject seems > non-trivial, so maybe the text could be fleshed out some? > > Section 6.1.5 "Groupings of browsing contexts" says: > | Each unit of related similar-origin browsing > | contexts can have a first script which is used to > | obtain, amongst other things, the script's base > | URL to resolve relative URLs used in scripts > | running in that unit of related similar-origin > | browsing contexts. Initially, there is no first > | script. > > Ok, so a *unit of related similar-origin browsing contexts* has one > shared first script. > > Does this implicitly say that this set of browsing contexts should never > execute script in parallel? (= mutually exclusive code execution, so one > hang will hang them all) No, that is implied by the event loop mechanism. http://www.whatwg.org/specs/web-apps/current-work/#event-loops > Section 6.5.3.2 "Calling scripts" says: > | When a user agent is to jump to a code entry-point > | for a script, for example to invoke an event > | listener defined in that script, the user agent > | must run the following steps: > | [...] > | 2. Set the first script to be the script being > |invoked. > > Example: > > /pages/page1.html: >
