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.
On Apr 1, 2010, at 9:20 PM, Eran Hammer-Lahav wrote:
> Can you write this as an actual proposal for the text?
>
> EHL
>
>
> On 4/1/10 8:25 PM, "Brent Goldman" <br...@facebook.com> 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
>>
>>
>> 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>
>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
