On many penetration test reports (including mine), the following is reported:

Password Field With Autocomplete Enabled

The page contains a form with the following action URL:

https://rob-sec-1.com/blog/autocomplete.php

The form contains the following password field with autocomplete enabled:

password

Issue background

Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications that employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application. The stored credentials can be captured by an attacker that gains control over the user’s computer. Further, an attacker that finds a separate application vulnerability such as cross-site scripting may be able to exploit this to retrieve a user’s browser-stored credentials.

Issue remediation

To prevent browsers from storing credentials entered into HTML forms, include the attribute autocomplete=”off” within the FORM tag (to protect all form fields) or within the relevant INPUT tags (to protect specific individual fields). Please note that modern web browsers may ignore this directive. In spite of this there is a chance that not disabling autocomplete may cause problems obtaining PCI compliance.


Now this one is an awkward one to report, because saving passwords for the user is a good thing. MDN says on the matter:

in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.

I completely agree with this. Password managers (even browser built-in ones) are better than using the same passwords across all sites, or subtle variations on one (monkey1Facebook, monkey1Twitter, etc.).

Users should have their local devices protected (by this I mean mobile devices and desktop machines). This means a password, PIN or fingerprint or equivalent to login, and encryption enabled (FDE, like BitLocker, or device enabled, like Android encryption), to prevent anything being extracted from the file system.

Therefore, the browser storing the password for the use of the user, is of very little risk. The main risk here, is what the Burp description of the vulnerability touches upon above:

cross-site scripting [XSS] may be able to exploit this to retrieve a user’s browser-stored credentials.

Yikes! So XSS could grab the credentials from your browser. To find out whether your browser is vulnerable, I’ve setup a test.

Login to your password manager, click the following link and then enter username: admin and password: secretPassword and when your browser asks you to save your password, do it. Go!

Then try the next link preloaded with this juicy XSS payload

<script>
document.body.onload=setTimeout(
function() {
    alert(document.getElementById('password').value)
    }
    ,1000)
</script>

The one second delay is to give the browser time to complete the form. However, this can be altered with the delay parameter in case your browser needs longer.

Test

So if an alert box is shown with your password, your browser or password manager is vulnerable. In a real attack there will be no alert box, the attacker sends the password (and of course, username using the same method) cross-domain to their site like this (open dev tools or Burp to see the background request).

The next link has autocomplete off. There are two tests you can do here.

  1. Find out whether your password is still completed from before. Many modern browsers ignore the autocomplete directive.
  2. Don’t do this test yet, but if you try a new login (e.g. root and pass), see whether your browser prompts you to save.

Autocomplete Off

The second test may prevent your browser from auto-filling anything in future on this domain without you manually clicking (as you now have two possible logins to the site). Delete one of the logins from your browser/manager if you tried this test.

If your browser still autocompletes, this shows that setting autocomplete=off is pretty pointless for users with the same browser and password manager combination.

Attacker Injected Form

If autocomplete=off made a difference to the above, then the point of my post is to show you whether an attacker injected form could re-enable autocomplete and then capture your credentials, should a cross-site scripting vulnerability exist on the site, and that you were unlucky enough to follow an attacker controlled link.

Before starting, make sure you only have one login saved. See the following guide on how to delete passwords if you tried the second test above. Click this link then your browser version and click back to return to this site: How to delete passwords.

This one has autocomplete off, however, an attacker injects their own form tag via the XSS vector, with autocomplete on to try and grab the password from it:

Attacker Injected Form

This works by closing the original form in the HTML, and then opening another one without autocomplete disabled before injecting the script:

</form><form><script...

If this test worked, but the second test didn’t, then removing autocomplete from a form is like closing the stable door after the horse has bolted. The password has already been saved and any future XSS attacks can grab their password.

Firefox 61, Edge 42 and IE 11 appear to be vulnerable, so if you have cross-site scripting on your site and a user has saved passwords, then the attacker can trivially grab the login details should their XSS link be followed. Chrome 67 appears to pre-fill the password, however, the script alert is empty, suggesting that Chrome has some clever logic built-in preventing script from retrieving it. I wonder if there’s a way around this for an attacker…? Maybe an idea for a future post.

The solution to this would be to use a password manager that requires the user to click before completing the password. This would stop a cross-site scripting attack from sending the password to the user automatically. Of course, if the user proceeded to login, the cross-site scripting could have attached an event handler to the password field in order to send once it had been entered. Changing your password manager will guard against completely automated attacks that do not require further user interaction.

So to avoid being a victim yourself:

  • If the “attacker injected form” test gets your password, switch to a password manager that requires you to click before completing your login details.
  • For sensitive sites, bookmark the logon page and always follow your bookmark when logging in, never follow links from emails, other sites or from messages.

From a pentesting perspective it looks like we’re stuck reporting it, especially for PCI tests:

there is a chance that not disabling autocomplete may cause problems obtaining PCI compliance.

So to sum up, password managers are great and increase overall security. However, if they complete forms without asking, they make an attacker’s work easy.