Re: [OAUTH-WG] WRAP session fixation?

Mike Malone <mjmalone@gmail.com> Mon, 30 November 2009 19:26 UTC

Return-Path: <mjmalone@gmail.com>
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 EC9923A6988 for <oauth@core3.amsl.com>; Mon, 30 Nov 2009 11:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 wDn875kDeQOM for <oauth@core3.amsl.com>; Mon, 30 Nov 2009 11:26:46 -0800 (PST)
Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 83AA03A6AD5 for <oauth@ietf.org>; Mon, 30 Nov 2009 11:26:46 -0800 (PST)
Received: by qyk13 with SMTP id 13so207522qyk.31 for <oauth@ietf.org>; Mon, 30 Nov 2009 11:26:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2XM5dU+mumSWD1r5GCDEuMAz231eP3DVvZeCQsOKDBY=; b=sLyn/U+kuOChH3wRGqqEUt4mi4ygEoy5EU+VJ8GBnVYw5CtMaNsuTpwnL0czUhXHLb 3Oq8z6I5Ef54zbrCKB+vzDMkaVmjUHphAy7cA78QWfFX7nV4P6Tp4uKpnKEl1iATiuPG PHKG+wuItV3L/z1vAI0MQdyxvda4cX9a6ZhgQ=
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:content-transfer-encoding; b=ZeFPLoyc/aZCx6+FV2/3gECxDi40yWFkjyNzrqbN+NV25WsSrp0fmeYNh9nGT/wI14 JlbLmqSO2L0AJB3yB6q7w69nvdKWQM+k1u0Xi3KzXQNjeG45Wf/5C10T70+aR4zD8GNU GxWJEKT2M1HkxJngu5vu6QlEo9HRzi8Yea4gQ=
MIME-Version: 1.0
Received: by 10.229.31.9 with SMTP id w9mr644223qcc.17.1259609195086; Mon, 30 Nov 2009 11:26:35 -0800 (PST)
In-Reply-To: <ED81D84D-0FB2-4976-8807-8724954C826A@facebook.com>
References: <daf5b9570911241758p35206df7xf7bf7f245087f726@mail.gmail.com> <C731D315.18C2C%lshepard@facebook.com> <daf5b9570911241817p3572e747gbc5e359b0bcd9df1@mail.gmail.com> <ED81D84D-0FB2-4976-8807-8724954C826A@facebook.com>
Date: Mon, 30 Nov 2009 11:26:35 -0800
Message-ID: <a9d9121c0911301126h45ac4524l73cfc167f217ab30@mail.gmail.com>
From: Mike Malone <mjmalone@gmail.com>
To: Brent Goldman <brent@facebook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Naitik Shah <naitik@facebook.com>, "oauth@ietf.org" <oauth@ietf.org>, Luke Shepard <lshepard@facebook.com>
Subject: Re: [OAUTH-WG] WRAP session fixation?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 30 Nov 2009 19:26:48 -0000

Interesting, but presumably if the callback is transferred securely
(e.g., if it's transmitted from the consumer with a signature) none of
this is really necessary. You'd probably want to blacklist some URI
schemes (like javascript:) but other than that as long as you can
verify that the consumer is sending the callback then what's wrong
with assuming it's legitimate?

Of course that doesn't work with Connect, since the browser-based flow
complicates things, but for OAuth I think formalizing more rigorous
rules for validating the callback isn't necessary.

Mike

On Wed, Nov 25, 2009 at 6:57 AM, Brent Goldman <brent@facebook.com> wrote:
> Facebook Platform/Connect has some pretty interesting logic involving
> registered callback URLs in our proprietary auth flows. Much of this is
> because we hate showing error messages. Maybe OAuth could borrow some of
> these ideas? Here's some more info.
> I'm using the terminology "specified callback URL" to refer to the callback
> URL specified in the request, and "registered callback URL" to refer to the
> callback URL configured with us in advance. There are two types of callback
> URLs that can be specified in a request: absolute and relative.
> Case 1. Specified callback URL is absolute.
> If the specified callback URL is "safe", we redirect to it. Otherwise,
> instead of throwing an error, we redirect to the registered callback URL,
> with the specified callback URL in a GET param called "next". It's up to the
> developer of the registered callback URL to use the "next" param, or they
> can just ignore it.
> To determine if the specified callback URL is safe: if the registered
> callback URL is a directory, then the specified callback URL has to be
> within that subdirectory. Otherwise, the specified callback URL has to point
> to the same file as the registered callback URL, and any query params on the
> registered callback URL have to also be present in the specified callback
> URL
> For example, if the registered callback URL is
> http://www.foobar.com/callback/, and the specified callback URL is
> http://www.foobar.com/callback/method2, we know the specified callback URL
> is safe and thus redirect directly there. But if the specified callback URL
> is http://www.facebook.com/logged-into-foobar, which is unsafe, we redirect
> to
> http://www.foobar.com/callback?next={urlencode(http://www.facebook.com/logged-into-foobar)}
> Note: we also support the concept of a "base domain", which essentially
> whitelists every page on that domain, and every page on all subdomains of
> that domain, as safe.
> Case 2. Specified callback URL is relative.
> In this case, there's no issue of safety, since we'll always redirect to a
> URL constructed based on the registered callback URL, which is by definition
> safe.
> More information about constructing the URL to redirect to:
> 2.1. If the registered callback URL doesn't have a question mark anywhere in
> it, we can just append the specified callback URL to it and redirect. For
> example, with a registered callback of http://www.foobar.com/callback/ and a
> specified callback URL of "loggedin.php?done=true", we redirect to
> http://www.foobar.com/callback/loggedin.php?done=true.
> 2.2 If the registered callback URL has a question mark, we append the
> specified callback URL directly, but do some munging to the params to get
> everything on the same level. For example, with a registered callback of
> "http://www.foobar.com/callback?page=" and a specified callback URL of
> "loggedin.php?done=true", we redirect to
> http://www.foobar.com/callback?page=loggedin.php&done=true (notice how the
> second ? changed to a &).
> Case 3. Unspecified callback URL.
> I lied, there's actually a third case. We support auth flows with
> unspecified callback URLs in the request. If there's a registered callback
> URL, we just redirect there. Otherwise, we show an error message. So
> basically the only way to get an error message is if there is no specified
> callback URL or registered callback URL.
> -Brent
>
> On Nov 24, 2009, at 6:17 PM, Brian Eaton wrote:
>
> On Tue, Nov 24, 2009 at 6:14 PM, Luke Shepard <lshepard@facebook.com> wrote:
>
> Yup, that’s basically what we do today- throw an error and don’t return. But
>
> this is less than ideal.
>
> We have discussed that we’d probably like to return, but with an error
>
> message. This would be in section 5.4.4 of the spec (“Authorization server
>
> directs user back to the client”) we would like to pass additional
>
> parameters for the error message- something other than user_denied, but
>
> which indicates that the application was just misconfigured.
>
> I guess it depends on the business requirements that led to callback
> URL preregistration.  Some sites require callback URL registration so
> they don't need to redirect to unknown third-party sites... in which
> case redirecting with an error message doesn't really fix the issue.
>
> Other sites require callback URL registration for security reasons, in
> which case an error message is just fine.
>
> Cheers,
> Brian
>
>