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

Torsten Lodderstedt <> Sun, 28 August 2011 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBCEB21F85BB for <>; Sun, 28 Aug 2011 10:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6nzJ84uC3S7k for <>; Sun, 28 Aug 2011 10:14:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE7A921F861A for <>; Sun, 28 Aug 2011 10:14:09 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1QxixD-0002bp-TN; Sun, 28 Aug 2011 19:15:27 +0200
Message-ID: <>
Date: Sun, 28 Aug 2011 19:15:34 +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: <>
Content-Type: text/plain; charset="ISO-8859-1"; 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, 28 Aug 2011 17:14:10 -0000

no comments?

Am 21.08.2011 19:59, schrieb Torsten Lodderstedt:
> 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 thoughts:
> 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 CSRF.
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list