Subject: [OAUTH-WG] redirect URI matching in section 3

From: Brian Eaton <[email-masked]>
Date: Sat, 10 Jul 2010 23:44:14 -0700

Section 3 says [[ provide guidance on how to perform matching ]].

I can write the guidance on performing redirect URI matching, but it
varies per profile.

User-Agent profile with registered client: matching is critical, MUST
verify is appropriate

Web server profile with client secret you trust: matching is not
critical.  Matching provides some extra security.  MAY is appropriate.
 MUST is really bad, since it prevents clients from moving redirect
URIs.

Any profile where you don't trust the client secret (e.g. installed
apps): Redirect URI matching is useless.  SHOULD NOT is appropriate.

So this is another case where the client needs to pass some indicator
to the server (either via type= parameter, or as policy associated
with client_id) of the environment in which it is running.  The type
parameter needs to signal:
- how the authorization server passes data (fragment or query string)
- what data is passed (access token, or just verification code)

Here's some proposed language on redirect URI matching.

New Section 3.1:  Overview of Callback URL Authentication

The OAuth 2 protocol distributes authorization credentials to
web-based applications by redirecting the user-agent to the client
with some form of authorization credential on the URL.  The
authorization credential is either an access token, or a authorization
code.  In either case, authenticating the URL to which the credential
is returned is critical to the security of the protocol.

Credentials returned on redirect URLs may leak in several ways:
- Referer headers sent by the browser to untrusted third-party web sites
- open redirectors
- web server log files
- browser history

Authorization servers have several techniques available for
authenticating callback URLs and defending against those leaks:
- using client authentication credentials to authenticate callback URLs
- callback URL white-listing
- passing authorization credentials on URI fragments
- issuing short-lived credentials to ease recovery in the event of compromise

3.1.1 Authorization Policy

In certain circumstances the Authorization Server is not able to
perfectly authenticate the callback URL.  For example, multiple
installed applications may use the same callback URL, and there is no
way for the Authorization Server to reliably distinguish among them.
Authorization Servers deal with this ambiguity by choosing different
policies on when to issue authorization credentials.

If the authorization server is able to authenticate the callback URL
with a high degree of confidence
- the authorization server MAY decline to prompt the user to grant
authorization, immediately rejecting the authorization request.
- the authorization server MAY issue an authorization credential after
prompting the user.
- the authorization server MAY issue a new authorization credential
without prompting the user, if the authorization server knows that the
user has previously approved this client.

If the authorization server is not able to authenticate the callback URL:
- the authorization server MAY decline to prompt the user to grant
authorization, immediately rejecting the authorization request.
- the authorization server MAY issue an authorization credential after
prompting the user.
- the authorization server MUST NOT issue an authorization credential
without prompting the user.

3.1.2 Callback URL Authentication Techniques

Client Credentials MAY be used to authenticate callback URLs.  If an
Authorization Server wishes to authenticate callback URLs with client
credentials, all of the following conditions MUST be met:

- the client credentials MUST have been issued to a web application
with a server-side component.
- the Authorization Server MUST believe that the client credentials
are stored securely.
- the Authorization Server MUST return only an authorization code to
the callback URL.  An access token MUST NOT be returned.

In all other circumstances, the Authorization Server MUST use callback
URL white-listing to authenticate callback URLs.  However, appropriate
callback URL white-listing varies for different client environments.

There are various techniques for callback URL white-listing.  The list
in this document is not exhaustive, and Authorization Servers MAY
implement other techniques at their discretion.  This document will
consider the following approaches:

- domain white-listing
   Authorization Servers white-list entire domains, e.g.
'*.example.com'.  Authorization servers may include the protocol in
this white-list, e.g. 'all https web sites on *.example.com'.  Any
page on any host in that domain is accepted.

- host white-listing
   Authorization Servers white-list entire hosts, e.g.
'www.example.com'.  Authorization servers may include the protocol in
the white-list, e.g. 'https://www.example.com'.  Any page on that host
is accepted.

- path white-listing
   Authorization Servers white-list specific paths on a particular
host, e.g. 'https://www.example.com/path'.  Any page beneath that path
is accepted.

- page white-listing
   Authorization Servers white-list a specific page on a particular
host, e.g. 'https://www.example.com/path/page'.  The query string and
URI fragment may vary, but all other components of the URL are fixed
and must match that page.

- full URL white-listing
   Authorization Servers white-list a specific URL, e.g.
'https://www.example.com/path/page?query'.  Any callback URL that does
not completely match that URL is rejected.

The following sections offer guidance to Authorization Servers and
Client developers on how to handle callback URL authentication.  For
better security, Authorization Servers and Clients should rely on a
combination of client credentials and callback URL white-listing to
authenticate callback URLs.

Section 3.1.3 Secure Callback URLs for the Web Server Profile

Client application developers using the web server profile should take
care that their callback URLs preserve the security of the profile.

Callback URL pages MUST NOT link or or redirect to untrusted content
from those pages, since the authorization code may leak in the referer
header.

Callback URL pages MUST NOT forward the authorization code to an untrusted page.

Callback URL pages SHOULD redirect to a trusted page immediately after
receiving the authorization code in the URL.  This prevents the
authorization code from remaining in the browser history, or from
inadvertently leaking in a referer header.

