Subject: [OAUTH-WG] Fwd: OAuth Security Consideration Text

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 May 2011 21:37:12 +0300

Breno did a review of the security draft.
Thanks a lot!

Begin forwarded message:

> From: Breno de Medeiros <[email-masked]>
> Date: May 7, 2011 4:25:53 AM GMT+03:00
> To: Hannes Tschofenig <[email-masked]>
> Subject: Re: OAuth Security Consideration Text
> 
> Hi Hannes,
> 
> I have gone through the test and I have a few edits and questions.
> 
> In the edits below, text between -- -- are supposed the be stricken
> out. Example if the original is:
> 
> They quick brown fox ...
> 
> and my suggested edit is:
> 
> --They--The quick brown fox ...
> 
> it means that I am suggesting that you replace the original with
> 
> The quick brown fox ...
> 
> Now edits by section: -------------------------------------
> 
> IN: Section 1. Definitions
> 
> Web Application .... to the OAuth protocol is--are-- stored on the
> server and --is-- not accessible ...
> 
> User Agent-based Application ... they can seamlessly make use of
> --it--its capabilities ...
> 
> IN: Section 2.2 Malicious Client Obtains Authorization
> 
> ...
> 
> Where the client can be --authenticate--authenticated ...
> 
> ...
> 
> It is --higly--highly RECOMMENDED that ...
> 
> IN: Section 2.9 Phishing Attacks
> 
> in which users can confirm the --authentictity--authenticity of the site.
> 
> -----------------/edits
> 
> Now higher level comments:
> 
> On Native Apps protection of refresh token:
> 
> On section Definitions, there is a sentence in the Native Apps "It is
> assumed that such applications can protect dynamically issued secrets,
> such as refresh tokens, from eavesdropping by other applications
> residing in the same service"
> 
> I suggest that you strike out this sentence from definitions since it
> is confusing. This should be moved to section 2.4, with a specific
> headed paragraph about management of refresh tokens for native
> applications including specific recommendation.
> 
> E.g. of substitution paragraph:
> 
> Native Applications MUST use operating system mediated protections to
> ensure that the refresh tokens are safe from unauthorized access by
> other users and applications. It is highly RECOMMENDED that such
> applications use OS-provided APIs to manage secrets. The applications
> MUST apply appropriately restrictive access controls to any file
> system or persistent memory objects where the refresh token is stored.
> 
> On Client Authentication:
> 
> "Authorization servers are encouraged to consider stronger client
> authentication means" --> This is too vague to be actionable. There is
> a great tradition of 'innovation' in client security that promotes no
> security and hinders interoperability. I tend to believe that it is
> better for servers to be conscious of the limitations of client
> authentication and implement mitigation measures than to create ad-hoc
> authentication mechanisms. Suggest to strike out this sentence.
> 
> "Authorization server MUST NOT issue client secrets to native or user
> agent-based applications in general." -> Agreed on user-agent, however
> at least in principle it is possible to issue secrets to native
> applications that use hardware-based DRM modules and can hold on to
> secrets. More importantly, since the OAuth2 spec no longer actually
> specifies how to implement a Native App Flow end-to-end, I am not sure
> how to even reason about Native App issues. Propose simply strike out
> 'native or'.
> 
> On Malicious Client Obtains Authorization:
> 
> "Authorization servers MUST NOT automatically process (without user
> interaction) repeated authorizations without authenticating the
> client." -> Not sure what to make of this sentence. If this implies
> User-Agent should not support automatic renewal of access tokens
> (since user-agent apps cannot be 'authenticated'), then it is a
> harmful recommendation because it ignores practical requirements. The
> bad word here is 'authenticating', since what is really intended is
> some assurance that it is the same client, e.g., the redirect URI
> matches a registered value in the User-Agent case. Please strike out
> this sentence or substitute it with one like:
> 
> "Authorization servers MUST implement measures to ensure that
> automatically issued tokens (without user interaction, based on
> previously recorded grant) are delivered to the same client to whom
> original grant was performed. Example of suitable measures are
> enforcing client authentication or enforcing that the destination of a
> redirect (in case of implicit grant) matches the expected value for
> the client."
> 
> On Access Tokens
> 
> "Application developers MUST NOT store access tokens in non-transient
> memory." -> This is not realistic -- consider the case of a Web
> Application running on distributed servers. It is quite possible that
> the only distributed storage mechanism available to the application is
> based on persistent storage. I suggest you strike out this sentence,
> since the previous one is sufficient.
> 
> On Session Fixation
> 
> This section needs to cover XSRF protection, the measures described
> within are insufficient for Web Applications or User-Agent-Based
> applications. Also the current mitigation described there is better
> described as a mitigation against token/code leakage.
> 
> I suggest that you create a new section:
> 
> ==
> Token and Code Leakage via Referer Header and/Or Open Redirectors
> 
> Attackers can leverage inclusion of third party content (images, ads)
> and/or the presence of redirectors in legitimate Web or
> User-Agent-Based Applications to steal codes and/or tokens issued to
> such sites.
> 
> "In order to prevent such attack ..." (move here the 2nd paragraph
> that currently lives on Session Fixation)
> 
> Now for the Session Fixation section, I would recommend that you
> expand it to also include 'token', since the attack is also possible
> via token.
> 
> The Session fixation attack involves an attacker that forwards a link
> to an unsuspecting victim. The victim clicks on the link and
> subsequently approves an expected application but as a result the
> attacker obtains access to the victim's data either at application or
> at the authorization server.
> 
> In order to prevent such attack, a Web or User-Agent-Based application
> MUST bind the state of authorization requests to the user's session
> with the application. This requires that the Application generate a
> strongly unguessable random number, and both include it in the 'state'
> parameter of the authorization request as well as to store it in the
> user's session, e.g., as an HTTP cookie, a DOM variable, or in any
> other suitable storage in the user's agent. When processing the
> response from the authorization server (whether in the form of a code
> or token), the Application MUST verify that the returned 'state'
> parameter matches the value in the user agent.
> 
> 
> 
> On Thu, May 5, 2011 at 14:26, Hannes Tschofenig
> <[email-masked]> wrote:
>> Hey Breno,
>> 
>> here is the draft I mentioned:
>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02
>> 
>> It would be great to get your review comments in.
>> 
>> Ciao
>> Hannes
>> 
>> 
> 
> 
> 
> --
> --Breno

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 12 May 2011 04:23:40 +0200

