Subject: [OAUTH-WG] OAuth Tokens and URI's

From: Jim Manico <[email-masked]>
Date: Fri, 9 Dec 2016 20:54:47 +0100

Torsten,

The
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1
guide you are working on is a special kind of magic. Thank you for
taking the time to write this very important document.

When it comes to 2.2.1, I see your great suggestion to prevent referrer
leakage. These defenses are very important, and I appreciate how clearly
you laid these out.

But I think they skip the really core problem that web security
solutions must embrace - which I believe to be, /do not put sensitive
data in URL/GET parameters/. This goes all the way back to RFC 2616
#9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval" which I feel implies "should not
do anything dangerous" including transport sensitive data.

OAuth 2 goes pretty wild - all the way - with putting very sensitive
tokens in URIs/URLs and I have seen some solutions that break the
"standard" and POST/PUT/PATCH when they can, keeping tokens out of POST
actions, URL's and similar.  Is this worth discussing?

Thank you again for this very important and well written document.

Aloha from Hawaii,

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

---

From: Jim Manico <[email-masked]>
Date: Fri, 9 Dec 2016 20:58:43 +0100

... One more note. You mentioned in this section...

   o  Use form post mode instead of redirect for authorization response

.. This might be worth expanding on./Use form post and keep data OUT OF
THE ACTION/ (which is essentially the same as a GET). Safe transport of
tokens includes well configured HTTPS, POST and other verbs, and data
being the body of the request, not in the action of a form. Fair?

(And sorry, I missed this one the first time around)

Aloha, Jim

On 12/9/16 8:54 PM, Jim Manico wrote:
> When it comes to 2.2.1, I see your great suggestion to prevent
> referrer leakage. These defenses are very important, and I appreciate
> how clearly you laid these out.
>
> taking an action other than retrieval" which I feel implies "should
> not do anything dangerous" including transport sensitive data.
>
> "standard" and POST/PUT/PATCH when they can, keeping tokens out of
> POST actions, URL's and similar.  Is this worth discussing?
>

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