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.1See 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 <[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]>
To: Oleg Gryb <[email protected]>
Cc: "[email protected]" <[email protected]>; Liyu Yi <[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]> 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 <[email protected]>
To: Liyu Yi <[email protected]>; [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
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, 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]
https://www.ietf.org/mailman/listinfo/oauth
--
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
