search

aaronpk / draft-parecki-oauth-client-id-metadata-document

Other
0 stars 1 forks source link

need more warnings about OAuth phishing attacks #4

Open aaronpk opened 1 month ago

aaronpk commented 1 month ago

https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html#name-oauth-phishing-attacks

This section should be more explicit about the dangers of app impersonation through the metadata document.

For example, a client hosting a metadata document at https://goooooooogle.com/metadata could put an app name and logo icon of "Google Docs" in the metadata, impersonating a client that is actually https://google.com/metadata, potentially leading to authorizing the wrong client.

We should place a stronger recommendation around displaying the hostname of the actual client_id to the end user to help prevent this kind of phishing.

matthieusieben commented 1 month ago

Aren't there also some phishing attacks risks when allowing the redirect_uris to be on any domain? If a client does not properly encode the state param (like they should!), they could interpret a redirection that was initiated by an attacker as a legitimate authorization callback.

matthieusieben commented 1 month ago

The approach towards which I'm leaning is to require the client_uri to be the "parent" url of the client_id (the same url but without the last path segment and no query string), and require that all redirect_uris start with <client_uri>/.

Also, we don't plan on showing the icon_uri for unknown clients. We might put in place a mechanism to allow devs to add their clients to the allow listed clients.

ThisIsMissEm commented 1 month ago

The approach towards which I'm leaning is to require the client_uri to be the "parent" url of the client_id (the same url but without the last path segment and no query string), and require that all redirect_uris start with <client_uri>/.

Also, we don't plan on showing the icon_uri for unknown clients. We might put in place a mechanism to allow devs to add their clients to the allow listed clients.

That breaks custom app redirect protocols

matthieusieben commented 4 weeks ago

Yeah, I'm only doing this for HTTP based uris.

ThisIsMissEm commented 4 weeks ago

This would also break HTTP cases where you want the app at https://app.myservice.example but the marketing/about site is https://myservice.example

ThisIsMissEm commented 4 weeks ago

In the case of BlueSky, you could also extend the metadata you store to include one of your bluesky DIDs, which would be used in preference over icon_uri, and if that client metadata document were then used against say, a mastodon server, then it'd just ignore the additional property it doesn't understand

matthieusieben commented 4 weeks ago

I realize now that adding restrictions on the client_uri or redirect_uris is probably worthless, as these could indeed be "valid" (wrt to those restrictions) while performing a 3xx redirect when visited.

Regarding the icon, I am not sure how using an account's profile picture (through its DID) would allow avoiding impersonation of well established companies.

ThisIsMissEm commented 4 weeks ago

It wouldn't necessarily prevent, but you'd have an on-platform identity linked which could then help with moderation