For Jim's comment "HTTP POST requests are also a lot more difficult to cache server side compared to URI's which are easier to cache. I'm likely not explaining this well, but I believe it's a webscale concern."
I would say, most of the OAuth case will be using HTTPS. and caching with HTTPS is only possible at the end point where SSL/TLS is terminated. when it goes to the server side, it is all about turning the post data to the cache key, some logic is required, but does this have a serious performance issue? However, I do realized that if fetching the resource is implemented as a POST, the POST response is typically not cached. For this, we might be able to use the POST to establish HTTP session and then use the GET to fetch the resource, and with right logic to control the caching behavior. BTW, caching itself also has security implication. On Fri, Jul 1, 2016 at 3:44 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote: > I'm aware about exploits related to improper redirect_url validation, > which was FB case, no qs here, but I still can't understand if appending a > fragment to Location by a browser makes this exploit simpler or can lead to > other exploits that have not been described yet. > > > ------------------------------ > *From:* John Bradley <ve7...@ve7jtb.com> > *To:* Oleg Gryb <o...@gryb.info> > *Cc:* "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liy...@gmail.com> > *Sent:* Friday, July 1, 2016 2:21 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > If the attacker can modify the redirect URI to anything like an embedded > add that will do a 302 redirect then the recipient of the redirect can load > JS to extract the access token. > > This has happened at Facebook so many times I have lost count. It is not > theoretical, it happens all the time. > One reason you need to do exact redirect_uri matching in the AS but people > are not so good at following that and take redirects to any URI on the host > in some cases. > > When used correctly for a real in web client it is fine. For a web server > client it introduces unnecessary risks over the code flow, or hybrid flow > using POST. > > Others may differ with my opinion. > > John B. > > On Jul 1, 2016, at 4:52 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote: > > John, > > Thanks, very useful. However, I'm still trying to figure out why it's > dangerous. Fragment doesn't travel to a server in this new flow either. > Appending it to Location header is done by the browser who needs to > memorize what the original request was. If the original request had a > fragment and the browser got redirected, Location header will be appended > by the browser. > > Are you saying that this is dangerous because the browser would *always* > need to store the fragment somewhere in its memory just in case if a server > decides to redirect? > > So an attack vector here is that an imposter can try to retrieve the > fragment from the browser's memory somehow. Is my understanding correct? > > Oleg. > > > ------------------------------ > *From:* John Bradley <ve7...@ve7jtb.com> > *To:* Oleg Gryb <o...@gryb.info> > *Cc:* "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liy...@gmail.com> > *Sent:* Friday, July 1, 2016 11:33 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim"; might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim” > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry"; might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry";, preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was when > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico <j...@manicode.com> > *To:* Oleg Gryb <o...@gryb.info> > *Cc:* "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liy...@gmail.com> > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was when > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in some > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak, > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico <j...@manicode.com> > *To:* Liyu Yi <liy...@gmail.com>; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn’t it be more secure if we change to use a post method for > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one question > arises from our engineers. > We noticed at <https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30> > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user without > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in library, > or for an IT staff who works on other employee’s computer. > > Shouldn’t it be more secure if we change to use a post method for access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
