Presumably, the attacker can get the token by having the Honest-AS redirect the user to a site controlled by the Attacker. That site then would redirect the user back to the original site with the Honest-AS token. This is no different than an ordinary phishing based attack.
On Wed, Jun 14, 2023, 20:24 Alexander Rademann <alexander.radem...@web.de> wrote: > > > *Hello, everyone!Section 4.4.1 of the BCP > <https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-23.html#section-4.4.1> > draft lists several variants of mix-up attacks; the description of the > Implicit grant variant reads as follows: "In the implicit grant, the > attacker receives an access token instead of the code; the rest of the > attack works as above."Given the attack description in that section, it is > not clear to me why an attacker would receive the access token and which > part the "rest of the attack" refers to. When the Implicit grant is used, > H-AS sends the access token (via redirect) to the user agent, which > extracts it and sends it to the client. However, the client does not send > the access token to A-AS, does it? (I hope that I didn’t overlook anything > in that section.)* > > > > *I also checked the referenced paper <https://arxiv.org/abs/1601.01229>; > there, the authors assume that the access token is sent to the > authorization server under the control of the attacker (or, using their > terminology, identity provider) to access some resource. [Appendix B, p. > 31ff] Perhaps this (or some similar) assumption should be added to the > description of this variant?I'm sorry if I missed anything or if this has > already been addressed before, I'm new to this mailing list and did not > find anything in the archives.Kind regardsAlex* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
