13 July 2021

Updated:
19 July 2021: Added examples in "Potential risks for users", explanation of autofill type
27 July 2021: Edited disabling autofill for Firefox
31 July 2021: Added FAQ section, in the new version of Edge you can require a system password before filling in a saved password
27 April 2023: Script code refactoring, changed title from "turn off" to "disable"

Notes:
This article is not about manual autofill (clicking in UI), but about password managers that fill passwords without user interaction (or minimal - one click anywhere). XSS vulnerability can be anywhere on a domain, XSS on login page is not required.

Password managers are a very popular topic in IT security these days. I can only agree with the use of password managers. After all, remembering dozens of unique passwords is almost impossible.

However, it is often no longer mentioned that the autofill function should be disabled or be set to fill only upon user request. Rather, this feature is more often described as a useful feature to ensure a convenient and "secure" login. Yes, it is convenient, but for loss of security.

Most password managers have the autofill feature enabled by default, even though it reduces the security of the stored password.

If a user uses the default configuration or follows the password manager's recommendation, it is possible to steal the saved login credentials from 11 of the 16 tested browsers and password managers in one mouse click. So the database/password on the website doesn't have to be leaked, and the attacker still gets your data - all in readable and unencrypted form (in plaintext).

Autofill can be 2 types: automatic autofill (autofilling a password without user interaction) and manual autofill (autofilling a password after some user interaction - clicking in the password manager's UI). In the following article, the term autofill always means automatic autofill.

Table of contents:

• Autofill
• Autofill in chromium-based browsers
• Abuse of the autofill? Cross-Site Scripting (XSS)
• Analysis of browsers and password managers
• Limitation
• Script and demo
• Clickjacking KeePassXC-Browser
• Potential risks for users
• Potential risks for companies / Recommendation for InfoSec
• Recommendation
• Conclusion
• FAQ

Autofill

As the name says, this feature ensures that the password managers automatically fill in the login form. The data is pre-filled only for domains where data has been stored.

The behaviour of the autofill depends on many factors. In addition to the domain, the protocol used (http/https), form attributes, and element IDs and names are also checked.

From a security point of view, this feature can be used to verify that users are not on a phishing site. If they were on it, the data would not be automatically filled in. Users might notice unusual behaviour and could check what domain they are currently on.

In addition to "verifying" the phishing site, this is more of a convenience login feature, as the user does not have to click anywhere and has everything pre-filled. However, pre-filled data is a problem because all data is in a readable form (plaintext) and can be accessed with javascript.

Autofill in chromium-based browsers

For chromium-based browsers (except Brave browser), the autofill feature works a bit differently than, for example, Firefox or regular password managers.

In these browsers, the data is filled in automatically at first view, but this is not true. The data in the form is not really filled in. It is only filled in when the user interacts with the website.

The user interaction must be of type isTrusted (=> triggered by the user) with an event such as a keystroke or mouse click. Mouseover, mousemove and similarly "simpler" events do not perform full autofill. If the content of the input is displayed without prior user interaction with the website, only a empty value will be displayed.

To demonstrate, I have created a script that displays the contents of the values in the form after 5 seconds.

<form action="/example.html">
      <label for="username">Username</label><br>
      <input type="text" id="username" name="username"> <br>
      <label for="psw">Password</label><br>
      <input type="password" id="password" name="password"><br><br>
      <input type="submit" value="Submit">
</form>

<script>
window.setTimeout(function(){
       var username = document.getElementById("username").value;
       var password = document.getElementById("password").value;

       alert(username+":"+password);
}, 5000);
</script>    

You can see how autofill works in chromium-based browsers in the following animations:

So the attacker must somehow trick the user into clicking somewhere on the website. In the role of the attacker, I would probably display a notification or cookie dialog. Both types of elements are displayed quite frequently on the sites, so the victim will not suspect suspicious activity.

The goal is not for the victim to click somewhere exactly, but for a click to be made. Displaying an element that makes browsing the site uncomfortable, and which requires interacting with the site to remove, is, in my opinion, a very effective way to get the required click from the user.

Abuse of the autofill? Cross-Site Scripting (XSS)

XSS is the most common web vulnerability. If a web page has this type of vulnerability, it is possible to inject javascript code into the page. The injected code will then perform an action defined by the attacker, such as stealing login credentials.

There are several ways to steal user login credentials using XSS. Someone could think of capturing the values entered to the login form or changing form action value (=address where the data will be sent). Then I have a few questions:

• What if the XSS vulnerability is not on the same page as the login form?
• What if the user is already logged in and therefore the login form is not available?

The answer could be that a completely new login form would be displayed to the user. Ideally still with a change of frontend to make it look like he is logged out.

Yes, it could probably work, but with this method I would have to rely on the victim re-entering their credentials. But what if the user doesn't fill out the new login form?

I'm not a fan of complicated interactions from the victim. If I want more than 2 normal mouse clicks from a user, I'm requesting too much and I'm thinking of a different solution. Among other things, if I ask the user to log in again (re-enter credentials), at that point it's primarily based on social engineering.

My approach would be to abuse the autofill feature that password managers have. If I know about the XSS vulnerability, I will use javascript to create a new login form that will be completely hidden to the user. The password manager will detect the presence of this form and will auto-fill the data into it. So the goal would be to take advantage of a misconfiguration in the password manager in use.

Advantages:

• The attack is happening in the background
• None or minimal additional interaction from the victim - 1 click
• XSS vulnerability can be anywhere on the domain, for some password managers even a subdomain is enough
• User can be logged in or logged out

Limitations:

• User must have a stored password for the domain
• Victim must have enabled automatic autofill in password manager
• Password manager must not be locked/logged out

Differences in victim interactions between "XSS fake login screen" and "XSS hidden login form":

XSS fake login screen:
click to username/email input, fill username/email, click to password input, fill password = 4 interactions

XSS hidden login form:
load website = 0-1 interactions (maximally 1 click or keystroke)

For more information see FAQ section

Analysis of browsers and password managers

As part of the analysis, I focused on the most used browsers and password managers. For password managers, only browser extensions were tested and everything was verified in the desktop-only version (especially Google Chrome). So on mobile phones the behaviour may be completely different.

Tested browsers and password managers:

Google Chrome 91.0.4472.124 - https://www.google.com/chrome
Mozilla Firefox 89.0.2 - https://www.mozilla.org
Safari 14.1.1 - https://www.apple.com/safari
Microsoft Edge 91.0.864.64 - https://www.microsoft.com/edge
Opera 77.0.4054.172 - https://www.opera.com
Internet Explorer 11 - https://www.microsoft.com/internetexplorer
Brave 1.26.74 - https://brave.com
Vivaldi 4.0.2312.36 - https://vivaldi.com

LastPass 4.75.0 - https://chrome.google.com/webstore/detail/hdokiejnpimakedhajhdlcegeplioahd
1Password 2.0.4 - https://chrome.google.com/webstore/detail/aeblfdkhhhdcdjpifhhbdiojplfjncoa
Bitwarden 1.51.0 - https://chrome.google.com/webstore/detail/nngceckbapebfimnlniiiahkandclblb
Dashlane 6.2123.1 - https://chrome.google.com/webstore/detail/fdjamakpfbbddfjaooikfcpapjohcfmg
Roboform 9.2.3.0 - https://chrome.google.com/webstore/detail/pnlccmojcmeohlpggmfnbbiapkmbliob
Keeper 15.3.5 - https://chrome.google.com/webstore/detail/bfogiafebfohielmmehodmfbbebbbpei
KeePassXC-Browser 1.7.8.1 - https://chrome.google.com/webstore/detail/oboonakemofpalcgghocfoadofidjkkk
Sticky Password 8.3.1.3 - https://chrome.google.com/webstore/detail/bnfdmghkeppfadphbnkjcicejfepnbfes

1) Browsers and password managers in default configuration