Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

Jim Manico <jim@manicode.com> Sun, 13 August 2017 16:37 UTC

Return-Path: <jim@manicode.com>
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 CE4B913254E for <oauth@ietfa.amsl.com>; Sun, 13 Aug 2017 09:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS_BASR4dsrN for <oauth@ietfa.amsl.com>; Sun, 13 Aug 2017 09:36:58 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F2D1321B7 for <oauth@ietf.org>; Sun, 13 Aug 2017 09:36:58 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id y129so32721485pgy.4 for <oauth@ietf.org>; Sun, 13 Aug 2017 09:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=d2+HeUBe1knYr2jLGu+W6Ur2kZOSLbdOWajZeqJRURI=; b=bLM5bBjjTt1aypFx8JIhfMVIe3xwv0yUJ3Y4bR9d0wWnUaMq3SzF6vY9qanlo7cFkh AT/bmIRG1yHfUDaxxEYMpO1VCfUbpc55qVFBHd/5O1zCR9QZxxL12kMqjJm6Z1K9/KGp ZWrrPxXIXt9vxMysNB76krWTP0l3CeG1kGFKqIaZrBqLFn+g0niVpFS0W+94MrEGV0pG YNfB7Ij20qRO74Pd8Vkr47XpbOagDKtNaWw+oUAt7YoRKdrcEaTXTyYPdX3lXOi5Pf8o EfJTOM1O1ShA1mnt1as4fdf3isAgD9cQe/3++rJPVQ/2ytrL2n8MxCV0AO6N+MPksWiY lrWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=d2+HeUBe1knYr2jLGu+W6Ur2kZOSLbdOWajZeqJRURI=; b=PTVOTlQW4vvrUZcomkFun4CdXGiIF2MjZ2vIe0U+kClWHCoA6x9vmv3W+5xIby9PIv hy/Kd2BShBXVxw2w+G8AOVpJormMcRZqhV/LyuOvNJRLdwcfOgA5KhScwCzP1bhrco04 uwWa0flh+WlxcmUNusRcRBB1aLtJzOAWA5jVjyZVNSg1IhsCriJlSaAFrevWelBvMQ+u 9AiMCx7o+0Pd1Zp6KYMsmQEzn+4OoVO3gZpu3NrqScCOYN/3BDwWQSS4BriYas2tgq08 2RK1o7bP1HZvsZq6n1t7OtKG2kYSZ6Ts5869N7c103PMitkmD+D4Tpsd8DchYcTZh0yr ROsw==
X-Gm-Message-State: AHYfb5jSNWlzr+BTt2XRGp8pVXXWc0UlUEJgUa+QS11N7P1zHStZyTIa JTvo3ZT2waKZ1STkaXE0VA==
X-Received: by 10.84.229.75 with SMTP id d11mr25022991pln.207.1502642218012; Sun, 13 Aug 2017 09:36:58 -0700 (PDT)
Received: from heembo.local (zipline.atenlabs.com. [206.251.244.230]) by smtp.googlemail.com with ESMTPSA id k4sm11710979pfk.26.2017.08.13.09.36.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 09:36:57 -0700 (PDT)
To: Thomas Broyer <t.broyer@gmail.com>, John Bradley <ve7jtb@ve7jtb.com>, Josh Mandel <jmandel@gmail.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
References: <CANSMLKFFGitCa6f5bqR=Ks-kqf_t=3poFwCMWTtJ=MyvNKUL3A@mail.gmail.com> <CANSMLKGV6O7rJJPtPxP44598rz-RXt4rqt0kGrvtUKsN2DD_jw@mail.gmail.com> <C1EC66B5-5171-4393-ABA5-C3B36C5FB9F4@ve7jtb.com> <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> <CAEayHEMwW4dTs_TXfWCKsQqiihRapf2GyWWiPdTUFBpRFVYt2w@mail.gmail.com>
From: Jim Manico <jim@manicode.com>
Message-ID: <24f0dd9a-4102-5dc7-b32c-fcb103f48c88@manicode.com>
Date: Sun, 13 Aug 2017 12:36:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAEayHEMwW4dTs_TXfWCKsQqiihRapf2GyWWiPdTUFBpRFVYt2w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------EA10A36F4BF8C1C43446A646"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EGY0jJS26ZHo80r5Bx-UOs17tjA>
Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Aug 2017 16:37:02 -0000

