From 4036162b50a367f5d56aed2d3339c881adee96e9 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Mon, 3 Jun 2024 19:27:31 -0600 Subject: [PATCH 1/3] initial WebID Document considerations --- biblio.json | 10 ++++++++++ index.bs | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/biblio.json b/biblio.json index c3a4a4d..a2b3673 100644 --- a/biblio.json +++ b/biblio.json @@ -26,5 +26,15 @@ ], "href": "https://solidos.solidcommunity.net/", "title": "SolidOS" + }, + "WebID": { + "authors": [ + "Andrei Sambra", + "Henry Story", + "Tim Berners-Lee" + ], + "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/", + "title": "WebID 1.0", + "publisher": "WebID Incubator Group" } } diff --git a/index.bs b/index.bs index 20ca176..6ace24b 100644 --- a/index.bs +++ b/index.bs @@ -118,3 +118,39 @@ The attacker writes a malicious `text/html` file to the server. Depending on the #### Considerations Servers are strongly encouraged to consider the countermeasures in the context of the use cases they want to enable or disable on a given storage. For instance, using `Content-Security-Policy: sandbox` will universally prohibit various functionalities for applications, including but not limited to accessing local storage, executing scripts, using forms, interacting with plugins, or including external content. This broad range of restrictions may not be desirable for various categories of applications that rely on client-side storage mechanisms, collaborative features, or dynamic content interaction. + +## Protecting WebID Document ## {#protecting-webid-document} + +Solid access policy enforcement heavily relies on the identities of agents. Requesting Parties are identified +with [[WebID]] and applications with ClientID [[Solid.OIDC]]. +User's WebID Document includes trust anchors, like designation to their [[Solid.OIDC]] Provider (aka. issuer). +In other approaches, public keys could be published or discoverable via the user's WebID Document. + +### Fully impersonate the user + +If the malicious app can write or append to the user's WebID, it could inject trust anchors, allowing complete impersonation. + +#### Prerequisites + +* Authorization system depends on a specific trust anchor in the user's WebID Document. + For example, [[Solid.OIDC]] issuer designation or pubic keys/keyset. +* User authorizes a malicious application to write or append to their WebID Document. + +#### Attack + +* The attacker publishes a malicious application, such as generating cool AI avatars and setting them in the user's profile. +* User authenticates with the malicious application + * If the access control system enforces client constraints, the user also authorizes the application to write or append to their WebID Document. +* Application injects attacker's trust anchor into the user's WebID Document +* The attacker can completely impersonate the user, which allows full access to all the data owned by the user. + As well as any data shared with that user by others, with the full extent of access they granted to the user. + +### Countermeasures + +* There is no requirement to expose WebID Document via [[Solid.Protocol]] and host it in Solid Storage. + WebID providers can support only a set of discovery features relying on the WebID document and provide + highly secured interface to change it, possibly requiring two-factor authentication. + +#### Considerations +Users need a way to manage their social profiles, approaches like linking from the user's WebID Document to +less protected vcard are available to accomplish it without opening discussed attack vectors. From 0e7817753b8d10b4587f3a9355f379e5eab7a665 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Thu, 6 Jun 2024 16:38:02 -0600 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- index.bs | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/index.bs b/index.bs index 6ace24b..c985c90 100644 --- a/index.bs +++ b/index.bs @@ -121,34 +121,36 @@ Servers are strongly encouraged to consider the countermeasures in the context o ## Protecting WebID Document ## {#protecting-webid-document} -Solid access policy enforcement heavily relies on the identities of agents. Requesting Parties are identified -with [[WebID]] and applications with ClientID [[Solid.OIDC]]. -User's WebID Document includes trust anchors, like designation to their [[Solid.OIDC]] Provider (aka. issuer). +Solid access policy enforcement relies heavily on the identities of agents. Requesting Parties are identified +by [[WebID]] and applications by ClientID [[Solid.OIDC]]. +A User's WebID Document includes trust anchors, like designation of their [[Solid.OIDC]] Provider (also known as _issuer_). In other approaches, public keys could be published or discoverable via the user's WebID Document. ### Fully impersonate the user -If the malicious app can write or append to the user's WebID, it could inject trust anchors, allowing complete impersonation. +If a malicious app can write or append to the user's WebID Document, +it could inject trust anchors, allowing complete impersonation. -#### Prerequisites +#### Exploit Prerequisites -* Authorization system depends on a specific trust anchor in the user's WebID Document. +* Solid's authorization system depends on a specific trust anchor in the user's WebID Document. For example, [[Solid.OIDC]] issuer designation or pubic keys/keyset. -* User authorizes a malicious application to write or append to their WebID Document. +* User authorizes a malicious Solid application to write or append to their WebID Document. #### Attack -* The attacker publishes a malicious application, such as generating cool AI avatars and setting them in the user's profile. -* User authenticates with the malicious application +* The attacker publishes an attractive malicious application, such as one that generates cool AI avatars and setting them in the user's profile. +* User authenticates with the malicious application. * If the access control system enforces client constraints, the user also authorizes the application to write or append to their WebID Document. -* Application injects attacker's trust anchor into the user's WebID Document -* The attacker can completely impersonate the user, which allows full access to all the data owned by the user. - As well as any data shared with that user by others, with the full extent of access they granted to the user. +* Application injects attacker's trust anchor into the user's WebID Document. +* The attacker can now completely impersonate the user, with full access to all the data owned by the user, + as well as access to any data shared with that user by others, to the full extent they granted to the impersonated user. ### Countermeasures -* There is no requirement to expose WebID Document via [[Solid.Protocol]] and host it in Solid Storage. - WebID providers can support only a set of discovery features relying on the WebID document and provide +* There is no requirement to expose WebID Document via [[Solid.Protocol]] nor to host it in Solid Storage. + Service providers who offer hosting of WebID Documents can minimally support + a set of discovery features that rely on the WebID document and provide a highly secured interface to change it, possibly requiring two-factor authentication. #### Considerations From 7f8188b55ca29229916228fb385094ccb77e48bc Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Thu, 13 Jun 2024 17:02:19 -0600 Subject: [PATCH 3/3] replace the initial countermeasure with an inline issue --- index.bs | 34 +++++++++++++--------------------- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/index.bs b/index.bs index c985c90..c20a06b 100644 --- a/index.bs +++ b/index.bs @@ -121,38 +121,30 @@ Servers are strongly encouraged to consider the countermeasures in the context o ## Protecting WebID Document ## {#protecting-webid-document} -Solid access policy enforcement relies heavily on the identities of agents. Requesting Parties are identified -by [[WebID]] and applications by ClientID [[Solid.OIDC]]. -A User's WebID Document includes trust anchors, like designation of their [[Solid.OIDC]] Provider (also known as _issuer_). +Solid access policy enforcement heavily relies on the identities of agents. Requesting Parties are identified +with [[WebID]] and applications with ClientID [[Solid.OIDC]]. +User's WebID Document includes trust anchors, like designation to their [[Solid.OIDC]] Provider (aka. issuer). In other approaches, public keys could be published or discoverable via the user's WebID Document. ### Fully impersonate the user -If a malicious app can write or append to the user's WebID Document, -it could inject trust anchors, allowing complete impersonation. +If the malicious app can write or append to the user's WebID, it could inject trust anchors, allowing complete impersonation. -#### Exploit Prerequisites +#### Prerequisites -* Solid's authorization system depends on a specific trust anchor in the user's WebID Document. +* Authorization system depends on a specific trust anchor in the user's WebID Document. For example, [[Solid.OIDC]] issuer designation or pubic keys/keyset. -* User authorizes a malicious Solid application to write or append to their WebID Document. +* User authorizes a malicious application to write or append to their WebID Document. #### Attack -* The attacker publishes an attractive malicious application, such as one that generates cool AI avatars and setting them in the user's profile. -* User authenticates with the malicious application. +* The attacker publishes a malicious application, such as generating cool AI avatars and setting them in the user's profile. +* User authenticates with the malicious application * If the access control system enforces client constraints, the user also authorizes the application to write or append to their WebID Document. -* Application injects attacker's trust anchor into the user's WebID Document. -* The attacker can now completely impersonate the user, with full access to all the data owned by the user, - as well as access to any data shared with that user by others, to the full extent they granted to the impersonated user. +* Application injects attacker's trust anchor into the user's WebID Document +* The attacker can completely impersonate the user, which allows full access to all the data owned by the user. + As well as any data shared with that user by others, with the full extent of access they granted to the user. ### Countermeasures -* There is no requirement to expose WebID Document via [[Solid.Protocol]] nor to host it in Solid Storage. - Service providers who offer hosting of WebID Documents can minimally support - a set of discovery features that rely on the WebID document and provide a - highly secured interface to change it, possibly requiring two-factor authentication. - -#### Considerations -Users need a way to manage their social profiles, approaches like linking from the user's WebID Document to -less protected vcard are available to accomplish it without opening discussed attack vectors. +Issue(9):