Re: [XHR] security issue with spec's same-origin and the Document pointer
On Sun, 23 Nov 2008 22:32:02 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. Once you navigate the original Document is either destroyed or stays around. However, it does not suddenly change into the Document of another domain. The point is that there *is* no document pointer until you call the constructur - per the spec. And once that script calls the constructor and the document pointer is created, the associated window has a different document in it from a different origin. Hence the document pointer will reference a document from a different origin than the script itself has, and same-origin comparisons will pass when they should fail and vice versa. If you still don't get it please read carefully because I don't know how to explain it clearer than that :-p. Besides, I'm on vacation and will try not to read E-mail ;) -- Hallvord R. M. Steen Core JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Mon, 24 Nov 2008, Hallvord R. M. Steen wrote: The point is that there *is* no document pointer until you call the constructur - per the spec. And once that script calls the constructor and the document pointer is created, the associated window has a different document in it from a different origin. Hence the document pointer will reference a document from a different origin than the script itself has, and same-origin comparisons will pass when they should fail and vice versa. Valid point; the XHR spec should use the script document context as the Document instead. Warning though, this part of the HTML5 spec is definitely unstable. http://www.whatwg.org/specs/web-apps/current-work/#script-document-context -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. If the script goes on to request content from this domain, the same-origin comparison against the document pointer would pass when it should in fact fail because the script itself is from a different origin. -- Hallvord R. M. Steen Core JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Sun, 23 Nov 2008 18:13:41 +0100, Hallvord R. M. Steen [EMAIL PROTECTED] wrote: On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. If the script goes on to request content from this domain, the same-origin comparison against the document pointer would pass when it should in fact fail because the script itself is from a different origin. Once you navigate the original Document is either destroyed or stays around. However, it does not suddenly change into the Document of another domain. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[XHR] security issue with spec's same-origin and the Document pointer
http://www.w3.org/TR/XMLHttpRequest/#document-pointer says When the XMLHttpRequest() constructor is invoked a persistent pointer to the associated Document object is stored on the newly created object. This is the Document pointer. The associated Document object is the one returned by the document attribute from the object on which the XMLHttpRequest() constructor was invoked (a Window object). The pointer can become null if the object is destroyed. http://www.w3.org/TR/XMLHttpRequest/#open , point 11 says If stored url is not of the same-origin as the origin of the Document pointerthe user agent should raise a SECURITY_ERR exception and terminate these steps. When the XMLHttpRequest() constructor is *invoked*, the window.document property might point to a document from a different origin. For example, given a document with an iframe from the same origin and a script that does var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. (I tested this scenario with to-same-origin and to-different-origin redirects - i.e. not quite what the sample code above does but it should be equivalent. IE 8 throws on invoking the constructor if the document has changed - even if the new document is from the same origin. Firefox, Opera and Safari allow requests if the new document is same-origin but not if it's from a different origin. Spec-wise, requiring what IE does seems safer - perhaps what happens is that the variable refers to the actual window.XMLHttpRequest object and that object is destroyed by navigation. Keeping a pointer to an associated original window location with a random variable that happens to point to an XHR constructor would be very non-ECMAScript-y, at least according to my gut feeling. Given that I don't know how one could spec what the other browsers do..). -- Hallvord R. M. Steen Core JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Fri, 21 Nov 2008 17:28:34 +0100, Hallvord R. M. Steen [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
