-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial WebID Document considerations #9
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -118,3 +118,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. | ||
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### 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. | ||
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### Prerequisites | ||
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
* Authorization system depends on a specific trust anchor in the user's WebID Document. | ||
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
For example, [[Solid.OIDC]] issuer designation or pubic keys/keyset. | ||
* User authorizes a malicious application to write or append to their WebID Document. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The context of malicious application is unclear here. Whether it is something that adheres to Solid Protocol interacting with a Solid storage, or just generally anything potentially having the means to update the WebID Profile Document. They are separate cases, and whether or to what extent this document (Solid Security Considerations) should touch on WebID Profile Documents that are not available via the Solid Protocol needs a consideration.
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### 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. | ||
elf-pavlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### Countermeasures | ||
|
||
Issue(9): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...except that the WebID XG never published this, with or without a version declaration. It would be better to title it as what it was,
"WebID 1.0 Editor's Draft"
(which must be read and understood as"Editor's Draft of WebID 1.0"
) ... and of course, the document now served from that location says "Draft Community Group Report 05 March 2014", which is similarly but differently inaccurate and contrary to the "publisher" identified here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case we can't quickly resolve it in this PR I created a dedicated issue for it #10