[Bug 12469] Dynamic Cross-Site Scripting and Page Repainting

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12469

--- Comment #9 from Henri Sivonen <hsivonen@iki.fi> 2011-04-12 10:28:39 UTC ---
(In reply to comment #4)
> Firstly, the external site referenced to in the iFrame does not need to be a
> .js file, it can be any webpage format (html, xml, php etc...) providing a
> message listener is implemented. 

This isn't particularly interesting considering that your scenario requires an
inline script to be injected first. If all the attack code were packed into
that script, the attack would work without any external files at all.

> Secondly, this exploit conforms to the DOM same-origin policy because the
> external script/page is not included directly in the website (it’s in the
> iFrame), cross-site messaging is allowed and the injected code appears to be
> the normal construct of the page. In the case of a stored/persistent XSS attack
> this would make it invisible to browser-based XSS detection, such as those
> employed by IE and Safari.

Your scenario involves injecting a <script>, which is something XSS detectors
look for.

> Thirdly, the external page (within the iFrame) has full control of the
> compromised site because the injected code acts as its slave. Cross-domain
> control of an iFrames parent window in JavaScript was previously impossible.

The bootstrap <script> your scenario requires injecting already has full
control.

So the actual compromise happens when the bootstrap script gets injected. That
the bootstrap script could use cross-document messaging isn't particularly
interesting.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 12 April 2011 10:28:41 UTC