IETF 118 followup review #30
Conversation
Co-authored-by: Aaron Parecki <[email protected]>
Co-authored-by: Aaron Parecki <[email protected]>
Co-authored-by: Aaron Parecki <[email protected]>
Co-authored-by: Aaron Parecki <[email protected]>
| ### Acquisition and Extraction of New Tokens {#payload-new-flow} | ||
|
|
||
| In this advanced attack scenario, the attacker completely disregards any tokens that the application has already obtained. Instead, the attacker takes advantage of the ability to run malicious code in the application's origin. With that ability, the attacker can inject a hidden iframe and launch a silent Authorization Code flow. This silent flow will reuse the user's existing session with the authorization server and result in the issuing of a new, independent set of tokens. This scenario consists of the following steps: | ||
| In this advanced attack scenario, the attacker completely disregards any tokens that the application has already obtained. Instead, the attacker takes advantage of the ability to run malicious code in the application's execution context. With that ability, the attacker can inject a hidden iframe and launch a silent Authorization Code flow. This silent flow will reuse the user's existing session with the authorization server and result in the issuing of a new, independent set of tokens. This scenario consists of the following steps: |
There was a problem hiding this comment.
I don't believe that the consistent rewording to execution context is accurate in this context. It is true that the code runs in the execution context, but the underlying security model of the browser is based on origins (Same-Origin Policy). When two execution contexts have the same origin and have a direct reference to each other, they are not isolated (e.g., a parent window and a frame).
I strongly recommend to stick with origin. Alternatively, we should add a note to explain this context.
There was a problem hiding this comment.
Explaining either one of the two that you think is more appropriate is definitely needed. I don't think origin is any better to execution context without an explanation of what we mean by it.
There was a problem hiding this comment.
Reworded to clarify what it means.
| however, that the browser will attempt to GET or POST to the API endpoint before | ||
| knowing any CORS policy; it simply hides the succeeding or failing result from | ||
| for these endpoints should be a wildcard origin or more restrictive. Note, | ||
| however, that the browser will typically do a "preflight" request to check to see |
There was a problem hiding this comment.
This is not correct. The browser only uses preflights for CORS-safelisted requests (i.e., anything that cannot be sent without modifying a request through JS). A simple GET or POST without custom headers or without a custom content type will not require a preflight.
There was a problem hiding this comment.
A simple request won't get a preflight, right, feel free to reword the conditions which are currently summarized as "typically".
It needs to be mentioned (at least here) that when one uses DPoP there are no more simple requests. Having had written not one browser based client I am no longer envisioning typical operation to be without preflights.
There was a problem hiding this comment.
I understand your point of view, but vanilla OAuth requests with form encoding would be simple requests. Reworded the text to add the necessary context.
| during preflight when it has no access to the actual request's body or headers and then when | ||
| the actual request is made decide to restrict the response after it was able to check the request | ||
| was made from an expected origin based on the data in the request, e.g. based on pre-registered | ||
| origins of the Browser-based OAuth 2.0 client. |
There was a problem hiding this comment.
I am assuming you are hinting at a dynamic CORS configuration where the AS uses the client ID to lookup a configuration and determine if this origin is legitimate? If that is indeed true, I don't think enforcement through CORS would be a correct implementation technique. I consider it application-level logic, akin to checking a redirect URI during an OAuth flow. As such, I would handle this as an application-level error instead of an invalid CORS request.
I am not objecting against this, but I believe it needs a bit more explaining when it is left in. This will not be obvious to someone without proper context.
There was a problem hiding this comment.
It is not enforced through CORS, the request would still fail with a proper oauth error, but it is through CORS that we ensure even these error responses don't get read from unintended origins.
There was a problem hiding this comment.
So the scenario would be as follows:
The AS has client 1 with origin A and client B with origin B. Upon handling a preflight, it sees a request coming from origin B, so it allows the request to go through. Upon handling the request, the AS sees that client 1 does not have origin B approved, so it issues an error message. However, additionally, it should not set the CORS header that allows origin B to read this response.
Is that a correct description? If so, I think we need to add this context in the document to make this point clear. We probably also need to make this a SHOULD requirement for the AS (as I don't think we can make it a MUST)
There was a problem hiding this comment.
It's currently a Note and I think that's enough to give guidance. I wouldn't make this normative in any way.
There was a problem hiding this comment.
Sounds good. I have rephrased this to include a bit more details on an example.
Reworded the text based on the discussion in [PR oauth-wg#30](oauth-wg#30)
Reworded the text based on the discussion in [PR oauth-wg#30](oauth-wg#30)
3 participants
A followup review with suggestions as requested at IETF 118