Re: [whatwg] Small ddition to 7.4.2.1, postMessage's security considerations for authors

2009-04-26 Thread Ian Hickson
On Sat, 14 Feb 2009, Jeff Walden wrote:
>
> The spec should mention that even after MessageEvent.origin's value has 
> been checked, MessageEvent.data should also be checked for structural 
> correctness, because if the target window contains an XSS hole, improper 
> validation of incoming messages could result in the target window's XSS 
> hole being propagated into the sender's window as well.
> 
> For example, consider a site A which requests a particular string of 
> JSON data from site B, which it then parses into an object using eval().  
> If site B is subvertible, the response JSON string may instead be 
> arbitrary script which would be executed by site A *as* site A's code.  
> Proper validation by site A would mean checking that the sent string 
> actually is JSON and not arbitrary syntactically-correct JavaScript.
> 
> (Ignore the fact that the site shouldn't be unserializing JSON data 
> using eval(), and further ignore that structured data-passing makes this 
> particular use obsolescent.  Other instances of contamination may be 
> possible depending on the sent data and its structure, and this was just 
> the simplest example to explain.)

Done.

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


[whatwg] Small ddition to 7.4.2.1, postMessage's security considerations for authors

2009-02-14 Thread Jeff Walden

The spec should mention that even after MessageEvent.origin's value has been 
checked, MessageEvent.data should also be checked for structural correctness, 
because if the target window contains an XSS hole, improper validation of 
incoming messages could result in the target window's XSS hole being propagated 
into the sender's window as well.

For example, consider a site A which requests a particular string of JSON data 
from site B, which it then parses into an object using eval().  If site B is 
subvertible, the response JSON string may instead be arbitrary script which 
would be executed by site A *as* site A's code.  Proper validation by site A 
would mean checking that the sent string actually is JSON and not arbitrary 
syntactically-correct JavaScript.

(Ignore the fact that the site shouldn't be unserializing JSON data using 
eval(), and further ignore that structured data-passing makes this particular 
use obsolescent.  Other instances of contamination may be possible depending on 
the sent data and its structure, and this was just the simplest example to 
explain.)

Jeff