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

Eran Hammer-Lahav <> Wed, 14 September 2011 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D77A721F8C12 for <>; Wed, 14 Sep 2011 06:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fS65lLGdEjJ9 for <>; Wed, 14 Sep 2011 06:59:56 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id EEF9E21F8C10 for <>; Wed, 14 Sep 2011 06:59:55 -0700 (PDT)
Received: (qmail 20827 invoked from network); 14 Sep 2011 14:02:01 -0000
Received: from unknown (HELO ( by with SMTP; 14 Sep 2011 14:02:01 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([]) with mapi; Wed, 14 Sep 2011 07:01:53 -0700
From: Eran Hammer-Lahav <>
To: Torsten Lodderstedt <>
Date: Wed, 14 Sep 2011 06:59:47 -0700
Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Thread-Index: Acxy5Uxqq4O01wZBTpW3AoKm4C137AAARjzg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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> <> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 14 Sep 2011 13:59:56 -0000

Is this malicious piece of software external a native application either past of a native client or external to the browser?


> -----Original Message-----
> From: Torsten Lodderstedt []
> Sent: Wednesday, September 14, 2011 6:51 AM
> To: Eran Hammer-Lahav
> Cc: Niv Steingarten;
> 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