- From: <bugzilla@jessica.w3.org>
- Date: Thu, 29 Apr 2010 08:33:12 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9602 --- Comment #5 from Lachlan Hunt <lachlan.hunt@lachy.id.au> 2010-04-29 08:33:51 --- (In reply to comment #4) > Lachlan, maybe it's a good idea to read the description once more. My PoC > doesn't use JavaScript at all. Yours does. World of difference here, because > many people block JavaScript as a security measure. I know, that was my point. I was showing how exactly the same issue can be replicated with JavaScript, to illustrate the fact that there is no significant new attack vector created by autofocus. Most people don't block JavaScript. The insignificant portion who do have no impact on the overall effectiveness of such an easily circumvented attack. > Due to iframe overlapping (try only iframe overlapping in Firefox to see what > happens) the iframe beneath the original trusted one gets focused, you will > notice if you reconstruct it carefully, that there will be no apparent > difference, because the focus appears to be set in first iframe, but it > actually gets set to the 2nd iframe beneath, tricking a unsuspecting user to > enter a password or other sensitive data for example. How do you propose that an iframe with untrusted content will be able to position itself beneath another trusted iframe? Unless the parent page itself is complicit with the attack or at least the victim of XSS, in which case the whole site is effectively untrustworthy. Also, even if an untrustworthy page were loaded in an iframe, then the parent site could include the sandbox attribute which will completely disable the effect of autofocus. e.g. <iframe src="http://untrusted.example/" sandbox></iframe> -- 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 Thursday, 29 April 2010 08:33:56 UTC