jricher
commented
2 years ago Thanks for the extensive writeups and diagrams. This points out what I think are the inherent risks in multi-device setups.
What the editors plan to do for #361 (and #22) is have new security considerations and examples that talk about the combinations of start/finish methods where the kinds of session-based mitigations you describe are actually possible, and warn for the cases where they are not.
This issue is related to issue #361.
When not using the redirect interaction start mode together with the redirect interaction finish mode, depending on how exactly issue #361 is dealt with, the following attack may be possible:
We assume that an honest end user wants to start a grant with a client instance controlled by an attacker and using an honest AS. In the role of an end user, the attacker then replays this request to an honest client instance using the same AS. The honest client instance then sends a grant request to the honest AS and receives a grant response with a user code. The honest client instance then forwards/shows this user code to the attacker, who in turn passes it on to the honest end user. The honest end user navigates to the user code interaction URI of the AS, authenticates herself, enters the user code and then has to authorize the request of the client instance. Since this request comes from the honest client instance and not the client instance controlled by the attacker, the end user could notice that something is wrong based on the information shown to her by the AS. However, assuming that every end user is informed enough to prevent the attack at this point is known to be unrealistic. If the end user authorizes the request, the interaction will be completed successfully and the honest client instance will receive an access token, for example. The attacker can now use the honest client instance with an access token that was issued for the honest end user and with the privileges of the honest client instance.
This attack fails when using the redirect interaction start mode and the redirect interaction finish mode if the honest client instance checks after the interaction that the same end user is "present":
We assume here that the honest client instance ensures that the same end user is present by storing a session ID as a cookie in the end user's browser. During the first redirect from the client instance to the AS, the attacker can theoretically set the same session ID as the honest client instance, but this would not be of any use for the attacker. With the first redirect, the honest end user is forwarded by the attacker, while with the second redirect she is forwarded by the AS to the honest client instance. The attacker can only set a cookie for his own domain in the first redirect, which means that a session ID set by the attacker is not sent to the honest client instance in the second redirect because the honest client instance uses a different domain than the attacker.
Note that in this scenario, the attack could be prevented by the AS already after the first redirect, if the AS would check the Referer header. Since the domain of the attacker's client instance is specified in the Referer header and not the domain of the honest client instance, the AS can reject. However, this is only possible if redirects are actually used. If, for example, a local client instance installed on the end user's device starts a browser with the interaction URI, no Referer header will be sent to the AS.
It should also be mentioned that for this attack to work, the honest end user does not necessarily have to start a grant with the client instance controlled by the attacker. As seen in the session on Risk Mitigation for Cross Device Flows during the OAuth Security Workshop, the attacker can also start a flow with the honest client instance on its own. The attacker can then, for example, display the interaction URI as a QR code and somehow get an honest end user to scan this QR code. Since the QR code forwards the end user to an honest AS, the end user is inclined to authorize the request at the AS.