-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redirected Icon Validation #1139
Comments
@christiaanbrand / @agl, What do you guys do in your platform? |
We do not currently process icons, so have no applicable behaviour here. However, if we did, I don't think that we would be comfortable fetching the icon when displaying the account chooser because that would disclose to the network and server that a given account was displayed. So we would likely try to fetch and cache the icon at registration time, perhaps turning it into a |
Thanks @agl. That would be another way. @herrjemand , Looks like both Windows and Android platforms are not processing/supporting icons. And this test only makes sense if platforms supported icon is any manner. So we can either remove the test or not treat passing this test mandatory if a platform does not support icons. |
Okay, I agree that this test is not applicable at this moment. |
Thanks Yuriy. |
Currently Icon in the spec is marked as "This URL MUST be an a priori authenticated URL." and currently FIDO2/WebAuthN conformance tests includes a test where icon supplied by the test is a redirected HTTPS URL to an HTTP URL and expects an error from the browser during MakeCredential/Create call.
But there is no protection for this icon to be from the same origin and can be used to fool the user. For example, a bad RP uses well known image to fool the user. Another issue with redirected URLs is that they can change over time. So, in our opinion, they must only be checked when actually shown/rendered to the user.
We, at Microsoft, due to security reasons, don't support Icon fetching at our platform when we do the multiple account selection UI where this icon can be rendered and is applicable. This is applicable for platform as well as external security keys case. As and when if we decide to support this, we will do the validations at that point and ignore these redirected HTTPS to HTTP url. So there is no security issue as of now w.r.t these URLs as we don't support them for now.
So IMO, this test should be removed from the makeCredential/Create layer and should only apply to the platforms if and when they are actually using it during multiple accounts selection UI at getAssertion/Get call..
The text was updated successfully, but these errors were encountered: