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

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

--- Comment #4 from Simon <simon.young90@live.com> 2011-04-11 22:48:47 UTC ---
Thank you both for your responses, I do agree; the attack vector for this
exploit is the same as conventional XSS attacks. However, I think there are a
few differences you might have overlooked with this method:

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. 

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.

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.
i.e. This will not work:

window.parent.document.write("XSS!");

The slave could also be instructed to make seemingly legitimate requests as if
it were the compromised domain, such as an XMLHTTPRequest and then pass the
results to the external site. If the external site then modified these results
so that all links in the new page were also XMLHTTPRequests to be passed back
to itself, this type of XSS could be used as a full man-in-the-middle attack.

Thanks again,

Simon Young

-- 
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 Monday, 11 April 2011 22:48:49 UTC