Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D0C3A6813 for ; Sat, 3 Jul 2010 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs+mJ0kQubIl for ; Sat, 3 Jul 2010 12:12:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 89B963A685A for ; Sat, 3 Jul 2010 12:12:21 -0700 (PDT) Received: by gxk3 with SMTP id 3so319419gxk.31 for ; Sat, 03 Jul 2010 12:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BeqpT8wg8LCgvREyjGijTpa2+pzB/J48Lt68ogdqll8=; b=RRyRSw5T+15DncWbrY2HQ8qu78hufsFCzKI41N5wqaDHMGzhUNissDNnb6MJJJzzc3 Xaiab52uQoIzteMZiHT19v1oLzghxADBso701e0vNGEmtMmS3OHCH3OFOxpjz4x3kGbT E/PozdzGpkazr+otgLMrwOxpMs81Fm1WIljig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=baxLQ//WtlAVFrgFAY7Kyv8XqOk4jtoD9/oMZeTePt6+0VrRQChy9FSI/JQ1z2WFrH NX/L7xP+Kktzdwv1ICj6eI9vqIMIZrtD2g2rKywHFO6cDdQEvI7Tb636eO+rTRvjxqtK 2LpZfbfXxZcDKG+9uwkNkpX0mtbyQ7nW2qNyo= MIME-Version: 1.0 Received: by 10.101.175.10 with SMTP id c10mr804648anp.192.1278184349567; Sat, 03 Jul 2010 12:12:29 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 12:12:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 3 Jul 2010 12:12:29 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c5bbf11d0cf5048a807cca Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:12:23 -0000 --001636c5bbf11d0cf5048a807cca Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wrote: > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In most cases, the redirection URI will simply include a > script that will pass the parameter to the **parent** window which can be > anything. If the server-based page is an active page, it still needs to > communicate with the user-agent, which again, can pretend to be that. > Good point. I wasn't imagining that far through it. Not to deny that most redirection URLs may just return a straight script that passes it to the parent window, but that seems pretty irresponsible to the host that's doing it -- because of the enormous security hole it opens up. Some client is trusted enough to authorize (by the user and auth server), receives an access token it wasn't expecting, and then blindly forwards it onto whoever wants it. Yikes. I sure hope these access tokens have *very* limited scope (like, I'd prefer none myself). I was about to describe how an active server could alleviate that by signing the original request using the state parameter, but I realized I'm solving a problem that the web server flow (or nowadays that the authorization code mode as I guess it's called) already solves. So I guess I just need to bite the bullet and accept that the user agent flow is *totally *insecure for web clients, and thus very special care must be taken to enable native clients without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really important to me as well -- I just am against doing it when it can't be secured in some way. Seriously... as is, once you authorize any client, you've authorized them all, including clients not even running on your computer. I guess this answers how I was visiting a site a few days ago and was amazed that it knew who I was (via Facebook) and was displaying my name and photo when I never logged into the site. I was shocked it knew who I was. Enter living in Incognito mode from now on. --001636c5bbf11d0cf5048a807cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:

You are putting too much= weight on the value of redirection URI registration. Since the same proble= m exists between the user-agent script and the server-side component used i= n the user-agent profile, anyone can imitate that flow. In most cases, the = redirection URI will simply include a script that will pass the parameter t= o the *parent* window which can be anything. If the server-based pag= e is an active page, it still needs to communicate with the user-agent, whi= ch again, can pretend to be that.

Good point. =A0I wasn't imagining that fa= r through it. =A0Not to deny that most redirection URLs may just return a s= traight script that passes it to the parent window, but that seems pretty i= rresponsible to the host that's doing it -- because of the enormous sec= urity hole it opens up. =A0Some client is trusted enough to authorize (by t= he user and auth server), receives an access token it wasn't expecting,= and then blindly forwards it onto whoever wants it. =A0Yikes. =A0I sure ho= pe these access tokens have very=A0limited scope (like, I'd pref= er none myself).

I was about to describe how an active server could alle= viate that by signing the original request using the state parameter, but I= realized I'm solving a problem that the web server flow (or nowadays t= hat the authorization code mode as I guess it's called) already solves.= =A0So I guess I just need to bite the bullet and accept that the user agen= t flow is totally insecure for web clients, and thus very special ca= re must be taken to enable native clients without opening up the web client= hole. =A0

Sorry to sound so negative about it. =A0Enabling this s= cenario seems really important to me as well -- I just am against doing it = when it can't be secured in some way. =A0Seriously... as is, once you a= uthorize any client, you've authorized them all, including clients not = even running on your computer. =A0I guess this answers how I was visiting a= site a few days ago and was amazed that it knew who I was (via Facebook) a= nd was displaying my name and photo when I never logged into the site. =A0I= was shocked it knew who I was. =A0Enter living in Incognito mode from now = on.
--001636c5bbf11d0cf5048a807cca--