Proton pass autofill cure53 audit iframe issue

Chipper

Hi,
I notice many people on the forum talking about autofill generally, so i have the impression that it is commonly used to pass credentials to login prompts.
Since reading about the iframe issue from protonpass's Cure53 audit:
"PRO-01-003 WP1: Autofill can be invoked from within iframes (Medium)
Note: Proton has discovered that this issue cannot be resolved at this time due to a
platform limitation in Android (the Android operating system does not currently provide
the information that would be required to resolve it)"

I now use copy paste, and have done since the audit came out, however as a new GrapheneOS user seeing everyone using autofill makes me wonder if Gos addresses this iframe issue somehow?

fid02

Chipper
Manually copy-pasting passwords instead of using autofill provides me with negligible protection against phishing attacks, iframes or not. Autofill in browsers regularly fail for various reasons. Thinking that copy-paste would protect me against a successful phish would just provide me with a false sense of security. Why can't a phisher just trick me into believing their site is highly legitimate? There's no reason to trust autofill for protection. A capable social engineer could lead me into an anxious or otherwise highly emotional state, making me ignore any red flags that I would normally immediately spot when not experiencing any anxiety or worry. Copy-pasting would give me a few extra seconds. Do I really believe that is enough time to make me take a step back and contemplate the situation, and think "hey, why didn't my password manager autofill? It could be a trick! Let's check for an iframe!" There is no way I am going to rely on this.

Tryptamine This is another example of where you need to be savvy and don't be dumb!

Intelligence has nothing to do with this. A successful play on emotions will bypass any intelligence one may possess. Unclear what you mean by "savvy".

Phishing-resistant authentication is the only protection against these kinds of attacks. It's unfortunate that the rollout is not quicker, given the urgency of this issue. Highly recommend setting up passkeys on accounts that support this. You can also use passkeys as MFA on site that support security keys. There's a guide on this here, although it's unfortunate that you currently need to do the registration from a desktop OS, sign-in can still be done easily on GrapheneOS: https://discuss.grapheneos.org/d/12019-passkeys-as-mfa-on-grapheneos-a-guide/6

Tryptamine

I just read the audit report. Seems this is when you are filling in credentials into an iframe, and not into a top lever site?

I also made the iframe on their text website (link in the Cure53 report) leak my made-up credentials when I didn't use autofill, and just typed in whatever. Seems this is just a sketchy situation!

I think whether you autofill, copy/paste, whatever, a better rule of thumb is; Don't log into iframes! Make sure you trust the website you are logging into. This is another example of where you need to be savvy and don't be dumb!

When have you ever logged into a cross-origin iframe? I block cross-origin everything like it has the plague, so I can't even remember seeing a third-party iframe anytime recently, but logging into something that wasn't a first-party, top-level site? Sketchy!

RRZishe

Tryptamine What are iframes and how do I know if a site is one?

Tryptamine

RRZishe a box in a website that loads a different website in it. That's an iframe. Used for ads a lot. I block them on desktop using Noscript!

FlipSid

Tryptamine can you elaborate more. I'm kind of having a hard time comprehending at the moment. Night Shift 😵‍💫
And what to do on Vanadium?
On FF I would just use uBlock Origin and medium mode.

Tryptamine

FlipSid a third party iframe used to be much more common back in the day. Haven't seen one for a long time, but then again I block stuff with a hosts file, both on GrapheneOS and desktop. Its a file in /etc/ on Ubuntu and /system/etc/ on GrapheneOS that let's you set rules for IP addresses for domains to redirect to. It has 1.5 million lines in my setup, redirecting ad and tracking domains to 0.0.0.0. You need to build it into GrapheneOS to have it on your phone, you can't just modify /system/etc/hosts

uBlock works well, especially in medium mode, which blocks scripts! It doesn't block first party scripts in medium, hard mode doesn't even do that. You can set first party scripts to be blocked too, but hard mode will block iframes at least since it blocks all third party resources. I block all JavaScript, first and third party, using Noscript. I just like it a lot better. So my uBlock only is for Adguard URL Tracking Protection. I also import the Actually Legitimate URL Shortener Tool.

That's on desktop though. On mobile (Android) Firefox lacks proper sandboxing of the web renderer. Unfortunate but it makes Vanadium the clear choice! Stay away from Firefox on your phone, it is too easy for a malicious website to have its data persist on your phone...

Vanadium block ads too! You can set it to block scripts too under "site settings." It blocks Java JIT by default. It is hardened chrome with all the Google telemetry taken out. I looked at all the patches when I compiled Vanadium, and there are a lot, and a lot of great ones that really enhance privacy and especially security! Nothing else like it!

For an example of an iframe, go to this website. the iframe is the box with a login prompt. This is the test site from the Cure53 report. If you put in anything for a username and password it will leak it to the top level website. Not just an autofill issue!

