Hi, maybe I’m missing something, but I did a test of what was reported in the first link: bitwarden did not autofill either the 4th or the 5th link, even with autofill enabled on page loading
In the linked Google security research, they notate Bitwarden has a fix bitwarden/clients#3860 which has already been merged.
Direct from the article
Both Dashlane and Bitwarden have updated their software although Dashlane, at least, remains unconvinced that the bug represents any kind of security threat.
Hence why in testing this is no longer an issue, thanks for bringing this up though
Spoiler Alert: As demonstrated by the ability of Steve Englehardt’s demo site to “sniff” your login credentials, cross-site scripting can still be used to steal credentials that are auto-filled into invisible forms. The patched security vulnerability only prevents auto-filling from occurring when forms are located on pages that have a CSP sandbox response header or that are located inside sandboxed iframes.
If anybody with the requisite technical expertise (e.g., @mgibson) would be willing to provide a technical explanation of what difference this recent patch makes in the context of the more general XSS vulnerability (which apparently still exists), I would be much obliged.
Frankly, not sure, that I understand why this case poses a security risk for the password manager’s browser extension. Web pages with CSP sandbox property have got even stronger protection against scam activity and what are connections between this CSP directive and security restrictions that are imposed on in-browser password managers. The research also mentions that such web pages are always classified as untrusted, it’s also unclear… Thank you in advance.
Btw, from what I can see, the test resource that is used to reproduce this issue, returns in https header the following parameters of CSP sandbox directive.
The fixes applied to our js-based autofill scripts are to better handle appropriately isolated contexts. This means that the developer of the web page has specifically taken steps to inform us that they don’t trust this content and don’t consider it part of their application, so we shouldn’t either.
The attack being described by Englehardt is one in which the hidden form lives outside of these sandboxed environments without any kind of indication that they are not owned by the top domain.
@mgibson Thanks for the clarification. Is there any technical reason why the auto-fill code cannot detect form fields that are not visible, and refuse to fill those? That would take care of the type of XSS attack described by Englehardt (among others).
@mgibson Thank you for the explanation! Have a good day.
@Dan_B1
I think it’s different things, Sandboxie is designed to isolate app’s process by restricting its privileges and rights (iirc), whilst CSP Sandbox directive instructs browser to strictly process web content on the page. The fix in the password manager just disables auto-fill for this kind of web pages with CSP Sandbox header response.
Couldn’t post a new response, because the forum doesn’t allow me to post more than three posts in one thread…
There is no technical reason, but there are usability reasons.
You may have realized a trend to transition log in pages to multi-step processes – Bitwarden itself has moved to it recently. This is to facilitate advanced login mechanics like SSO, login with device, linked application unlocking, etc. The best practice for these multi-step pages is to present the username first, and have a hidden field for the password, that will be passed along to the password step, should it occur.
Before anyone points it out, we’re aware the web vault doesn’t work this way, it was a miss in the original feature and we just haven’t gotten the time to get back to it
If this is the only reason, then it seems that the main drawback of preventing Bitwarden from auto-filling invisible fields would be that the user has to auto-fill twice (once on the username field, and again on the password field), and that it is possible the “autofill on page load” may not work for the password field, requiring a manual auto-fill (Ctrl+Shift+L, etc.) there.
Personally, I always use Ctrl+Shift+L for security reasons, and having to hit this keyboard shortcut twice would be a negligible price to pay for the peace of mind of knowing that only the visible fields are being auto-filled. In fact, I find it a bit unnerving when I auto-fill my username, and then see that the password is already filled when I get to the password screen (which I have discussed in detail in my analysis on Preventing Amazon from “stealing” password).
Thus, if this usability issue is the only thing standing in the way of a more secure auto-fill, then I think that users should be given the option of disabling auto-fill of hidden fields. I am encouraged to learn from your response that there are no technical hurdles standing in the way of such a feature.
Yeah I tend to agree with you. However, I didn’t mean to suggest it was easy, just that it’s in principle possible.
I don’t personally know of a simple way of determining if something is hidden. Since visibility flags are set on the item-level, but are inherited from parents, you have to walk the DOM to determine if something is displayed. Then there are weird ways of making things hidden like positioning it way outside of the view or maybe some other ways I can’t conceive of.
Like everything related to stopping bad actors, I’m sure it’ll be an arms race. I’ll raise your support of that feature. I’m hopeful to be able to get some meaningful autofill improvements in the near future.
I really wish people would refrain from posting clickbait sensationalistic blog articles full of misinformation (yes, I’m referring here to the “bleeping” FUD that you linked). I guess this is a sport now that Lastpass got in trouble — trying to take down the “next” password manager product.
The only valuable piece of information in that blog is the link to the Flashpoint report that the blog author is plagiarizing paraphrasing (and poorly at that). And the link to that source was already posted by @mookbav in the comment just above yours.
With regards to the original report by Flashpoint, they describe a well-known, but tricky issue related to balancing legitimate use of iframes by some websites (e.g., iCloud.com) vs. the rare possibility that an advertiser can abuse this function. As noted earlier in this thread, Bitwarden recently released a patch that prevents auto-filling in iframes that have been sandboxed. Flashpoint has not provided any working proof-of-concept demo that can be tested without paying them (!), so it is possible that this latest patch fixes whatever they claim they found. Furthermore, they admit that the only “vulnerability” they found can be readily mitigated simply by changing the URI Match Detection option from Base domain to Host.
All of this just smells like an attempt by Bleepingcomputer and Flahspoint to profit from spreading FUD.