Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Am 03.12.19 um 10:49 schrieb Daniel Fett: > Am 03.12.19 um 10:21 schrieb Christian Mainka: >> Hi, >> >> according to [1], countermeasure (1) describes to >> >>> configure [the] authorization servers to return an AS identitifier >> ("iss") and the "client_id" for which a code or token was issued in

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

On Tue, Nov 26, 2019 at 7:20 AM Daniel Fett wrote: > Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: > > Depending on its implementation the client might simply extract all data > > contained in the Client Information Response and use it for > > authorizations with the specific AS. > >

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Am 03.12.19 um 10:21 schrieb Christian Mainka: > Hi, > > according to [1], countermeasure (1) describes to > >> configure [the] authorization servers to return an AS identitifier > ("iss") and the "client_id" for which a code or token was issued in the > authorization response. > > So if an MixUp

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Hi, according to [1], countermeasure (1) describes to > configure [the] authorization servers to return an AS identitifier ("iss") and the "client_id" for which a code or token was issued in the authorization response. So if an MixUp attack is running, the victim contacts A-AS but is redirected

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Am 02.12.19 um 10:05 schrieb Christian Mainka: > I think this problem is not only restricted to the redirect_uri. > Regarding countermeasure (1), also the A-AS can return the same > client_id as the client uses on the H-AS. > > TL;DR: In countermeasure (1), only the issuer prevents MixUp, the >

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Hi Daniel, I think this problem is not only restricted to the redirect_uri. Regarding countermeasure (1), also the A-AS can return the same client_id as the client uses on the H-AS. TL;DR: In countermeasure (1), only the issuer prevents MixUp, the client_id parameter can be faked as well during

Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Hi Karsten, Very interesting observation! My gut feeling is that this is the real problem here: Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: > Depending on its implementation the client might simply extract all data > contained in the Client Information Response and use it for >

[OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Hi, we identified a possible issue regarding the Mix-Up attack countermeasures described in the Security Best Current Practices. Section 4.4.2 of the latest version of the BCP lists "AS-specific redirect URIs" as a countermeasure for Mix-Up attacks. This countermeasure can be bypassed if