FlipSid

Tryptamine thank you for elaborating.
I use Vanadium as my main browser with disabled cross origin referrer. On top of that iVPN with comprehensive mode. As I understand it has 1Hosts Pro as one of the Blocklists used in this setup.
Since being on GrapheneOS I have stopped using Gecko.

Tryptamine

FlipSid I still use Firefox Nightly on desktop. I have been using it since it first came out, and the Mozilla browser before that, when Netscape shut down, since that was what I was using even before that back in the late 90's! Firefox was the spiritual successor to Netscape after all!

I have loved it, and they are very serious on security, always improving especially on the Nightly build!

There are arguments to be made that Chromium browsers are better on desktop too, but a healthy web environment needs competition between different web renderers. If it is all Chromium, Google will certainly push their new standards on everyone and that will be the end of an open web...

I harden Firefox to the maximum degree I can. It is incredibly customizable and that's what I've been doing for almost 2 decades! The Arkenfox project (with a lot of optional switches enabled) combined with a great hosts file, with only uBlock Origin and Noscript for extensions (only Adguard URL Tracking Protection and Actually Legitimate URL Shortener Tool for uBlock because of the hosts file) is a very hardened setup, and by far the most secure setup I have ever found when applied to Firefox Nightly!

My mobile Firefox on GrapheneOS has all the same modifications, Arkenfox and all. A lot of the tweaks in the Arkenfox script don't work on Android though, but at leadt the important ones do. I only use it to transfer links back and forth from my laptop though using Firefox Sync, and it's hardened just for that. Vanadium for everything else!

Chipper

You raise great points Tryptamine, as a fellow Arkenfox, noscripts, firefox user on desktop (ublock serves no useful purpose i think if you run noscripts, and my vpn runs list based blocking for ads malware anyway) I was disappointed to hear that the android implementation was inferior to Vanadium but happily made the decision to use Vanadium once i moved to Gos (i would certainly love the finely grained control of noscript like blocking in Vanadium over the "Scripts or no?" choice i get with vanadium) but of course i fully appreciate and comprehend all the additional benefits i get with Vanadium and the effort it has required to achieve this so i quite gratefully and happily use it.

Your point about credentials being hijackable whether auto filled or not is well received, and certainly, aiming to not pass credentials to (or interact with in any way, even loading Iframes or cross site originating content i think) is sage advice (hence the usefulness of finely grained noscript like blocking and it being missed in Vanadiuim)

I have been operating on the assumption that the use case for an iframe based autofill credential hijack would likely not be made by a visible iframe that i knowingly interact with, but by an invisible iframe (made invisible say by simply styling it out of view) that obtains the credentials merely by happening to be loaded on the page and my happening to having autofill enabled therefore requiring no user interaction to obtain.. (maybe it would need to have you press a button.. any button on the page)
So while you make a great point about the copy paste also being exploitable, in the use case i envision i am unlikely to interact with the iframe and manually provide it my details, yet with autofill enabled i would be oblivious to the hijack. (the autolock feature of protonpass being set to say 1 min obviously would go a long way to mitigate this but it is far from being considered solved)

Tryptamine

Chipper yeah, autofill might be able to populate a field in an invisible iframe, I just can't see it happening... You would need to click on the login box, which wouldn't be visable, the login would pop up, you would need to click on it, then unlock the password manager with a fingerprint. Seems like too many things to happen before that filling of a login into an iframe would happen. You would be just as likely to type in your credentials if that iframe perfectly replaced the usual login box of a website and disguised itself well enough...

This is also why its a critical rule: one password for one website! then stolen credentials only compromise that site, nothing else!

Chipper

fid02

While you may be right that using copy-paste instead of autofill provides you with negligible protection against phishing attacks iframes or not, (personally i think you have incorrectly minimized the protection having to consciously and manually enter credentials provides in the event of phishing) my question was about iframes and whether or not Gos/vanadium has in some way been able to mitigate the potential for this exploitation.

Given my appreciation for the sense in the Gos approach to security being to eradicate whole classes of exploit, rather than focus on individual exploits wherever possible, i do see the sense in transitioning to passkeys and have excitedly watched the industry slowly move towards enabling passkey use for commonly used services.

As a long time security key user that is already accustomed to using keys stored on a hardware device for authentication the one thing i have been confused by though not spent anytime researching is the supposed phishing resistance of passkeys once they are made copy-able... in my mind the phishing resistance of a passkey is not separate from its ability to be transferred (or lack thereof)... once it is used like a password, stored in a password/passkey manager and used for authentication in the same fashion as current passwords then presumably the ability to phish it the same as a password also exists?

fid02

Chipper my question was about iframes and whether or not Gos/vanadium has in some way been able to mitigate the potential for this exploitation

Indeed, I see now that my reply was off-topic and I apologise for this.