> Rejecting a GET with code in the URL means that the code is never
"used" at the AS, so can still be exchanged for an access token; and
rejecting the request does not mean it won't leak

That's a good point Thomas. I still think secure OAuth workflows should
totally avoid putting any kind of sensitive data in URI's for any step,
including POST /Actions/ that leak like a GET query parameter.

> So reject if you like from the user's point of view, but "consume" the
code anyway (and then immediately revoke the token, maybe), or you're
probably making things worse

Interesting point, but I think if the standard reflected this suggestion
it would be less likely that implementer will do it.

> (if you're worried of leaking 5min one-time codes, particularly when that code cannot be used without a client_secret
and/or PKCE code_verifier)

Also a good point. This specific step in the workflow might not be at
risk as much as other steps, but I see a LOT of folks putting sensitive
data in tokens and I'm trying to help avoid that leakage.

Thanks for your feedback.

Aloha, Jim


On 8/13/17 11:20 AM, Thomas Broyer wrote:
> Rejecting a GET with code in the URL means that the code is never
> "used" at the AS, so can still be exchanged for an access token; and
> rejecting the request does not mean it won't leak. So reject if you
> like from the user's point of view, but "consume" the code anyway (and
> then immediately revoke the token, maybe), or you're probably making
> things worse (if you're worried of leaking 5min one-time codes,
> particularly when that code cannot be used without a client_secret
> and/or PKCE code_verifier)
>
> Disclaimer: not a security expert here.
>
> Le sam. 12 août 2017 16:55, Jim Manico <jim@manicode.com
> <mailto:jim@manicode.com>> a écrit :
>
>     > The _*safest*_ thing for a client is to accept both. 
>
>     I politely (and strongly) disagree with this statement. The safest
>     thing for a client is to only accept POST or other verbs where any
>     kind of sensitive data is NOT kept in the URL. Sensitive data in
>     URL's leak like a sieve, even over HTTPS.
>
>     Respectfully,
>     Jim
>
>
>
>     On 8/11/17 3:18 PM, John Bradley wrote:
>>     OpenID Connect formally defined a POST response mode.
>>
>>     http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>
>>     The OAuth 2 spec docent preclude it.  
>>
>>     The safest thing for a client is to accept both.  
>>     The main advantages of POST is that it docent leak in the
>>     referrer, and can handle larger responses without the browser
>>     choking in some cases.
>>
>>     Size is more of an issue in Connect where a id_token may be
>>     returned in the front channel and POST allows for the larger
>>     response without the client needing to have JS extract the fragment.
>>
>>     That is why Connect defined it and OAuth largely assumes that for
>>     code get is OK.
>>     For security GET responses should add headers to prevent referrer
>>     from leaking the code.
>>
>>     We are adding advice on that to the Security document that is
>>     being updated now.
>>
>>     John B.
>>
>>
>>>     On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com
>>>     <mailto:jmandel@gmail.com>> wrote:
>>>
>>>     Fixing my "with this technique" url: it should have been
>>>     https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
>>>
>>>     On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com
>>>     <mailto:jmandel@gmail.com>> wrote:
>>>
>>>         Hi All,
>>>
>>>         I've just encountered a server that performs a redirect
>>>         (back to the client's redirect_uri) via POST instead of GET.
>>>         This was surprising behavior to me and broke my client
>>>         implementation — but citing chapter and verse, the server
>>>         developer pointed out
>>>         that https://tools.ietf.org/html/rfc6749#section-1.7 says 
>>>
>>>             While the examples in this specification show the use of
>>>             the HTTP 302 status code, any other method available via
>>>             the user-agent to accomplish this redirection is allowed
>>>             and is considered to be an implementation detail.
>>>
>>>
>>>         Is triggering a POST-based redirect (e.g. with this
>>>         technique
>>>         <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63%29>)
>>>         to the redirect_url (including url query parameters for
>>>         state and code) indeed considered a "method available via
>>>         the user-agent to accomplish this redirection"? In other
>>>         words, should a well-behaved OAuth client be prepared to
>>>         receive GETs as well as POSTs to its redirect_uri? If so,
>>>         what would be the considerations for a server choosing
>>>         between GET and POST?
>>>
>>>         Best,
>>>
>>>           Josh
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     -- 
>     Jim Manico
>     Manicode Security
>     https://www.manicode.com
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com