Callback URL pages SHOULD NOT log the authorization code.

Callback URL pages SHOULD be CSRF protected.  (TODO: dig up the
language in OAuth 1.0a, it was pretty good, I think...)

Section 3.1.4  Callback URL Authentication for the Web Server Profile

The web server profile returns an authorization code on the callback
URL.  Authorization codes returned on callback URLs are very prone to
leaking in referer headers, open redirectors, web server log files,
and browser history.

Authorization Servers MAY omit callback URL white-listing, but only if
they are using client credentials to authenticate callback URLs.  If
client credentials are being used, any type of callback URL
white-listing will improve security.

Different types of white-listing provide different levels of security.

- domain- and host- whitelisting
   Domain and host white-listing rules are very broad, and so are very
vulnerable to the leaks discussed in section 3.1.  Domain- and host-
white-listing MUST NOT be used alone.  Domain and host white-listing
MAY be used in combination with using client credentials to
authenticate callback URLs.

- path white-listing
   Path white-listing is somewhat broad, and may be vulnerable to the
leaks discussed in section 3.1.  Path white-listing MUST NOT be used
alone.  Path white-listing MAY be used in combination with using
client credentials to authenticate callback URLs.
    When using path white-listing, Authorization servers MUST defend
against directory traversal attacks by canonicalizing the path.
Appropriate path canonicalization algorithms vary for different types
of web-servers, e.g. "\..\" may represent a parent directory in some
web servers, and not in others.

- page and URL white-listing
   Page and URL white-listing are very specific, but may still be
vulnerable to some of the leaks discussed in section 3.1 if the
callback URL page does not follow the security recommendations in
section 3.1.3.  These types of white-listing MAY be used alone, or in
combination with client credentials to authenticate callback URLs.

   When full URL white-listing is used, Authorization Servers MUST
allow the "state" query parameter to vary.

Section 3.1.4 Secure Callback URLs for the User-Agent Profile

Client application developers using the user-agent profile should take
care that their callback URLs preserve the security of the profile.
Because the user-agent profile returns an access token on the URI
fragment, many types of leaks are less likely.  However, incorrect
code can still leak the authorization credentials.

Callback URL pages MUST NOT forward the access token or authorization
code to an untrusted page.

Callback URLs rendered in a top-level browser window cannot prevent
the access token from remaining in the browser history.  Whenever
possible, client applications SHOULD use an iframe to receive
callbacks so that the access token does not appear in the browser
history.  [[Note that Authorization Servers SHOULD NOT allow their
approval pages to be iframed due to the risk of click-jacking attacks,
so this only works for immediate mode.   Browser security gets
complicated.]]

If callback URLs must be rendered in a top-level browser window,
client applications SHOULD redirect immediately after receiving the
callback URL to remove the access token from the URL bar.   This
prevents the user from inadvertently copying their access token.

Callback URL pages SHOULD be CSRF protected.  (TODO: dig up the
language in OAuth 1.0a, it was pretty good, I think...)

Section 3.1.4  Callback URL Authentication for the User-Agent profile

Because the user-agent profile returns an access token on the callback
URL, client credentials cannot be used to authenticate the callback
URL.  Callback URL white-listing is the only possible way to
authenticate the callback URL.  However, because the authorization
credentials are always returned on the URL fragment, the opportunity
for leaking credentials via referer headers and open redirectors is
reduced.

Different types of white-listing provide different levels of security.

- domain- white-listing
   Domain white-listing is very broad.  Domain white-listing MUST NOT
be used, because of the risk of malicious code running under some host
in the domain.

- host- white-listing
   Host white-listing is very broad.  Authorization servers should be
conservative in choosing which hosts they trust, but host
white-listing MAY be used.

- path white-listing
   Path white-listing is somewhat broad.  Path white-listing MAY be used.
    When using path white-listing, Authorization servers MUST defend
against directory traversal attacks by canonicalizing the path.
Appropriate path canonicalization algorithms vary for different types
of web-servers, e.g. "\..\" may represent a parent directory in some
web servers, and not in others.

- page and URL white-listing
  Page and URL white-listing are very specific.  These types of
white-listing MAY be used

  When full URL white-listing is used, Authorization Servers MUST
allow the "state" query parameter to vary.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Jul 2010 13:22:05 -0700

This is a naïve questions:

Why not just say the server MUST match the redirection URI if one was previously registered, and require registration for user-agent clients?

EHL

On 7/10/10 11:44 PM, "Brian Eaton" <[email-masked]> wrote:

- domain white-listing

- host white-listing

- path white-listing

- page white-listing

- full URL white-listing

- path white-listing

- domain- white-listing

- host- white-listing

- path white-listing

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

---

From: Brian Eaton <[email-masked]>
Date: Sun, 11 Jul 2010 15:11:06 -0700

On Sun, Jul 11, 2010 at 1:22 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Why not just say the server MUST match the redirection URI if one was
> previously registered, and require registration for user-agent clients?

I don't know enough to be sure that's the right answer.  As far as I
can tell, the industry isn't converging on a solution, so I'm
reluctant to say MUST to anything.

I suspect the FB folks have the most experience with this kind of profile.