55
edits
The autocomplete attribute and web documents using XHTML: Difference between revisions
Jump to navigation
Jump to search
m
The autocomplete attribute and web documents using XHTML (view source)
Revision as of 15:56, 9 August 2006
, 9 August 2006→Background
m (→Background) |
|||
| Line 13: | Line 13: | ||
<code>form</code> and text and password <code>input</code> elements of HTML 3.2 with an [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/autocomplete.asp <code>autocomplete</code> attribute] which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the <code>autocomplete</code> attribute ([http://devedge-temp.mozilla.org/viewsource/2003/form-autocompletion/index_en.html Netscape Devedge: How to Turn Off Form Autocompletion]). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them. | <code>form</code> and text and password <code>input</code> elements of HTML 3.2 with an [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/autocomplete.asp <code>autocomplete</code> attribute] which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the <code>autocomplete</code> attribute ([http://devedge-temp.mozilla.org/viewsource/2003/form-autocompletion/index_en.html Netscape Devedge: How to Turn Off Form Autocompletion]). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them. | ||
In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]). And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants. | In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]), or browsers like ELinks and OmniWeb that have form history and ignore the attribute entirely. And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants. | ||
I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]). | I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]). | ||
| Line 29: | Line 29: | ||
In 2004, Kevin Gibb's [http://www.google.com/webhp?complete=1&hl=en Google Suggest] found a new use for the <code>autocomplete</code> attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank <code>input</code> field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it. | In 2004, Kevin Gibb's [http://www.google.com/webhp?complete=1&hl=en Google Suggest] found a new use for the <code>autocomplete</code> attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank <code>input</code> field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it. | ||
In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support | In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support, <code>autocomplete</code> is here to stay. | ||
== The Problem == | == The Problem == | ||