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)
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:
script src=/scripts/script1.js
*1 button onclick=func1();
/scripts/script1.js:
function func1() { ... }
*2 func1();
What is regarded as *first script* in these two
calls to func1() ?
*1: the implicitly generated event handler wrapper
in /pages/page1.html ?
*2: /scripts/script1.js
Yes.
[...]
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:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
Per *1 in the first example, wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
No, why?
--
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:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
[...] wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
No, why?
Because I was interpreting the following from the spec
and your previous mail:
- clicking the button will trigger the anonymous
event handler in /pages/section1/thing1 and will
result in activating a first script with
basedir=/pages/section1
- when the anonymous event handler calls into the
impersonate() function defined in /pages/script.js
the initial script (and basedir) remains as first
script and does not activate basedir=/pages
- 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?
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 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 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)
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)
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:
script src=/scripts/script1.js
*1 button onclick=func1();
/scripts/script1.js:
function func1() { ... }
*2 func1();
What is regarded as *first script* in these two
calls to func1() ?
*1: the implicitly generated event handler wrapper
in /pages/page1.html ?
*2: /scripts/script1.js
Yes.
[...]
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:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
Per *1 in the first example, wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
Best regards
Mike
