Subject: [OAUTH-WG] User Interface specs?

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 17:48:36 -0700

Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a
popup window to the user¹s Identity Provider for user to complete the
AuthZ/AuthN flow rather than taking the user away from the referring site
via a full page redirect.

In the case where a popup window is used, it¹s a very good idea to require
that that the browser¹s address bar is displayed, and that an independent
browser window is used, rather than an inline iframe. These requirements are
needed to help prevent the user from being phished in the case where the
user has to enter their password, and to ensure that the user¹s consent was
not forged via a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take
place within a popup window, so it would make sense to put into the core
spec that popups should be independent browser windows with the address bar
clearly displayed. 

Another missing feature in the core spec is support for multiple languages.
Given that many Service Providers have a global userbase, client
applications will want to have a way to specify the language to be used on
the auth screen. While the User Agent¹s Accept-Language: HTTP header, as
well as the user¹s IP address could be used as language hints, in practice
clients will want the ability to specify the language.

Is there consensus to get Popup Window requirements and language support
into the OAuth2 core spec?

Allen

---

From: Brent Goldman <[email-masked]>
Date: Thu, 1 Apr 2010 20:25:08 -0700

+1 on both

Regarding clickjacking: If we don't want the flows to be inlined in an iframe, specifying that the clients must show the server in a popup doesn't protect against malicious clients that choose to show it in an iframe anyway. So I think it also make sense to add to the core spec that servers should protect against this. The JavaScript is simple enough that perhaps the spec could give an example snippet that any OAuth server to use. E.g., if (top != self && !isTopWindowSafe(top)) { showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }.

-Brent

On Apr 1, 2010, at 5:48 PM, Allen Tom wrote:

Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a popup window to the user’s Identity Provider for user to complete the AuthZ/AuthN flow rather than taking the user away from the referring site via a full page redirect.

In the case where a popup window is used, it’s a very good idea to require that that the browser’s address bar is displayed, and that an independent browser window is used, rather than an inline iframe. These requirements are needed to help prevent the user from being phished in the case where the user has to enter their password, and to ensure that the user’s consent was not forged via a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take place within a popup window, so it would make sense to put into the core spec that popups should be independent browser windows with the address bar clearly displayed.

Another missing feature in the core spec is support for multiple languages. Given that many Service Providers have a global userbase, client applications will want to have a way to specify the language to be used on the auth screen. While the User Agent’s Accept-Language: HTTP header, as well as the user’s IP address could be used as language hints, in practice clients will want the ability to specify the language.

Is there consensus to get Popup Window requirements and language support into the OAuth2 core spec?

Allen
<ATT00001..txt>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:07:31 -0700

On 4/1/10 5:48 PM, "Allen Tom" <[email-masked]> wrote:

> AuthZ/AuthN flow rather than taking the user away from the referring site via
> a full page redirect.
> 
> needed to help prevent the user from being phished in the case where the user
> has to enter their password, and to ensure that the user¹s consent was not
> forged via a clickjacking attack.
> 
> place within a popup window, so it would make sense to put into the core spec
> that popups should be independent browser windows with the address bar clearly
> displayed. 

It certainly belongs in the security considerations section, but unless
there is a way for the server to enforce it, a MUST directive is pointless.
An attacker will obviously not comply...

> Given that many Service Providers have a global userbase, client applications
> will want to have a way to specify the language to be used on the auth screen.
> While the User Agent¹s Accept-Language: HTTP header, as well as the user¹s IP
> address could be used as language hints, in practice clients will want the
> ability to specify the language.
> 

Don't ask. Write a proposal and send to the list for each of these items
(don't spend time on editorial or language). I'll add it to the spec and
we'll see how well it fits in. At this stage we should be liberal in what we
include so we can get the full picture. Then we will decide what to drop or
spin-off.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:20:03 -0700

Can you write this as an actual proposal for the text?

EHL

On 4/1/10 8:25 PM, "Brent Goldman" <[email-masked]> wrote:

> +1 on both
> 
> Regarding clickjacking: If we don't want the flows to be inlined in an iframe,
> specifying that the clients must show the server in a popup doesn't protect
> against malicious clients that choose to show it in an iframe anyway. So I
> think it also make sense to add to the core spec that servers should protect
> against this. The JavaScript is simple enough that perhaps the spec could give
> an example snippet that any OAuth server to use. E.g., if (top != self &&
> !isTopWindowSafe(top)) {
> showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }.
> 
> -Brent
> 
> 
>> that popups should be independent browser windows with the address bar
>> clearly displayed.
>> 
>> will want to have a way to specify the language to be used on the auth
>> screen. While the User Agent¹s Accept-Language: HTTP header, as well as the
>> user¹s IP address could be used as language hints, in practice clients will
>> want the ability to specify the language.
>>

---

From: Brent Goldman <[email-masked]>
Date: Thu, 1 Apr 2010 23:01:13 -0700

7.1.1. Browser-Based Attacks

This section describes common attacks against OAuth flows involving web browsers, as well as protections against these attacks. The flows involving web browsers are the Web Callback Flow, the Web Client Flow, and the Device Flow.

7.1.1.1 Phishing

Phishing is the process of a malicious website attempting to acquire sensitive information such as usernames and passwords by masquerading as a trustworthy website. With regards to OAuth, an attacker could build a malicious website embedding a masquerade version of an OAuth Authorization Server to obtain the user's credentials. The attacker could then use these credentials to authorize any application on the user's behalf, essentially stealing the user's identity.

For a phishing attack to be successful, the user must voluntarily enter their credentials into the masqueraded site. It is difficult for a user to distinguish between a trustworthy site and a masqueraded version if the user cannot see the URL bar.

7.1.1.2. Clickjacking

Clickjacking is the process of a malicious website tricking the user into performing undesired actions (such as authorizing an OAuth flow), without the user realizing this is happening, by having the user click a button that appears to perform an innocuous function. In more detail, a malicious site loads the target site in a transparent iframe overlaid on top of a set of dummy buttons which are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an "Authorize" button) on the hidden page.

7.1.1.3. Protection

Both phishing and clickjacking attack vectors can be avoided by disallowing iframes.

OAuth clients SHOULD redirect to to the Authorization Server or show the Authorization Server in a popup window, and SHOULD NOT display the Authorization Server in an iframe. In the case that a popup window is used, the popup window MUST display the browser's address bar.

Since malicious clients will not comply with these recommendations, OAuth Authorization Servers SHOULD also enforce protection. It is not possible for the server to determine if a browser's address bar is displayed or not, but it is possible for the server to protect against being displayed in an iframe.

In newer versions of Internet Explorer, Safari, and Chrome, a page is prevented from being iframed if the HTTP header X-FRAME-OPTION is set to DENY. If this header is set to SAMEORIGIN, only sites with a different origin are blocked from iframing the site.

For older browsers not supporting X-FRAME-OPTION, a page can be prevented from being iframed using JavaScript. To determine if the site is being iframed, a site just needs to check that top != self. If this condition is true (and if the top URL is not trustworthy -- e.g., it's not owned by the same domain), the JavaScript should redirect to an error page explaining that the site should not be iframed. Other options include opening the same page in a popup window, or showing a large DIV with high z-index covering the entire screen, preventing any clicks from reaching the buttons underneath.

For browsers not supporting either X-FRAME-OPTION or JavaScript, a page cannot be prevented from being displayed in an iframe.