1. Attacks and Mitigations
1.1. Solid OIDC
1.2. Serving user-created files
When Solid Servers [Solid.Protocol] 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 the scenario: The attacker, pretending to be the victim, can access anything that the victim’s account can access.
1.2.1. 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 of a benign application.
1.2.1.1. Prerequisites
-
When multiple agents are allowed to perform append or write operations in a storage, the attacker has append or write access to a publicly readable resource in a storage.
-
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.
1.2.1.2. 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 who logged in there previously.
-
The
text/htmlfile can access [SolidOS] via the window reference, including performing authenticated fetch. -
The
text/htmlfile can make any request in the name of the currently logged-in user, through this authenticated fetch.
1.2.2. Steal login credentials
If a user saves credentials for an application on the same site as the Solid server, a malicious application could steal these credentials.
1.2.2.1. 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.
1.2.2.2. Attack
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
<input>fields for the user name and password with the saved credentials. -
The malicious
text/htmlfile can read and send the credentials to the attacker. -
The attacker can use the credentials to log in with the IDP of the victim.
1.2.3. Countermeasures
-
Multiple agents can create files on the same server, which could render
same-originsecurity boundaries useless. -
As one possible countermeasure, servers could add a [
Content-Security-Policy: sandbox](https://www.w3.org/TR/CSP3/#directive-sandbox) header to artificially enablesame-originsecurity policies for files served on the same origin.
1.2.3.1. 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.
1.3. 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_). In other approaches, public keys could be published or discoverable via the user’s WebID Document.
1.3.1. 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.
1.3.1.1. Exploit Prerequisites
-
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 Solid application to write or append to their WebID Document.
1.3.1.2. 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.
-
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.