Hi Breno,

thanks for the feedback. Please find my comments inline.

> > residing in the same service"

the original text says: "on the same device"

> > applications including specific recommendation.

This section shall document all assumptions determining the differences between those categories, which are relevant for the security sections. Thus I would like to keep it and probably improve it. 

> > secrets. 

A couple of comments on this:

1) This statement is intended to prohibit secrets for software packages and not software instances. Thus the text also says "An authorization server MAY issue a client secret for an installation of a native application on a specific device.". We just want to get rid of the bad practice of using secrets for authenticating software packages. This practice creates a false feeling of security and people tend to rely on this kind of client authentication too much. They shall be adviced to utilize other means than client secrets.
2) The intention of the text is to give simple and clear rules instead of discussing "if", "then" and "why". This discussion is subject of the security threats and considerations I-D referenced by the introduction of the text.
3) DRM modules give you a device specific authentication, they do not authenticate a certain software package or instance.

>>> More importantly, since the OAuth2 spec no longer actually

The description of how to implement native apps is badly missing right now and has been requested during IETF-80. It will be re-included soon. 

> > redirect (in case of implicit grant) matches the expected value for

As discussed in the other thread. I do not consider the redirect_uri enforcement to be a reliable way to prevent abuse of existing authorizations.

> > since the previous one is sufficient.

Good point, I agree.

> > parameter matches the value in the user agent.

In my opinion, the mean you describe is complementary to the redirect_uri-based approach described in the text. Both can be used to detect session fixation attempts. The difference is that the redirect_uri-based appraoch relies on the authz server to detect the attack whereas the redirect_uri-based approach leaves the detection to the client.  

Would you please elaborate on how the state parameter prevents XSRF?

regards,
Torsten.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Breno <[email-masked]>
Date: Wed, 11 May 2011 22:57:32 -0700

On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten <
[email-masked]> wrote:

> This section shall document all assumptions determining the differences
> between those categories, which are relevant for the security sections. Thus
> I would like to keep it and probably improve it.
>

This may be a difference of opinion rather than substance, but I find that
assumptions stated too far ahead of their use suffer from lack of
connection. I would suggest again that the definition remain purely
semantic, and the security assumptions be discussed more closely to the
attending threats and mitigations.

> 1) This statement is intended to prohibit secrets for software packages and
> not software instances. Thus the text also says "An authorization server MAY
> issue a client secret for an installation of a native application on a
> specific device.". We just want to get rid of the bad practice of using
> secrets for authenticating software packages. This practice creates a false
> feeling of security and people tend to rely on this kind of client
> authentication too much. They shall be adviced to utilize other means than
> client secrets.
>

