... 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
