Skip to content

Commit

Permalink
Merge pull request #9 from elf-pavlik/main
Browse files Browse the repository at this point in the history
initial WebID Document considerations
  • Loading branch information
elf-pavlik authored Jun 19, 2024
2 parents f7e0a77 + 7f8188b commit d2dc6d6
Show file tree
Hide file tree
Showing 2 changed files with 40 additions and 0 deletions.
10 changes: 10 additions & 0 deletions biblio.json
Original file line number Diff line number Diff line change
Expand Up @@ -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"
}
}
30 changes: 30 additions & 0 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -117,3 +117,33 @@ 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

Issue(9):

0 comments on commit d2dc6d6

Please sign in to comment.