From b39e3ac57609b3d98764e5f0c814150930e8d186 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Thu, 10 Sep 2020 20:06:29 +0100 Subject: [PATCH 01/17] Hide Defensive Design Defense Article. --- content/docs/defenses/design-protections/defensive-design.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index 96ba9cddb..f9429e934 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -4,6 +4,7 @@ description = "" date = "2020-07-21" category = "defenses" menu = "main" +bookHidden = true +++ -TODO \ No newline at end of file +This section focus on defensive defensive design techniques used by companies to mitigate some XS-Leaks \ No newline at end of file From c3e70311cc6974d14f5dade4a2ac881b345127e7 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Thu, 10 Sep 2020 20:11:32 +0100 Subject: [PATCH 02/17] Add motivation contents for defensive desing tecniques. --- .../docs/defenses/design-protections/defensive-design.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index f9429e934..678b2d6ec 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -7,4 +7,9 @@ menu = "main" bookHidden = true +++ -This section focus on defensive defensive design techniques used by companies to mitigate some XS-Leaks \ No newline at end of file +This section should focus on defensive design techniques used by companies to prevent XS-Leaks from happening. This could be: + +- The way applications they use iframes to display information based on a user query (search system) +- How they use Fetch Metadata with Vary headers to prevent cache probing attacks +- How to ensure all application endpoints implement certain Headers to have the same behavior across different states. +- Strategies used by companies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. \ No newline at end of file From 35440c0c5e7987307afb37446daba3de55bc210e Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Thu, 10 Sep 2020 20:30:32 +0100 Subject: [PATCH 03/17] Change text for defensive design article. --- .../docs/defenses/design-protections/defensive-design.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index 678b2d6ec..ae6193fc4 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -7,9 +7,11 @@ menu = "main" bookHidden = true +++ -This section should focus on defensive design techniques used by companies to prevent XS-Leaks from happening. This could be: +This section should focus on defensive design techniques used by companies to prevent XS-Leaks from happening. Some ideas: - The way applications they use iframes to display information based on a user query (search system) -- How they use Fetch Metadata with Vary headers to prevent cache probing attacks +- How applications use Fetch Metadata with Vary headers to prevent cache probing attacks and what problems might occur with improper deployments. Are there any drawbacks of deploying this? - How to ensure all application endpoints implement certain Headers to have the same behavior across different states. -- Strategies used by companies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. \ No newline at end of file +- Quick strategies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. + +If you want to contribute please check https://github.com/xsleaks/wiki/issues/17 \ No newline at end of file From 024c4c25f926e0f1fd17bdf938ee063132a41b6a Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Mon, 14 Sep 2020 02:48:18 +0100 Subject: [PATCH 04/17] Add Subresource Protections article. --- .../design-protections/subresource-protections.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index eaa897594..07a5acda4 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -6,4 +6,13 @@ category = "defenses" menu = "main" +++ -TODO \ No newline at end of file + +The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html). The difference from CSRF protections is that in the case of XS-Leaks, only GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. + +## Deployment + +This protection might work in some scenarios but it has some disadvantages: + +- Hard to deploy as it requires substantial changes in the code base. It might break the desired behavior of the feature. +- It will break bookmarks, and other permanent references. + From 93c90a972980b22a8b3fd1745d882d28de344e24 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Mon, 14 Sep 2020 02:48:56 +0100 Subject: [PATCH 05/17] Fix grammar in Subresource Protections --- .../defenses/design-protections/subresource-protections.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 07a5acda4..f1c61e1d3 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -13,6 +13,6 @@ The principle of protecting subresources is the same as protecting endpoints fro This protection might work in some scenarios but it has some disadvantages: -- Hard to deploy as it requires substantial changes in the code base. It might break the desired behavior of the feature. -- It will break bookmarks, and other permanent references. +- Hard to deploy as it requires substantial changes in the codebase. It might break the desired behavior of the feature. +- It will break bookmarks and other permanent references. From 85f52f2b8f0b9bf8213d569cfa30ea4b9847bfd7 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Mon, 14 Sep 2020 02:50:08 +0100 Subject: [PATCH 06/17] Fix references in Subresource Protections --- .../docs/defenses/design-protections/subresource-protections.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index f1c61e1d3..245d982c0 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -7,7 +7,7 @@ menu = "main" +++ -The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html). The difference from CSRF protections is that in the case of XS-Leaks, only GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. +The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)is that in the case of XS-Leaks, only GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. ## Deployment From e4338dcc85cea51af3cefd7974acb8a5718fbd35 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Mon, 14 Sep 2020 03:19:34 +0100 Subject: [PATCH 07/17] Add more contents to sub resource protections. --- .../design-protections/subresource-protections.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 245d982c0..ebc2a757c 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -1,18 +1,27 @@ +++ title = "Subresource Protections" -description = "" +description = "Subresources Protections" date = "2020-07-21" category = "defenses" menu = "main" +++ -The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)is that in the case of XS-Leaks, only GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. +The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: + +- Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be rather more effective. +- Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario this protection can be highly effective. ## Deployment This protection might work in some scenarios but it has some disadvantages: -- Hard to deploy as it requires substantial changes in the codebase. It might break the desired behavior of the feature. +- Hard to deploy as it requires substantial changes in the codebase. +- It might break the desired behavior for the feature. - It will break bookmarks and other permanent references. +{{< hint warning >}} +This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy opt-in web platform security features as default approach. +{{< /hint >}} + + From c95f38ad50d3fe0da809af4e613f4a16b7c8e87c Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Mon, 14 Sep 2020 03:22:18 +0100 Subject: [PATCH 08/17] Fix links in Subresources Protections --- .../design-protections/subresource-protections.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index ebc2a757c..3c05d1227 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -9,19 +9,19 @@ menu = "main" The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: -- Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be rather more effective. -- Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario this protection can be highly effective. +- Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be rather more effective. +- Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective. ## Deployment -This protection might work in some scenarios but it has some disadvantages: +While this protection might work in some scenarios, it has some disadvantages: - Hard to deploy as it requires substantial changes in the codebase. - It might break the desired behavior for the feature. - It will break bookmarks and other permanent references. {{< hint warning >}} -This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy opt-in web platform security features as default approach. +This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy [opt-in web platform security features](https://TODO) as the default approach. {{< /hint >}} From 85c68206e670c3ca1dd8a3d252fa1cf004800037 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 15 Sep 2020 01:42:23 +0100 Subject: [PATCH 09/17] Add Facebook example in sub resource protections article. --- .../design-protections/subresource-protections.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 3c05d1227..93a9f0c7e 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -6,19 +6,24 @@ category = "defenses" menu = "main" +++ +### Random tokens -The principle of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: +One of the principles of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: - Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be rather more effective. - Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective. +### User Consent + +Some applications might ask for user consent to trigger a certain sensitive action. Facebook deploys this protection in some sensible search endpoints like `https://www.facebook.com/messages/?qa=UserMustConsent`, where a user musk press OK to advance with the search query. Since attackers can't surpass this verification, the page won't leak any special behavior. + ## Deployment While this protection might work in some scenarios, it has some disadvantages: - Hard to deploy as it requires substantial changes in the codebase. - It might break the desired behavior for the feature. -- It will break bookmarks and other permanent references. +- In the case of Random tokens, it will break bookmarks and other permanent references. {{< hint warning >}} This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy [opt-in web platform security features](https://TODO) as the default approach. From 1443c2b8adb626332b7366cf76a416fd9be79f02 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 22 Sep 2020 15:41:19 +0100 Subject: [PATCH 10/17] Update content/docs/defenses/design-protections/defensive-design.md Co-authored-by: Roberto Clapis --- content/docs/defenses/design-protections/defensive-design.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index ae6193fc4..1dab53ab2 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -7,11 +7,11 @@ menu = "main" bookHidden = true +++ -This section should focus on defensive design techniques used by companies to prevent XS-Leaks from happening. Some ideas: +This section should focus on defensive design techniques to prevent XS-Leaks from happening. Some ideas: - The way applications they use iframes to display information based on a user query (search system) - How applications use Fetch Metadata with Vary headers to prevent cache probing attacks and what problems might occur with improper deployments. Are there any drawbacks of deploying this? - How to ensure all application endpoints implement certain Headers to have the same behavior across different states. - Quick strategies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. -If you want to contribute please check https://github.com/xsleaks/wiki/issues/17 \ No newline at end of file +If you want to contribute please check https://github.com/xsleaks/wiki/issues/17 From aaeb3420b89bd46ef1255c5fc2f6afd82b61195b Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 22 Sep 2020 15:41:26 +0100 Subject: [PATCH 11/17] Update content/docs/defenses/design-protections/defensive-design.md Co-authored-by: Roberto Clapis --- content/docs/defenses/design-protections/defensive-design.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index 1dab53ab2..1031aab43 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -9,7 +9,7 @@ bookHidden = true This section should focus on defensive design techniques to prevent XS-Leaks from happening. Some ideas: -- The way applications they use iframes to display information based on a user query (search system) +- The way applications use iframes to display information based on a user query (search system) - How applications use Fetch Metadata with Vary headers to prevent cache probing attacks and what problems might occur with improper deployments. Are there any drawbacks of deploying this? - How to ensure all application endpoints implement certain Headers to have the same behavior across different states. - Quick strategies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. From 1a5934d2c5cd46de332c393966f3bff68c129766 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 22 Sep 2020 15:42:12 +0100 Subject: [PATCH 12/17] Update content/docs/defenses/design-protections/defensive-design.md Co-authored-by: Roberto Clapis --- content/docs/defenses/design-protections/defensive-design.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/defensive-design.md b/content/docs/defenses/design-protections/defensive-design.md index 1031aab43..fb8ff6953 100644 --- a/content/docs/defenses/design-protections/defensive-design.md +++ b/content/docs/defenses/design-protections/defensive-design.md @@ -12,6 +12,6 @@ This section should focus on defensive design techniques to prevent XS-Leaks fro - The way applications use iframes to display information based on a user query (search system) - How applications use Fetch Metadata with Vary headers to prevent cache probing attacks and what problems might occur with improper deployments. Are there any drawbacks of deploying this? - How to ensure all application endpoints implement certain Headers to have the same behavior across different states. -- Quick strategies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features. +- Quick strategies to mitigate reported XS-Leaks as a short-term solution before deploying web platform security features. If you want to contribute please check https://github.com/xsleaks/wiki/issues/17 From 35cdd6643feda9c13a5d2f27899a2d47cb31ac27 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 22 Sep 2020 15:43:31 +0100 Subject: [PATCH 13/17] Update content/docs/defenses/design-protections/subresource-protections.md Co-authored-by: Roberto Clapis --- .../defenses/design-protections/subresource-protections.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 93a9f0c7e..98ab8d596 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -10,7 +10,7 @@ menu = "main" One of the principles of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: -- Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be rather more effective. +- Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be cheaper to deploy and more effective. - Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective. ### User Consent @@ -29,4 +29,3 @@ While this protection might work in some scenarios, it has some disadvantages: This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy [opt-in web platform security features](https://TODO) as the default approach. {{< /hint >}} - From 8f331c25dd9bcdcd21ce6f22d962a1251957af83 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Tue, 22 Sep 2020 15:43:41 +0100 Subject: [PATCH 14/17] Update content/docs/defenses/design-protections/subresource-protections.md Co-authored-by: Roberto Clapis --- .../defenses/design-protections/subresource-protections.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 98ab8d596..470b6ad8e 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -8,7 +8,7 @@ menu = "main" ### Random tokens -One of the principles of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, mostly GET requests are the ones worth protecting. To apply this protection, applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: +One of the principles of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, GET requests are the ones usually worth protecting. To apply this protection applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: - Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be cheaper to deploy and more effective. - Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective. @@ -28,4 +28,3 @@ While this protection might work in some scenarios, it has some disadvantages: {{< hint warning >}} This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy [opt-in web platform security features](https://TODO) as the default approach. {{< /hint >}} - From c0f43dec9fd7395445e8fe2e1e6ccee2f8b3cfd6 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Fri, 25 Sep 2020 02:59:24 +0100 Subject: [PATCH 15/17] Add Rob suggestion about redirect consent pages. --- .../defenses/design-protections/subresource-protections.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index 470b6ad8e..d60f58265 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -17,6 +17,8 @@ One of the principles of protecting subresources is the same as protecting endpo Some applications might ask for user consent to trigger a certain sensitive action. Facebook deploys this protection in some sensible search endpoints like `https://www.facebook.com/messages/?qa=UserMustConsent`, where a user musk press OK to advance with the search query. Since attackers can't surpass this verification, the page won't leak any special behavior. +User Consent is often asked in applications to warn the user it's being redirected to a page **outside** of the current website. + ## Deployment While this protection might work in some scenarios, it has some disadvantages: @@ -24,6 +26,7 @@ While this protection might work in some scenarios, it has some disadvantages: - Hard to deploy as it requires substantial changes in the codebase. - It might break the desired behavior for the feature. - In the case of Random tokens, it will break bookmarks and other permanent references. +- Consent pages might add friction to using the application. {{< hint warning >}} This protection can be enough to fix attacks temporarily in certain scenarios. Due to the challenges of deploying this protection, applications are encouraged to deploy [opt-in web platform security features](https://TODO) as the default approach. From 18365a0a132fe440d2fb327e1274241a942b5741 Mon Sep 17 00:00:00 2001 From: Manuel Sousa Date: Fri, 25 Sep 2020 11:29:26 +0100 Subject: [PATCH 16/17] Small fix --- .../docs/defenses/design-protections/subresource-protections.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index d60f58265..c95c027ca 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -17,7 +17,7 @@ One of the principles of protecting subresources is the same as protecting endpo Some applications might ask for user consent to trigger a certain sensitive action. Facebook deploys this protection in some sensible search endpoints like `https://www.facebook.com/messages/?qa=UserMustConsent`, where a user musk press OK to advance with the search query. Since attackers can't surpass this verification, the page won't leak any special behavior. -User Consent is often asked in applications to warn the user it's being redirected to a page **outside** of the current website. +User consent is often asked in applications to warn the user it's being redirected to a website **outside** of the current website. This prevents attackers to [detect some type of navigations](https://TODO). ## Deployment From cad7dfa026e6b23c00fd62d8ecc03dd5a2c59523 Mon Sep 17 00:00:00 2001 From: Roberto Clapis Date: Sun, 27 Sep 2020 10:56:46 +0200 Subject: [PATCH 17/17] Update content/docs/defenses/design-protections/subresource-protections.md --- .../docs/defenses/design-protections/subresource-protections.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/defenses/design-protections/subresource-protections.md b/content/docs/defenses/design-protections/subresource-protections.md index c95c027ca..36aa9bd71 100644 --- a/content/docs/defenses/design-protections/subresource-protections.md +++ b/content/docs/defenses/design-protections/subresource-protections.md @@ -11,7 +11,7 @@ menu = "main" One of the principles of protecting subresources is the same as protecting endpoints from [CSRF attacks](https://owasp.org/www-community/attacks/csrf). The difference from [CSRF protections](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) is that in the case of XS-Leaks, GET requests are the ones usually worth protecting. To apply this protection applications can append a (cryptographically strong) pseudorandom value, unique to each request/session, to make the URL of a subresource unpredictable to an attacker. The protection can be applied to the following types of subresources: - Authenticated subresources such as API endpoints or regular authenticated URLs. While pseudorandom values can be used in this case, security mitigations like [Same-Site Cookies](https://TODO) can be cheaper to deploy and more effective. -- Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective. +- Unauthenticated subresources such as images can use this protection to prevent some types of [Cache Probing Attacks](https://TODO). In this scenario, this protection can be highly effective but it might hinder cache efficacy or be otherwise hard to deploy. ### User Consent