Hi all, I would like to discuss a text proposal for the security BCP.
Background: Yesterday, Neil pointed out the following problem with binding access tokens using mTLS or token binding in SPAs: "I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client." The problem is that a browser's TLS stack will attach the proof of possession no matter which origin started a request. (This seems like a real downside of token binding - why does it not have the "same site" option that cookies nowadays have?) I prepared the following addition to the security BCP and would like to hear your opinions: "It is important to note that constraining the sender of a token to a web browser (using a TLS-based method) does not constrain the origin of the script that uses the token (lack of origin binding). In other words, if access tokens are used in a browser (as in a single-page application, SPA) and the access tokens are sender-constrained using a TLS-based method, it must be ensured that origins other than the origin of the SPA cannot misuse the TLS-based sender authentication. The problem can be illustrated using an SPA on origin A that uses an access token AT that is bound to the TLS connection between the browser and the resource server R. If AT leaks to an attacker E, and there is, for example, an iframe from E's origin loaded in the web browser, that iframe can send a request to origin R using the access token AT. This request will contain the proof-of-posession of the (mTLS or token binding) key. The resource server R therefore cannot distinguish if a request containing a valid access token originates from origin A or origin E. If the resource server only accepts the access token in an Authorization header, then Cross-Origin Resource Sharing (CORS) will protect against this attack by default. If the resource server accepts the access tokens in other ways (e.g., as a URL parameter), or if the CORS policy of the resource server permits requests by origin E, then the TLS-based token binding only provides protection if the browser is offline." The "summary" above this text reads as follows: "If access tokens are sender-constrained to a web browser, the resource server MUST ensure that the access token can only be used by the origin to which the access token was issued (origin binding). One solution for the resource server to accomplish this is to only accept the access token in an Authorization header (as described in RFC 6750) and to ensure that the active CORS policy prevents third parties from sending Authorization headers. See <xref target="pop_tokens"/> for details." What do you think? -Daniel
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
