From 776a156f18527511982ff33f8955a67989a549ee Mon Sep 17 00:00:00 2001 From: Filip Skokan Date: Sat, 17 Feb 2024 10:15:09 +0100 Subject: [PATCH 1/6] more silent frame edits --- draft-ietf-oauth-browser-based-apps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index 9dbc854..1b19867 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -996,7 +996,7 @@ The scenario where the attacker obtains a fresh set of tokens (See {{payload-new For completeness, this BCP lists a few options below. Note that none of these defenses are recommended, as they do not offer practically usable security benefits. -The authorization server could block authorization requests that originate from within an iframe. While this would prevent the exact scenario from {{payload-new-flow}}, it would not work for slight variations of the attack scenario. For example, the attacker can launch the silent flow in a popup window, or a pop-under window. Additionally, browser-only OAuth 2.0 clients typically rely on a silent frame-based flow to bootstrap the user's authentication state, so this approach would significantly impact the user experience. +The authorization server could block authorization requests that originate from within an iframe. While this would prevent the exact scenario from {{payload-new-flow}}, it would not work for slight variations of the attack scenario. For example, the attacker can launch the silent flow in a popup window, or a pop-under window. Additionally, browser-only OAuth 2.0 clients typically rely on a hidden iframe-based flow to bootstrap the user's authentication state, so this approach would significantly impact the user experience. The authorization server could opt to make user consent mandatory in every Authorization Code flow (as described in Section 10.2 OAuth 2.0 {{RFC6749}}), thus requiring user interaction before issuing an authorization code. This approach would make it harder for an attacker to run a silent flow to obtain a fresh set of tokens. However, it also significantly impacts the user experience by continuously requiring consent. As a result, this approach would result in "consent fatigue", which makes it likely that the user will blindly approve the consent, even when it is associated with a flow that was initialized by the attacker. @@ -1405,7 +1405,7 @@ Security of In-Browser Communication Flows {#in_browser_communication_security} -------------------------------------- In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window. -In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. +In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run hidden iframe-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a. {{WebMessaging}}) instead of top-level redirections. To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in {{WebMessaging}}). From a5d36325c7b28d93a28aae723ea7536494815e0c Mon Sep 17 00:00:00 2001 From: damienbod Date: Sun, 18 Feb 2024 08:21:20 +0100 Subject: [PATCH 2/6] initial draft --- draft-ietf-oauth-browser-based-apps.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index 9dbc854..c731834 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -499,6 +499,13 @@ To avoid such bypasses against the CORS policy, the BFF SHOULD require that ever It is also possible to deploy the JavaScript application on the same origin as the BFF. This ensures that legitimate interactions between the frontend and the BFF do not require any preflights, so there's no additional overhead. +##### Use Anti-forgery/double submit cookies + +Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. When implemented correctly, it provides an extra layer of protection against Cross-Site Request Forgery. The cookie is validated for all state changing requests. + +The anti-forgery cookie should be encrypted and apply the SameSite=Strict attribute to the cookie. The cookie should be connected to the session and different for each session. The session should use HTTPS. + + #### Advanced Security In the BFF pattern, all OAuth responsibilities have been moved to the BFF, a server-side component acting as a confidential client. Since server-side applications are more powerful than browser-based applications, it becomes easier to adopt advanced OAuth security practices. Examples include key-based client authentication and sender-constrained tokens. From df048fbf7e541373f5758b88704b62fa49bc9233 Mon Sep 17 00:00:00 2001 From: damienbod Date: Sun, 18 Feb 2024 08:25:43 +0100 Subject: [PATCH 3/6] capital --- draft-ietf-oauth-browser-based-apps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index c731834..375dbaa 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -499,7 +499,7 @@ To avoid such bypasses against the CORS policy, the BFF SHOULD require that ever It is also possible to deploy the JavaScript application on the same origin as the BFF. This ensures that legitimate interactions between the frontend and the BFF do not require any preflights, so there's no additional overhead. -##### Use Anti-forgery/double submit cookies +##### Use anti-forgery/double submit cookies Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. When implemented correctly, it provides an extra layer of protection against Cross-Site Request Forgery. The cookie is validated for all state changing requests. From b1a013ac5afcdcd59a0468cae15279bb594b4fab Mon Sep 17 00:00:00 2001 From: damienbod Date: Sun, 18 Feb 2024 11:51:56 +0100 Subject: [PATCH 4/6] update feedback Philippe --- draft-ietf-oauth-browser-based-apps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index 375dbaa..4755315 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -501,9 +501,9 @@ It is also possible to deploy the JavaScript application on the same origin as t ##### Use anti-forgery/double submit cookies -Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. When implemented correctly, it provides an extra layer of protection against Cross-Site Request Forgery. The cookie is validated for all state changing requests. +Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. This mechanism relies on a session-specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie. The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identity legitimate requests. When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. -The anti-forgery cookie should be encrypted and apply the SameSite=Strict attribute to the cookie. The cookie should be connected to the session and different for each session. The session should use HTTPS. +Note that this mechanism is not necessarily recommended over the CORS approach. However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. #### Advanced Security From 7831ad2b4eb688a846ddc8a22aed592f895ed120 Mon Sep 17 00:00:00 2001 From: damienbod Date: Sun, 18 Feb 2024 11:54:45 +0100 Subject: [PATCH 5/6] grammer --- draft-ietf-oauth-browser-based-apps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index 4755315..ea92834 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -501,7 +501,7 @@ It is also possible to deploy the JavaScript application on the same origin as t ##### Use anti-forgery/double submit cookies -Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. This mechanism relies on a session-specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie. The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identity legitimate requests. When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. +Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies. This mechanism relies on a session-specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie. The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identify legitimate requests. When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. Note that this mechanism is not necessarily recommended over the CORS approach. However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. From 582bffee22cf09e0889d634f6bff0eb7d683d04c Mon Sep 17 00:00:00 2001 From: Philippe De Ryck Date: Sun, 18 Feb 2024 12:50:29 +0100 Subject: [PATCH 6/6] Moved new section on in-browser flows The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern. --- draft-ietf-oauth-browser-based-apps.md | 27 ++++++++++++-------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/draft-ietf-oauth-browser-based-apps.md b/draft-ietf-oauth-browser-based-apps.md index 9dbc854..e774913 100644 --- a/draft-ietf-oauth-browser-based-apps.md +++ b/draft-ietf-oauth-browser-based-apps.md @@ -878,6 +878,18 @@ Authorization servers MUST require an exact match of a registered redirect URI as described in {{oauth-security-topics}} Section 4.1.1. This helps to prevent attacks targeting the authorization code. + +##### Security of In-Browser Communication Flows {#in_browser_communication_security} + +In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window. +In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. + +If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a. {{WebMessaging}}) instead of top-level redirections. +To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in {{WebMessaging}}). + +Section 4.18. of {{oauth-security-topics}} provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. + + ##### Cross-Site Request Forgery Protections {#pattern-oauth-browser-csrf} Browser-based applications MUST prevent CSRF attacks against their redirect URI. This can be @@ -1400,21 +1412,6 @@ and the countermeasures mentioned above. - -Security of In-Browser Communication Flows {#in_browser_communication_security} --------------------------------------- - -In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window. -In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. - -If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a. {{WebMessaging}}) instead of top-level redirections. -To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in {{WebMessaging}}). - -Section 4.18. of {{oauth-security-topics}} provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. - - - - IANA Considerations {#iana} ===================