Hi,
I have few comments about leakage via third-party content, 'Referer'
header, Referrer-Policy and the underlying assumptions:
In the OAuth and OpenID good practices and specifications, I miss the use
of the 'Referer' header as a way to validate the origin of the calling
page. It seems to me that the current document ('oauth-security-topics') is
a great point to open this discussion.
The 'Referer' header value can be obtained by the client application from
the request in the backend and even in the frontend (through javascript -
`document.referrer`), since the first versions of the browsers. We
know that the concern is not about how the client application can get the
value of the referrer, but how to protect against leaking the authorization
parameters through this header. So, we have available the "Referrer-Policy"
specification. Referrer-Policy is already widely implemented, including in
not-so-modern browsers.
The draft-ietf-oauth-security-topics-21, Section 4.2 ("Credential Leakage
via Referer Headers"), discusses part of this issue. However, in Section
4.2.4 ("Countermeasures"), in the first measure, an example is cited,
indicating the use of "Referrer-Policy: no-referrer". I understand that
this is just an example about how to apply Referrer-Policy, but I suggest
encouraging the use of "Referrer-Policy: origin" instead of
"Referrer-Policy: no-referrer".
The use of "Referrer-Policy: origin" should not bring any security
breaches, as only the "schema://host:port" part of the referrer is passed
on, opening up another possibility of protection against CSRF when
validating this value (origin or site validations), mainly when using the
GET method.
========================================================================
Therefore, I suggest that in the first measure of Section 4.2.4, the text
be changed from:
4.2.4. Countermeasures
The page rendered as a result of the OAuth authorization response and
the authorization endpoint SHOULD NOT include third-party resources
or links to external sites.
The following measures further reduce the chances of a successful
attack:
* Suppress the Referer header by applying an appropriate Referrer
Policy [webappsec-referrer-policy] to the document (either as part
of the "referrer" meta attribute or by setting a Referrer-Policy
header). For example, the header Referrer-Policy: no-referrer in
the response completely suppresses the Referer header in all
requests originating from the resulting document.
To:
4.2.4. Countermeasures
The page rendered as a result of the OAuth authorization response and
the authorization endpoint SHOULD NOT include third-party resources
or links to external sites.
The following measures further reduce the chances of a successful
attack:
* Reduce the Referer header by applying an appropriate Referrer
Policy [webappsec-referrer-policy] to the document (either as part
of the "referrer" meta attribute or by setting a Referrer-Policy
header). For example, the header "Referrer-Policy: origin" in
the response will only inform the values of the scheme, host and
port on Referer header in all requests originating from the resulting
document.
========================================================================
Configuring the client application and the AS to inform the origin in the
Referer header should be considered a good practice, bearing in mind that
this could be very useful for applications to have one more validation
criterion to prevent the attacks described in:
- 4.1. Insufficient Redirect URI Validation
- 4.2. Credential Leakage via Referer Headers
- 4.4. Mix-Up Attacks
- 4.5. Authorization Code Injection
- 4.6. Access Token Injection
- 4.7. Cross Site Request Forgery
- 4.8. PKCE Downgrade Attack
- 4.10. Open Redirection
However, I am not aware of any reference to these practices in any OAuth
standard (RFC or OpenId). Perhaps it makes some sense, in addition to
commenting about these aspects in this document, to also start a new
document to specify the origin trust mechanisms, because, I believe , that
we will need to configure the usage of these policies through the Discovery
Endpoint metadata.
Best regards,
- Rodrigo Speller
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
