Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 14 September 2011 14:23 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 B6D7321F8B88 for <oauth@ietfa.amsl.com>; Wed, 14 Sep 2011 07:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 pwJZekug1OSr for <oauth@ietfa.amsl.com>; Wed, 14 Sep 2011 07:23:29 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7887221F8B06 for <oauth@ietf.org>; Wed, 14 Sep 2011 07:23:28 -0700 (PDT)
Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1R3qP8-0004qG-Ml; Wed, 14 Sep 2011 16:25:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Sep 2011 16:25:34 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Eran Hammer-Lahav <eran@hueniverse.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <fc9d72310a893cae84779b2c354463b0@lodderstedt-online.de> <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Message-ID: <f5f772c38f19a4e3417c01770829214c@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.5.2
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: 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: Wed, 14 Sep 2011 14:23:29 -0000
It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: > Is this malicious piece of software external a native application > either past of a native client or external to the browser? > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, September 14, 2011 6:51 AM >> To: Eran Hammer-Lahav >> Cc: Niv Steingarten; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> Hi Eran, >> >> >> 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. >> >> >A textbook CSRF attack is when an attacker constructs a URI and >> then >> >manipulate a user-agent with an active session to call that. In the >> >simplest example, an >attacker constructs a URI that transfers a >> >million dollars from the current account to its, then tricks the >> user >> >to click on that link or automatically >redirects the user to that >> URI. >> > Because the user is already signed in and has an active session >> token, >> >the request goes through. >> >> >To prevent it, the request URI must include an artifact that binds >> the >> >request to the active session. Since the attacker has no way of >> >accessing the session >information, it cannot construct as a URI. >> In >> >practice, this means adding a hidden form parameter to the button >> with >> >some hash of the session information >that the server can verify. >> >> So I would conclude we have the same understanding of what CSRF >> means. >> >> >> 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. >> >> >Of course it matters. >> >> >The only way the attacker can get access is by calling the 'I >> agree' >> > button action via an active user session. The attacker cannot >> access >> >the hidden form >value with the session hash (or whatever the >> server is >> >using for CSRF protection). So whatever URI it constructs will not >> work >> >when called with the active >user session. >> >> My point is: the attacker in the threat I'm trying to describe does >> not need to >> create any URL since it just remote controls the user-agent. The >> malicous >> code runs outside of the browser and "just" uses the URLs provided >> by the >> authz server. Yes, there need to be a session. No, the attacker does >> not >> need to inject any URL he made up. >> >> >> 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. >> >> >I'm having a hard time following all these scenarios. But the >> >important part is that OAuth assumes the 'user-agent' is a >> compliant >> >and secure web browser. If >the user-agent does not enforce cookie >> >boundaries, XSS, CORS policy, etc. there isn't much we can do. In >> other >> >words, if the user installs a poorly design >native application >> which >> >has its own user-agent implementation opened to known web attacks, >> all >> >bets are off. >> > >> >The security model behind all these is pretty simple. The active >> user >> >session has to be protected from any external access by attackers >> and >> >enforce same-origin policy. >> >> What didn't you understand? I would be happy to improve my >> description. >> What I basically try to get across: a malicious piece of software >> running on the >> resource owners device can simulate her consent. As a pre-requisite >> the >> attacker must be able to either abuse an existing session or to >> create a new >> one. I gave four examples of how this could be achieved. At least >> the last has >> obviously nothing to do with browser security features. The threat >> also has >> nothing to do with poor design or user-agent implementation flaws. >> It is a >> deliberate attack against the resource owner. >> >> One could argue that prevention of malicous software is not the >> responsibility of the authz server. I could agree with that. But >> people seem to >> expect an OAuth authz server to cope with such attacks. That's why I >> believe >> we either clearly draw this boundary in the spec or give a hint on >> how to >> prevent this kind of threat. >> >> regards, >> Torsten. >> >I still don't see the need to add the proposed section. >> >> >EHL >> >> >>
- [OAUTH-WG] Draft 20 last call comment (Resource O… Torsten Lodderstedt
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Barry Leiba
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Lodderstedt, Torsten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Igor Faynberg
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Barry Leiba
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Barry Leiba
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… William J. Mills
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… William J. Mills
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Niv Steingarten
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… William J. Mills
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Torsten Lodderstedt
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Torsten Lodderstedt
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Torsten Lodderstedt
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Torsten Lodderstedt
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Eran Hammer-Lahav
- Re: [OAUTH-WG] Draft 20 last call comment (Resour… Torsten Lodderstedt