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 <[email protected]> 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 <[email protected]> > To: Oleg Gryb <[email protected]> > Cc: "[email protected]" <[email protected]>; Liyu Yi <[email protected]> > 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.2 > <https://tools.ietf.org/html/rfc7231#section-7.1.2>I > 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 <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 > <http://www.example.org/People.html#tim>” > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry > <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 > <http://www.example.net/index.html> > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry > <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/ > > <https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/> > > >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >> To: Oleg Gryb <[email protected] <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>; Liyu Yi <[email protected] >> <mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >>> We've discussed access tokens in URI back in 2010 >>> (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html >>> <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 <[email protected] <mailto:[email protected]>> >>> To: Liyu Yi <[email protected] <mailto:[email protected]>>; [email protected] >>> <mailto:[email protected]> >>> 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 Security >>> https://www.manicode.com <https://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 >>>> <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 list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> -- >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
