Hi Torsten, > 4.4.1.2. Threat: Eavesdropping authorization codes > > The OAuth specification does not describe any mechanism for > protecting authorization codes from eavesdroppers when they are > transmitted from the Service Provider to the Client and where the > Service Provider Grants an Access Token. > > Note: A description of a similar attack on the SAML protocol can be > found at http://www.oasis-open.org/committees/download.php/3405/ > oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1). > > Countermeasures: > > o The authorization server SHOULD enforce a one time usage > restriction (see Section 5.1.5.4). Authorization server as well > as Resource server MUST ensure that these transmissions are > protected using transport-layer mechanisms such as TLS or SSL > (see Section 5.1.1).
You are talking here about eavesdropping to obtain the authorization code. The authorization code is not sent to the resource servers. I agree that the authorization code must be protected by TLS when it is sent by the client to the authorization server. But it must ALSO be protected when it is sent by the browser to the client. (The connection from the browser to the client is easier to eavesdrop on than the connection from the client to the authorization server!) (It must also be protected when sent from the authorization server to the browser in the redirection response, which is probably the case anyway, since that's the response portion of the HTTP request that authenticates the user.) > ... > > 4.4.1.6. Threat: Authorization code phishing > > A hostile party could act as the client web server and get access to > the authorization code. This could be achieved using DNS or ARP > spoofing. Yes. > Impact: This affects web applications and may lead to a > disclosure of authorization codes and, potentially, the corresponding > access and refresh tokens. The attacker will not get the access and refresh tokens without the client_id, but doesn't need to. The attacker can impersonate the user, log in to the client if the protocol is used for social login as in "log in with Facebook", and use the client to obtain protected resources of the legitimate user and deliver them to the attacker. The attacker never sees an access token, but the client gets the access token and uses it for the benefit of the attacker. > Countermeasures: > > o The client shall authenticate the server using server > authentication - Section 5.1.2 Really????????? The browser is sending the authorization code to the client, and the attacker is using DNS or ARP spoofing to receive it instead of the client. To prevent this, what's needed is obviously authentication of the client by the browser, not authentication of the server by the client! > o The authorization server shall require the client to authenticate > with a secret, so the binding of the authorization code to a > certain client can be validated in a reliable way (see > Section 5.2.4.4). Client authentication to the server does not prevent the attack. The authorization code is a credential that provides access to the user's protected resources (via the client) and allows the user to log in to the client (in a social-login scenario). Sending it without TLS protection, as OAuth 2.0 does, is tantamount to sending a user password without TLS protection. If you are not convinced please read the message I sent you a few weeks ago, available at http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and section 3.5.3 of the security analysis paper I announced earlier, available at http://www.pomcor.com/techreports/DoubleRedirection.pdf. (Section 3.5.3 refers to section 2; if you don't want to read the whole section 2, the relevant portion is the last three paragraphs of page 4.) Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
