Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

Torsten Lodderstedt <> Sun, 21 August 2011 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D71D821F886A for <>; Sun, 21 Aug 2011 10:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z1VzPw59pKaI for <>; Sun, 21 Aug 2011 10:58:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0244021F8781 for <>; Sun, 21 Aug 2011 10:58:08 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1QvCIe-0003up-3d; Sun, 21 Aug 2011 19:59:08 +0200
Message-ID: <>
Date: Sun, 21 Aug 2011 19:59:12 +0200
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Eran Hammer-Lahav <>
References: <> <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Aug 2011 17:58:09 -0000

Hi Eran,
>>> This is still just a CSRF attack.
>> I think you may be right. I still believe this particular style of attack on the
>> authorization server is worth mentioning, be it in its own separate section or
>> under the existing CSRF section (as you suggested).
> This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit.
> I don't see any reason to include this new text based on this threat analysis.
> However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one).

I agree, we should explicitely document these two variants of CSRF 
(client, authz server). But I suspect it's not only CSRF we are talking 
about in this thread - at least not textbook CSRF. Let me explain my 

As far as I understood, in a textbook CSRF attack the attacker would 
create his own requests in order to abuse a user's session. This can be 
prevented by utilizing standard CSRF coutermeasures (page token, nounce, 
signature as parameter on every request URL), which bind URLs to a 
certain session.

But why should the attacker create requests et all? All he needs is 
already provided by the authorization server themselves. The malicious 
client can download the HTML pages comprising the authorization flow 
from the authz server and use the embedded URLs to issue the requests 
which normaly would have been issued by the resource owner herself 
(using the use agent indeed). It's more or less the push on a "I agree" 
button we are talking about. The authorization server may add a page 
token to the respective form URL. But it does not matter since the 
client just uses the authz server manufactured URL to post the form.

So let's assume the attacker has to programmatically handle HTML forms 
the authorization server delivers to the user agent. As you correctly 
pointed out, the pre-requisite for such an attack to succeed is that the 
resource owner must be authenticated somehow, e.g. based on a session 
cookie. Which also means, we are talking about clients running on the 
victim's device, within the user agent or as native app.

I see the following possible scenarios:

1) external system browser - The app could utilize an existing session 
within the system browser on the victim's device. It could then remote 
control a browser window, e.g. using low-level operating system messages 
("send mouse click") or component techniques such as ActiveX. There are 
tools available to create macros which automatically control and obtain 
data from such applications. So this should be feasible.

2) internal browser (cross-browser cookies) - If the authorization 
server uses cross-browser cookie techniques, such as flash cookies, the 
attacker could instantiate an internal (invisible) browser and try to 
utilize a session associated with such a cookie. I assume controlling 
such a browser instance will be even simpler then in (1).

3) internal browser (silent authz flow) - This is a scenario where the 
attacker is unable to abuse an existing session on the device. It could 
instead create an internal browser and perform an authorization flow 
with the resource owner for one particular scope. Using the same browser 
instance and based on the cookies obtained in the first run, it could 
silently perform additional authorization flows for other scopes.

4) internal browser (non-interactive authentication methods) - There are 
authentication methods available w/o the need for user-interaction, for 
examples SIM card authentication or certificate-based authentication. 
The attacker could utilize an internal, invisible browser instance in 
combination with such an authentication method in order to perform the 
authorization process.

I'm not sure whether the scenarios described above can be classified as