Fix BWN-01-001

Posting in Feature Requests as opposed to bugs as no action is currently planned and I’d like to request this be reconsidered. I have read the justification from the report as below and and have a couple of thoughts on this response.

Due to the nature of how autofill is expected to work, users should be able to log into services where embedded iframes from another domain are present. If a website is embedding a malicious iframe from another domain, we can assume that website (or device) is already in a compromised state and that efforts from Bitwarden to try to mitigate the leaking of credentials for that website would likely not help. Additionally, by default Bitwarden does not autofill information without a user’s consent.

It is understandable that a user would expect autofill to work for an iframe, however I would expect it to fill in the password for the site in the frame. As example of this would be a website that for its login embeds a single-sign-on page for a company (such as iCloud and Apple) - I would expect that my password saved under Apple would be the one filled without me having to re-save it as iCloud in my vault. My understanding of the bug reported is that this behaviour would be more secure and close the issue.

The workflow for a user that expects autofill to work on these pages would be no different, simply prompt the user with a ‘Would you like to save this password’ page for the iframe address on first successful login and use this to fill the iframe or the url it embeds in the future. This would be just as user friendly (a slight inconvenience for existing users admittedly) and substantially more secure.

An alternative option is to bring up a popup on attempted autofill to avoid this issue. Something to the likes of ‘iCloud.com is attempting to use your login credentials on Apple.com, would you like to continue?’ - optionally with a ‘Don’t ask me again’ button that would add Apple.com as a second URL for the iCloud entry.

Thanks for your time and hard work in creating what is an amazing product, I hope you’ll consider the community reaction on this subject and consider if changing this behaviour as recommended in the audit.

Definitely agree, a simple warning message as you discribed would alreaddy increase protection against phishing attempts in hijacked iframes a lot

Another vote for this. iFrame examples like detailed above can lead to Bitwarden suggesting the wrong credential even if you ignore the possible compromise issue.

Additionally the rationale around the risk of compromise is somewhat flawed. While it is true that the compromise of the toplevel website cannot be designed against, it is possible for the iframe website to be compromised and in that case the toplevel credential is now exposed to an attacker.

I’m in the same situation on a daily basis.
A Dutch educational publisher offers its online materials through base domain: noordhoff.nl.
The login for this educational website is tunneled through an iframe with a different base domain: toegang.nu.
I’ve included both URI’s to the login item, as well as custom fields for the Username and Password.

When I open the webpage, the Bitwarden browser extension shows (1) indicating it has recognized the website for which it has a login item in the vault.
Pressing ctrl-shift-L however does not autofill the fields.
I need to go through the process of clicking the BW-extension item and selecting the item for auto-fill or RMB-click and navigate the context menu.

[Edit] Additional information: If I open the iframe in a separate tab, ctrl-shift-L does work and autofills the fields. This is no work around, because it doesn’t take further with the original website.