Does this mean the RS effectively relies on the user agent to enforce the sender constraint (via CORS policy)?
> Am 23.11.2018 um 14:54 schrieb Neil Madden <neil.mad...@forgerock.com>: > > Thanks for doing this Daniel, I think the proposed text is good. > > — Neil > >> On 22 Nov 2018, at 14:42, Daniel Fett <danielf+oa...@yes.com> wrote: >> >> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
