From a2e02c2e8cff0216e6763769b32c7c9c7c9a5a24 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Tue, 19 Mar 2024 06:43:42 -0600 Subject: [PATCH 1/4] initial draft Co-authored-by: Ted Thibodeau Jr --- .gitignore | 2 ++ biblio.json | 16 +++++++++ index.bs | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++ logo.include | 3 ++ 4 files changed, 117 insertions(+) create mode 100644 .gitignore create mode 100644 biblio.json create mode 100644 index.bs create mode 100644 logo.include diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3432c3f --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +*.html + diff --git a/biblio.json b/biblio.json new file mode 100644 index 0000000..f8df2f2 --- /dev/null +++ b/biblio.json @@ -0,0 +1,16 @@ +{ + "Community.Solid.Server": { + "authors": [ + "Joachim Van Herwegen" + ], + "href": "https://communitysolidserver.github.io/", + "title": "Community Solid Server" + }, + "SolidOS": { + "authors": [ + "Timea Turdean" + ], + "href": "https://solidos.solidcommunity.net/", + "title": "SolidOS" + } +} diff --git a/index.bs b/index.bs new file mode 100644 index 0000000..e413933 --- /dev/null +++ b/index.bs @@ -0,0 +1,96 @@ +
+Title: Solid Security Best Current Practice
+Boilerplate: issues-index no
+Boilerplate: omit conformance
+Local Boilerplate: logo yes
+Shortname: solid-best-security-practice
+Level: 1
+Status: w3c/CG-DRAFT
+Group: Solid Community Group
+Favicon: https://solidproject.org/TR/solid.svg
+ED: https://solid.github.io/specification/security-best-practice
+TR: https://solidproject.org/TR/security-best-practice
+!Created: Feb 20, 2024
+!Modified: [DATE]
+!Editor's Draft: [https://solid.github.io/specification/security-best-practice](https://solid.github.io/specification/security-best-practice)
+Repository: https://github.com/solid/security-best-practice
+Inline Github Issues: title
+Markup Shorthands: markdown yes
+Max ToC Depth: 2
+Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net/)
+Metadata Order: This version, Latest published version, Editor's Draft, Test Suite, Created, Modified, *, !*
+Metadata Include: Editor's Draft off
+Abstract:
+  This document describes best current security practice for OAuth 2.0.
+Status Text:
+  This section describes the status of this document at the time of its publication.
+
+  This document was published by the [Solid Community Group](https://www.w3.org/community/solid/) as
+  an Editor’s Draft. The information in this document is
+  still subject to change. You are invited to [contribute](https://github.com/solid/solid-oidc/issues)
+  any feedback, comments, or questions you might have.
+
+  Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft
+  document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate
+  to cite this document as other than work in progress.
+
+  This document was produced by a group operating under the [W3C Community Contributor License Agreement
+  (CLA)](https://www.w3.org/community/about/process/cla/). A human-readable
+  [summary](https://www.w3.org/community/about/process/cla-deed/) is available.
+
+ +# Attacks and Mitigations # {#attacks-and-mitigations} + +## Serving user-created files ## {#serving-user-created-files} + +The attacker can be an agent with a WebID or an application. They need append/write access to the user's server +to store a malicious HTML file, e.g., because the user allowed them to write a blog post, +or they have their own storage in a different path on the same domain. + +Impact of both scenarios: The attacker, pretending to be the victim, can access anything +that the victim's account can access. + + +### Use Solid-OIDC DPoP-bound ID tokens to make authenticated requests + +#### Prerequisites + +* The attacker has append/write access to a publicly readable folder/file on the server +* The server serves [[SolidOS]] under the same domain (by default, [[Community.Solid.Server]] serves everything under the same domain) +* The victim is logged in via [[SolidOS]], so opening it automatically logs in again + +#### Attack + +The attacker writes a malicious `text/html` file to the server. When this file is opened by the user: + +* It opens [[SolidOS]] in a new tab and saves the window reference (iirc, opening any non-existing resource from the server returns [[SolidOS]]) +* [[SolidOS]] automatically logs in, as the user logged in there previously +* The `text/html` file can access [[SolidOS]] via the window reference, including the authenticated fetch +* The `text/html` file can make any requests through this authenticated fetch in the name of the currently logged-in user + + +### Steal login credentials + +#### Prerequisites + +* The attacker has append/write access to a publicly readable folder/file on the server +* The victim uses the IDP of the (small) [[Community.Solid.Server]] server +* The storages are on the same domain as the IDP (default for [[Community.Solid.Server]]) +* The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]]) via the browser or a password manager extension + + +#### Attack: The attacker writes a malicious `text/html` file to the server. Depending on the application used to store the login credentials, the concrete autofill/suggestion behaviour can vary. For instance, if the user saved it with Chrome and opens the malicious file: + +* The victim performs any interaction with the site (e.g., clicking on a cookie banner) +* Chrome automatically fills in `` fields for the user name and password with the saved credentials +* The malicious `text/html` file can read and send the credentials to the attacker +* The attacker can use it to login with the IDP of the victim + + + +### Countermeasures ### {#serving-user-created-files-countermeasures} + +Servers are encouraged to apply security measures when serving user-created files. +Multiple agents can create files on the same server, which could render same-origin security boundaries useless. +As an example countermeasure, servers could add a `Content-Security-Policy: sandbox` +header to artificially enable same-origin security policies for files on the same origin. diff --git a/logo.include b/logo.include new file mode 100644 index 0000000..a107eb9 --- /dev/null +++ b/logo.include @@ -0,0 +1,3 @@ + From e9d624dc08ee14b0429b269a7cef2049a9a1dcfc Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Tue, 19 Mar 2024 09:27:21 -0600 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- index.bs | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index e413933..6af1d17 100644 --- a/index.bs +++ b/index.bs @@ -43,9 +43,9 @@ Status Text: ## Serving user-created files ## {#serving-user-created-files} -The attacker can be an agent with a WebID or an application. They need append/write access to the user's server -to store a malicious HTML file, e.g., because the user allowed them to write a blog post, -or they have their own storage in a different path on the same domain. +An attacker could be an agent with a WebID or an application. They need append/write access to the user's server +to store a malicious HTML file. They might have this access because the user allowed them to write a blog post, +or because they have their own storage in a different path on the same domain. Impact of both scenarios: The attacker, pretending to be the victim, can access anything that the victim's account can access. @@ -57,13 +57,13 @@ that the victim's account can access. * The attacker has append/write access to a publicly readable folder/file on the server * The server serves [[SolidOS]] under the same domain (by default, [[Community.Solid.Server]] serves everything under the same domain) -* The victim is logged in via [[SolidOS]], so opening it automatically logs in again +* The victim is logged in via [[SolidOS]], so any new session is automatically logged in again #### Attack The attacker writes a malicious `text/html` file to the server. When this file is opened by the user: -* It opens [[SolidOS]] in a new tab and saves the window reference (iirc, opening any non-existing resource from the server returns [[SolidOS]]) +* It opens [[SolidOS]] in a new tab and saves the window reference (if the writer of this document recalls correctly, opening any non-existent resource from the server returns [[SolidOS]]) * [[SolidOS]] automatically logs in, as the user logged in there previously * The `text/html` file can access [[SolidOS]] via the window reference, including the authenticated fetch * The `text/html` file can make any requests through this authenticated fetch in the name of the currently logged-in user @@ -79,7 +79,9 @@ The attacker writes a malicious `text/html` file to the server. When this file i * The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]]) via the browser or a password manager extension -#### Attack: The attacker writes a malicious `text/html` file to the server. Depending on the application used to store the login credentials, the concrete autofill/suggestion behaviour can vary. For instance, if the user saved it with Chrome and opens the malicious file: +#### Attack + +The attacker writes a malicious `text/html` file to the server. Depending on the application used to store the login credentials, the concrete autofill/suggestion behaviour can vary. For instance, if the user saved it with Chrome and opens the malicious file: * The victim performs any interaction with the site (e.g., clicking on a cookie banner) * Chrome automatically fills in `` fields for the user name and password with the saved credentials @@ -90,7 +92,6 @@ The attacker writes a malicious `text/html` file to the server. When this file i ### Countermeasures ### {#serving-user-created-files-countermeasures} -Servers are encouraged to apply security measures when serving user-created files. -Multiple agents can create files on the same server, which could render same-origin security boundaries useless. -As an example countermeasure, servers could add a `Content-Security-Policy: sandbox` -header to artificially enable same-origin security policies for files on the same origin. +* Servers are encouraged to apply security measures when serving user-created files. +* Multiple agents can create files on the same server, which could render `same-origin` security boundaries useless. +* As an example countermeasure, servers could add a `Content-Security-Policy: sandbox` header to artificially enable `same-origin` security policies for files on the same origin. From 210674f5fc6b61db36449cbe2515fb30ac312bb6 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Sun, 31 Mar 2024 06:02:52 -0600 Subject: [PATCH 3/4] Apply suggestions from code review Co-authored-by: A_A <21040751+Otto-AA@users.noreply.github.com> --- index.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 6af1d17..cb1e19c 100644 --- a/index.bs +++ b/index.bs @@ -21,7 +21,7 @@ Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net/) Metadata Order: This version, Latest published version, Editor's Draft, Test Suite, Created, Modified, *, !* Metadata Include: Editor's Draft off Abstract: - This document describes best current security practice for OAuth 2.0. + This document describes best current security practice for Solid. Status Text: This section describes the status of this document at the time of its publication. @@ -52,7 +52,7 @@ that the victim's account can access. ### Use Solid-OIDC DPoP-bound ID tokens to make authenticated requests - +If a user is logged-in to an application hosted on the Solid server, a malicious application on the same Solid server could abuse this login to make authenticated requests. Here we use [[SolidOS]] as an example for the benign application. #### Prerequisites * The attacker has append/write access to a publicly readable folder/file on the server @@ -70,7 +70,7 @@ The attacker writes a malicious `text/html` file to the server. When this file i ### Steal login credentials - +If a user saved credentials for an application on the same site of the Solid server, a malicious application could steal these credentials. #### Prerequisites * The attacker has append/write access to a publicly readable folder/file on the server From 872c19e0c41694e8746ead4d349beb7cdda163f8 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Wed, 10 Apr 2024 06:00:18 -0600 Subject: [PATCH 4/4] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- index.bs | 57 +++++++++++++++++++++++++++++++++----------------------- 1 file changed, 34 insertions(+), 23 deletions(-) diff --git a/index.bs b/index.bs index cb1e19c..a2445e3 100644 --- a/index.bs +++ b/index.bs @@ -43,50 +43,61 @@ Status Text: ## Serving user-created files ## {#serving-user-created-files} -An attacker could be an agent with a WebID or an application. They need append/write access to the user's server -to store a malicious HTML file. They might have this access because the user allowed them to write a blog post, -or because they have their own storage in a different path on the same domain. +When Solid Servers serve files created by different users, they break the common Web assumption that files and/or applications served within the same origin are automatically equally trustworthy. + +An attacker could be any agent — human, browser, browser-based application, +etc. — with a WebID. They need append/write access to the user's server +to store a malicious HTML file. They might have this access because the +user had allowed them to write a blog post, or because they have their own +storage in a different path on the same domain, among other possibilities. -Impact of both scenarios: The attacker, pretending to be the victim, can access anything +Impact of the scenario: The attacker, pretending to be the victim, can access anything that the victim's account can access. ### Use Solid-OIDC DPoP-bound ID tokens to make authenticated requests -If a user is logged-in to an application hosted on the Solid server, a malicious application on the same Solid server could abuse this login to make authenticated requests. Here we use [[SolidOS]] as an example for the benign application. + +If a user is logged in to an application hosted on the Solid server, a +malicious application on the same Solid server could abuse this login to +make authenticated requests. Here we use [[SolidOS]] as an example of a +benign application. + #### Prerequisites -* The attacker has append/write access to a publicly readable folder/file on the server -* The server serves [[SolidOS]] under the same domain (by default, [[Community.Solid.Server]] serves everything under the same domain) -* The victim is logged in via [[SolidOS]], so any new session is automatically logged in again +* The attacker has append/write access to a publicly readable folder/file on the server. +* The server serves [[SolidOS]] under the same domain (e.g., by default, [[Community.Solid.Server]] serves everything under the same domain). +* Once the victim is logged in via [[SolidOS]], any new session is automatically logged in to the same account. #### Attack The attacker writes a malicious `text/html` file to the server. When this file is opened by the user: -* It opens [[SolidOS]] in a new tab and saves the window reference (if the writer of this document recalls correctly, opening any non-existent resource from the server returns [[SolidOS]]) -* [[SolidOS]] automatically logs in, as the user logged in there previously -* The `text/html` file can access [[SolidOS]] via the window reference, including the authenticated fetch -* The `text/html` file can make any requests through this authenticated fetch in the name of the currently logged-in user +1. It opens [[SolidOS]] in a new tab and saves the window reference. (If the writer of this document recalls correctly, opening any non-existent resource from the server returns [[SolidOS]].) +1. [[SolidOS]] automatically logs in, as the user who logged in there previously. +1. The `text/html` file can access [[SolidOS]] via the window reference, including performing authenticated fetch. +1. The `text/html` file can make any request in the name of the currently logged-in user, through this authenticated fetch. ### Steal login credentials -If a user saved credentials for an application on the same site of the Solid server, a malicious application could steal these credentials. + +If a user saves credentials for an application on the same site as the Solid server, a malicious application could steal these credentials. + #### Prerequisites -* The attacker has append/write access to a publicly readable folder/file on the server -* The victim uses the IDP of the (small) [[Community.Solid.Server]] server -* The storages are on the same domain as the IDP (default for [[Community.Solid.Server]]) -* The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]]) via the browser or a password manager extension +* The attacker has append/write access to a publicly readable folder/file on the server. +* The victim uses the IDP of the (small) [[Community.Solid.Server]] server. +* The storages are on the same domain as the IDP (default for [[Community.Solid.Server]]). +* The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]]) via the browser or a password manager extension. #### Attack -The attacker writes a malicious `text/html` file to the server. Depending on the application used to store the login credentials, the concrete autofill/suggestion behaviour can vary. For instance, if the user saved it with Chrome and opens the malicious file: +The attacker writes a malicious `text/html` file to the server. Depending on the tool used to store the login credentials, the actual autofill/suggestion behaviour can vary. For instance, if a user who saved login credentials with Chrome opens the malicious file: -* The victim performs any interaction with the site (e.g., clicking on a cookie banner) -* Chrome automatically fills in `` fields for the user name and password with the saved credentials -* The malicious `text/html` file can read and send the credentials to the attacker -* The attacker can use it to login with the IDP of the victim +1. The victim performs any interaction with the site (e.g., clicking on a cookie banner). +1. Chrome automatically fills in `` fields for the user name and password with the saved credentials. +1. The malicious `text/html` file can read and send the credentials to the attacker. +1. The attacker can use the credentials to log in with the IDP of the victim. @@ -94,4 +105,4 @@ The attacker writes a malicious `text/html` file to the server. Depending on the * Servers are encouraged to apply security measures when serving user-created files. * Multiple agents can create files on the same server, which could render `same-origin` security boundaries useless. -* As an example countermeasure, servers could add a `Content-Security-Policy: sandbox` header to artificially enable `same-origin` security policies for files on the same origin. +* As one possible countermeasure, servers could add a `Content-Security-Policy: sandbox` header to artificially enable `same-origin` security policies for files served on the same origin.