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

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 28 August 2011 17:14 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEB21F85BB for <oauth@ietfa.amsl.com>; Sun, 28 Aug 2011 10:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nzJ84uC3S7k for <oauth@ietfa.amsl.com>; Sun, 28 Aug 2011 10:14:10 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A921F861A for <oauth@ietf.org>; Sun, 28 Aug 2011 10:14:09 -0700 (PDT)
Received: from [79.253.27.149] (helo=[192.168.71.26]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1QxixD-0002bp-TN; Sun, 28 Aug 2011 19:15:27 +0200
Message-ID: <4E5A77B6.1030205@lodderstedt.net>
Date: Sun, 28 Aug 2011 19:15:34 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
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 <eran@hueniverse.com>
References: <b7df18688b7612cb85418ed587b80044@lodderstedt-online.de> <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmuoYO5NJrGNAHJsHennt_si+DTdA0QuLps8UBvMb=aLVoA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmuoJR2yFBBzjqT4nbGt28PDu4yFEYTnV9c893FAAuqvT+g@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmuqCx2Nv_OEAx30HZEqbx58zxhWweOMctaxp2E3S3rDWig@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmuoQuQGemjv0r2PzDBSD1D9XJjQo9cjZCs5-jxFbNc4JNA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmuo7yxuBKb4xU=cW3ESGvQ=PKpjSa2T9+=fUx-n5KYTLrQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E514770.7040405@lodderstedt.net>
In-Reply-To: <4E514770.7040405@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth