And the Web it keeps Changing: Recent security relevant changes to Browsers and HTML/HTTP Standards

Published: 2014-05-06
Last Updated: 2014-05-06 12:24:37 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

As we all know, web standards are only leaving "draft" status once they start becoming irrelevant. It is a constant challenge to keep up with how web browsers interpret standards and how the standards themselves keep changing. We are just going through one of the perpetual updates for our "Defending Web Applications" class, and I got reminded again about some of the changes we had to make over the last year or so.

Autocomplete=Off

This weekend we just had yet another post about people picking bad passwords. The only real way around this problem is a password manager. For a long time, browsers included features to allow you to save passwords. But historically, these features were not liked very well as they tended to protect the password inadequately. But with the number of leaked passwords going up and up, and browser makers feeling more confident about their built in password safe features, some browsers started to ignore this setting. For example recent versions of Chrome and Safari will offer saving your password no matter if the "autocomplete=off" attribute is set or not.

BTW: You may still need to keep your autocomplete=off attribute in your forms to pass the PCI audit. After all, in this case you are not defending against hackers but against auditors and the attribute still works great to fend of auditor questions.

In the end, this means it is up to the user to decide to enable or disable this feature, and what password safe to use. Personally I don't think you can do without a password safe. But some people still think they can remember > 100 random passwords/passphrases. (I am having a hard time with one or two).

Cookie2 Headers

"nobody" ever really used the Cookie2 header. It was supposed to address privacy concerns people had with regular cookies. Cookies set via the Cookie2 header are essentially session cookies. They can not be set "cross domain" and they expire as soon as you close the browser. But that was back in the day when people still considered privacy as something attainable. RFC 6265 officially obsoletes Cookie2 back in 2011. I guess nobody noticed (me neither) because nobody uses it.

URL Bars

Another "good old days" feature of many browsers was URL bars. They are slowly disappearing. The simple reason is that most users (no... you are not "most users" as you are reading this post) have no idea what a URL is or how to decipher it. It all started with mobile browsers who pushed the URL off the screen as soon as possible to save the few mega pixels it would take to render the URL bar. I think it was Internet Explorer 8 where I first noticed that the URL bar got squished into a corner in order to provide more space for the search bar. Google now is tying to make this change more official by only showing the hostname, not the full URL, in recent beta releases of Chrome. The idea here is that the hostname is what matters and the other parts of the URL are usually just used by phishers to confuse the user as to the actual location of the page.

Anything I missed? Not looking for brand new features like HTTP/2.0 but for old features that no longer work in new browsers and are somewhat security related. I may add a couple more items to this post or as a comment as I remember them.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
5 comment(s)

Comments

Interesting note about Autocomplete. In fact, Microsoft has officially removed support for it in IE11 (http://msdn.microsoft.com/en-us/library/ie/ms533486(v=vs.85).aspx) "As of Internet Explorer 11, the autocomplete property is no longer supported for input type=password fields."
So the behavior is always-on now?

BTW, do you have a specific reference for your PCI crack? If you're right then it would seem that you can't be PCI compliant using IE11+
IE 11 (like Safari and others) always allows the user to store the data. I don't think that would affect PCI compliance per se as the compliance verifies the web application, not the browser the user uses. I can see where an auditor may request a certain configuration for browsers used to access the site from the company that is being examined (the merchants computers, not the customer computers).

The PCI reference I have seen is section 3.2 that requires that some data can not be stored. The OWASP E-Commerce Payments guide mentions autocomplete in that context (https://www.owasp.org/index.php/Handling_E-Commerce_Payments) . The automcomplete part applies to the credit card and cvv2 number in this context. I don't think the PCI standard would require it for the password, but it is possible that it can be interpreted that way.

Personally, I was never a big fan of the requirement as there is still no HTML tag that prevents users from writing passwords on post-its, and as I mentioned above, how else are you going to remember them?
If you work for a government, defending against auditors is often more important than defending against attackers. Sad, but true.
I hope there will be a way for us abnormal users to turn this back on. I don't expect Microsoft to make it easy, but I would hope Google and the Mozilla Foundation would make it a checkbox in the preferences.
So Yahoo says "never mind" to the user DoNotTrack setting, and now the browsers outright ignore the site coding. So much for having any control from either side (like we ever did, but still...).

AutoComplete=Off is just a necessary evil in audit land, and I imagine few of the auditors at the big financials and others know that it doesn't make much difference. Autocomplete fields and "X-Frame-Options" headers were two of the prominent audit findings last year, usually NON-negotiable fixes even as silly as they are as 'vulnerability controllers'.

Diary Archives