When the spec did define a Native App flow it mandated the opposite (the
secret was required not optional), which led Google, for instance, to launch
the OAuth2 registration for clients to include secret issuance for native
apps---against the recommendation of our internal security team---for pure
compliance reasons (not that we are relying on its remaining a secret, our
security model does not rely on this). I welcome the change of language
(even if we may take some time for Google to catch up with it), but find it
a bit too strong. Possibly "It is NOT RECOMMENDED ..." followed by some
description of why this is ineffective as a security measure?

> 2) The intention of the text is to give simple and clear rules instead of
> discussing "if", "then" and "why". This discussion is subject of the
> security threats and considerations I-D referenced by the introduction of
> the text.
>

Yes, and I am not suggesting it should -- my recommendation was to strike it
out. However, what about a softened approach as above?

> 3) DRM modules give you a device specific authentication, they do not
> authenticate a certain software package or instance.
>
> The description of how to implement native apps is badly missing right now
> and has been requested during IETF-80. It will be re-included soon.
>

That's welcome news indeed.

> As discussed in the other thread. I do not consider the redirect_uri
> enforcement to be a reliable way to prevent abuse of existing
> authorizations.
>

Google's experience with threat models on this space leads us to believe
that it can be effective in practice. Note that expansive variants of this
practice are not safe, e.g., domain matching versus full redirect URI
matching.

Note that:

- There is high value from the perspective of deployment flexibility to
support auto-approval in flows where the client cannot authenticate (e.g.,
user-agent);  and
- There is a class of existence of effective mitigation strategies: one of
these that is fully spec-compliant is full URL matching. Another is to use
non-HTTP transport such as windows.postMessage() for authenticated
cross-domain communication of the response. (You could consider that a case
of client authentication where the user-agent is the authority).

I believe that is quite important that we address this issue with a bit of
finesse. I understand that there is interest in not going into too much
detail into a security considerations section for a broadly applicable spec.
However this is a point where abstraction can easily change the threat
model/risk profile to the point where a security practitioner would reverse
their recommendation on usage. Taking the easy option here to use
categorical language may be counterproductive. It is perfectly appropriate
to issue guidance that one expects to be widely disregarded provided that
one is convinced that those ignoring the guidance will inevitably be putting
their services and/or their users at risk. However, I do not think this is
the case here. It is possible (or so I believe) to violate this guidance as
current stated and mitigate the risks appropriately.

> In my opinion, the mean you describe is complementary to the
> redirect_uri-based approach described in the text. Both can be used to
> detect session fixation attempts. The difference is that the
> redirect_uri-based appraoch relies on the authz server to detect the attack
> whereas the redirect_uri-based approach leaves the detection to the client.
>

They are complementary but not in an optional way. By that I mean that
_both_ types of measures must _always_ be applied.

The client cannot help the user agent against exploits where the attacker
abuses the inherent authority of the user agent (while acting on behalf of
the user), causing it to perform actions against itself in a confused
deputy-type scenario. That's the essence of an XSRF. The client is impotent
to help the user agent protect itself without explicit involvement by the
user agent.

> Would you please elaborate on how the state parameter prevents XSRF?

The state parameter can provide XSRF (which in turn is essential to prevent
session fixation attacks) as follows.

- Client or user-agent generates a secret.
- The secret is stored in a location accessible only by the client or the
user agent (i.e., protected by same-origin policy). E.g.: DOM variable
(protected by javascript or other DOM-binding language's enforcement of
SOP), HTTP cookie, HTML5 client-side storage, etc.
- The secret is attached to the state before a request is issued by the
client
- When the response is received, before accepting the token or code, the
client consults the user agent state and rejects the response altogether if
the state does not match the user agent's stored value.

Concrete example using HTTP cookies:

Client issues a 302 to the user agent with a Set-Cookie header with value
"XsrfToken1=$unguessable_random_number" and while simultaneously attaching
to the request the state parameter
"&state=XsrfToken1%3D$unguessable_random_number"

When the client receives the response from the authorization server, it
checks that such cookie is also visible.

Now, an attacker cannot perform a session fixation attack because it cannot
cause the user agent to modify its state in the same-domain-origin scope of
the client (if it could it would be game over as it could cause the user
agent to supply user credentials in most circumstances). Since it cannot
modify the user agent state, it cannot cause the user agent to succeed in
completing transactions with the client.

In the case of a web server application the client is a web server. In the
case of a user agent application the client is logic running within the user
agent (so instead of a 302 you would most likely have a window.location
reassignment and instead of a Set-Cookie header you would have a
reassignment of document.cookie). The principle is the same.

-- 
Breno de Medeiros