[Bug 9602] That autofocus attribute will wreak security havok. What an ignorant idea to bring more logic to HTML. I think I know a couple of ways to abuse it, since it actually is some sort of flow control, which only scripting languages should be capable of. I hope

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





--- Comment #6 from Skyphire <sasha@scarletred.nl>  2010-04-29 10:22:26 ---
> 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.

As I also said it was known, the difference was a script-less vector. So you
essentially, autofocus brings scripting to HTML. You bet I am worried. It is
for a very good reason the two should be separated, since HTML is and SHOULD be
merely structural semantics. Even this argument makes enough sense, in my
opinion, to be worried. Setting a focus to a button goes completely against all
my logic.

> 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.

The idea that this is possible in the first place should be raising eyebrows. I
proposed a couple of vectors that could be used to stack attacks regardless if
the end-user has JavaScript enabled. There are plenty of cases where this can
lead to a compromise. It isn't a vulnerability in itself, (just like enabling
Telnet on your host isn't a vulnerability in itself) but it enables unwanted
control that COULD lead to unexpected results. I haven't figured out a way to
do it fully automatic (without a single key-stroke) but if it is possible, it
essentially means even HTML can be used for malicious ends. Surely this isn't
expected behavior, is it?

> 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>


The parent site could do that, but I rather see that browser vendors disable
autofocus on embedded frames, like iframes. I see no reason why an Iframe
should be allowed to transfer focus over it's document through this HTML
"feature". It has nothing to do with semantics at all. Scripting languages
-like JavaScript, LiveScript- were invented for this task. So to me this is a
caution of what's in store. Because how is an end-user to know that a
combination of these attacks can lead to some sort of compromise without his
consent? HTML5 brings new features and a lot of them are very useful, but I see
absolutely no point in giving HTML the power to control even more flow. HTML4
brought enough control flow into existence too through the FOR attribute. And
yes, browser happily accept this. 

Example:

<!-- bubble all flow control towards the button through a label (including body
clicks!) -->

<label for="submit">

  <body>

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque faucibus 
condimentum dui, nec suscipit nibh pulvinar quis. Mauris feugiat vulputate
neque
 sed malesuada. Nam nec nibh id neque tristique fermentum. Maecenas dignissim
mi
 nec libero ullamcorper sed imperdiet nisi vestibulum. Morbi iaculis risus id 
nulla pulvinar pharetra.

<form action="192.168.1.2/yourvulnrouter.html" method="post">
<input type="submit" id="submit" style="display:none;">
<input type="hidden" name="CMD" value="some command the router listens for">
</form>

  </body>

</label>

I'm curious about the motivation behind this design decision too. I think it's
pointless to marginalize risks in favor of features which HTML should not be
capable of at all. Maybe it's me, but I have suspicion it isn't w3 who dropped
the ball here, but rather the WHATWG group, who interestingly enough consists
of major browser vendors. So, is autofocus what the browser vendors want to be
implemented? or is it what the end-user actually want or don't want? From an
end-user standpoint like myself, HTML should never enable/disable nor control
the flow of control unless the end-user specifies to do so, like for instance
disabling scripting to prevent unwanted modifications, malicious or not. 

-Skyphire

-- 
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 10:22:29 UTC