... 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:
> 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
--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
