I'm hardly speaking with any authority here but my hope/expectation is that using Origin Only for the Referrer Policy would provide enough info in the referer (the origin) so as to not break search engines flows or other analytics that are using data from the referer header. The referring domain is provided, which is useful data, but without there query or path that often leaks sensitive data or tokens.
https://w3c.github.io/webappsec/specs/referrer-policy/ or http://www.w3.org/TR/referrer-policy/ is the work in progress on Referrer Policy. On Fri, Apr 10, 2015 at 5:37 PM, isciurus <isciu...@gmail.com> wrote: > I would also be interested to know about the possible response headers for > referrer (a draft?). Last time we brainstormed the problem with Brad Hill > we thought it could break something with search engines flow and referrer > policy. > > > I have tried to document the response headers that can help stop > leaking referrer. > > On Fri, Apr 10, 2015 at 4:08 PM, John Bradley <ve7...@ve7jtb.com> wrote: > >> Thanks, >> >> I have tried to document the response headers that can help stop leaking >> referrer. >> >> Being able to do the same thing to stop fragment leaking would be a good >> thing. >> >> If the W3C adds that then I would add it to our recommendations. >> >> In the Interim without browser support we may need to look at other >> methods to pass tokens to clients in the browser. >> >> I am certainly interested in tracking your proposal. >> >> John B. >> >> On Apr 10, 2015, at 4:00 PM, isciurus <isciu...@gmail.com> wrote: >> >> Hi, >> >> One of the recent drafts >> https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html >> was brought to my attention. Regarding the part "2.2. Security Compromise: >> The Authorization Server As Open Redirector": >> >> The legitimate OAuth Authorization response will include an access >> token in the URI fragment. >> Most web browsers will append the fragment to the URI sent in the >> location header of a 302 response if no fragment is included in the >> location URI. >> >> This browser behaviour with a url fragment reattaching is indeed used >> widely in attacks on OAuth (for example, one of the recent on the bitcoin >> exchange >> http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and >> I am also aware of one attack on OpenID 2 implementation leaking a valid >> signature using the same technique. >> We are trying to propose a browser-level protection from sensitive url >> fragment data reattach on cross-domain redirects: >> http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html >> A new header in the AS response would also block fragment reattach in the >> following scenario: >> >> https://AUTHORIZATION_SERVER/authorize?response_type=token >> <https://authorization_server/authorize?response_type=token> >> &client_id=good-client&scope=VALID_SCOPE >> &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize >> %3Fresponse_type%3Dcode >> %26client_id%3Dattacker-client-id >> %26scope%3DINVALID_SCOPE >> %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com >> >> But it would additionally block exploitation of vulnerable clients which >> have open redirects on their domains and don't whitelist their redirect_uri: >> >> https://AUTHORIZATION_SERVER/authorize?response_type=token >> <https://authorization_server/authorize?response_type=token> >> &client_id=good-client&scope=VALID_SCOPE >> &redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect >> %3Furl%3Dhttps%253A%252F%252Fattacker.com >> >> This can improve the situation with already deployed clients in large >> scale. Let me know if this proposal is interesting to the OAuth WG. >> >> Thanks, >> Andrey >> _______________________________________________ >> 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
