Hi Francisco,
Am 22.02.2011 06:57, schrieb Francisco Corella:
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
true, this was a mistake.
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.)
That's correct. I changed resource server to client.
> ...
>
> 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.
whether this is an obstacle mainly depends on whether a client secret is
associated with this client_id.
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.
You describe the potential impact of a spoofing attack on the client web
site, correct? Is this specific to OAuth? I ask because the focus of the
document is on OAuth specific threats.
> 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!
You are right. Things are getting less obvious after 6 month of work on
a document :-) I corrected that.
> 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.
Hmmh, OAuth 2.0 is just a protocol. Implementations decide to
send/receive authorization codes with or without TLS protection. Having
the security threat model now, the OAuth 2.0 spec could declare TLS
protection a MUST for the redirect back to the clients. I think that's
what you would like to see?
regards,
Torsten.
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
