55
edits
The autocomplete attribute and web documents using XHTML: Difference between revisions
Jump to navigation
Jump to search
The autocomplete attribute and web documents using XHTML (view source)
Revision as of 11:22, 5 August 2006
, 5 August 2006→Background
| Line 6: | Line 6: | ||
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]). | 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]). | ||
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]). | ||
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 (e.g. ELinks has form history but does not recognize the attribute), <code>autocomplete</code> is here to stay. | In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support (e.g. ELinks has form history but does not recognize the attribute), <code>autocomplete</code> is here to stay. | ||
== The Problem == | == The Problem == | ||