4 ms·

> Then you can show it to the user so they know exactly where the token is being sent Unfortunately, most major websites end up hosting an endpoint that will r

by awans 2y ago

> Then you can show it to the user so they know exactly where the token is being sent Unfortunately, most major websites end up hosting an endpoint that will redirect users to a separate URL provided as a query parameter. This means that users may easily be misled about where the token is, in fact, being sent. [0] - https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-open-redirects https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-... [1] - https://datatracker.ietf.org/doc/html/rfc6819#section-4.2.4 https://datatracker.ietf.org/doc/html/rfc6819#section-4.2.4

apitman 2y ago
> most major websites Is this true? Do you know of any major ones offhand? That would be surprising to me. Thanks for sharing [0]. I found its discussion of shared subdomain cookies useful. However, I believe all the vulnerabilities in the OAuth section would be mitigated by using PKCE and not using the implicit flow, even if you leave the open redirect. Am I missing anything there? As for open redirects in general, it is an important problem. As an authorization server, if you want to protect against clients that might have an open redirect (and as you indicate eventually one will), while still using the simple scheme I mentioned above, I can think of a few options: 1. Require the client_id to exactly match the redirect_uri instead of just a prefix. This is probably the most secure, but can result in ugly client IDs shown to the user, like "example.com/oauth2/callback". Of course clients can control that and make it something prettier if they want. 2. Strip any query params from the redirect_uri, and document this behavior. That should handle most cases, but it's always possible clients implement an open redirect in the path itself somehow. You could also check for strings like "http", but at some point there's only so much you can do. 3. Require clients to implement client metadata[1], so you can get back to exact string matches for redirect_uri. This is a very new standard, and also doesn't work for localhost clients. [0]: https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-open-redirects https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-... [1]: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-client-id-metadata-document https://datatracker.ietf.org/doc/html/draft-parecki-oauth-cl...
- kccqzy 2y ago
  Google has a URL redirector: https://www.google.com/url?q=https://news.ycombinator.com/item?id=41461892 https://www.google.com/url?q=https://news.ycombinator.com/it...
  - apitman 2y ago
    Does that count as an open redirect? It gives a big fat declaration where you're coming from and where you're going to, and requires the user to choose. I agree some nonzero number of users would click to continue when they shouldn't while doing an OAuth flow. Thanks for the example.

by awans 2y ago

apitman 2y ago

> most major websites Is this true? Do you know of any major ones offhand? That would be surprising to me. Thanks for sharing [0]. I found its discussion of shared subdomain cookies useful. However, I believe all the vulnerabilities in the OAuth section would be mitigated by using PKCE and not using the implicit flow, even if you leave the open redirect. Am I missing anything there? As for open redirects in general, it is an important problem. As an authorization server, if you want to protect against clients that might have an open redirect (and as you indicate eventually one will), while still using the simple scheme I mentioned above, I can think of a few options: 1. Require the client_id to exactly match the redirect_uri instead of just a prefix. This is probably the most secure, but can result in ugly client IDs shown to the user, like "example.com/oauth2/callback". Of course clients can control that and make it something prettier if they want. 2. Strip any query params from the redirect_uri, and document this behavior. That should handle most cases, but it's always possible clients implement an open redirect in the path itself somehow. You could also check for strings like "http", but at some point there's only so much you can do. 3. Require clients to implement client metadata[1], so you can get back to exact string matches for redirect_uri. This is a very new standard, and also doesn't work for localhost clients. [0]: https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-open-redirects https://sec.okta.com/articles/2021/02/stealing-oauth-tokens-... [1]: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-client-id-metadata-document https://datatracker.ietf.org/doc/html/draft-parecki-oauth-cl...

kccqzy 2y ago
Google has a URL redirector: https://www.google.com/url?q=https://news.ycombinator.com/item?id=41461892 https://www.google.com/url?q=https://news.ycombinator.com/it...
- apitman 2y ago
  Does that count as an open redirect? It gives a big fat declaration where you're coming from and where you're going to, and requires the user to choose. I agree some nonzero number of users would click to continue when they shouldn't while doing an OAuth flow. Thanks for the example.