Skip to content
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 draft #2

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions .gitignore
@@ -0,0 +1,2 @@
*.html

16 changes: 16 additions & 0 deletions 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"
],
Comment on lines +10 to +12
Copy link
Member

@csarven csarven Apr 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering listing individuals in https://solidos.solidcommunity.net/Contacts/Group/SolidOS_Team.ttl or refer to the "SolidOS Team", e.g.:

Suggested change
"authors": [
"Timea Turdean"
],
"authors": [
"SolidOS Team"
],

"href": "https://solidos.solidcommunity.net/",
"title": "SolidOS"
}
}
97 changes: 97 additions & 0 deletions index.bs
@@ -0,0 +1,97 @@
<pre class='metadata'>
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 Solid.
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.
</pre>

# Attacks and Mitigations # {#attacks-and-mitigations}

## Serving user-created files ## {#serving-user-created-files}
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved

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.
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to reproduce this security issue:

  1. Give untrusted agent Append/Write access to storage.
  2. Goto 1.

Copy link

@Otto-AA Otto-AA Apr 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Give untrusted agent Append/Write access to storage.

From how I understand, you imply that the problem is already this step of giving Append/Write access.

If yes, I'd disagree with this. If you meant something else, can you clarify it?

Append/Write access seems like a simple requirement for an attacker, for various reasons.

Firstly, if I give someone access to append pictures to my /cats container, I would not expect this to be a security issue. In fact, if the attacker could gain full control over the pod just from Append access to a container, this would render access control rather useless. The Solid protocol / implementations should ensure that access control holds up, even with malicious agents.

Secondly, any CSS instance that is publicly open for registration would give an attacker the opportunity to host malicious html files on the same origin (solidweb.me, etc.). For ESS it's the same (at least for storage.inrupt.com). For NSS, other storages are only on the same site, not origin.

And thirdly, even if I only give agents access that I completely trust: They can also get hacked. If that happens, the impact of this should be as contained as possible. So we should only give them access to what they really need, and it should be hard for them to gain more access.

EDIT: in security terms, getting more access based from some initial access is called a "privilege escalation". Serving html/... files allows for privilege escalation if the server does not prevent it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please clarify what you mean?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@csarven, if I interpret your haiku correctly, you seem to suggest that Solid access control could be boiled down to a simple allow list of WebIDs, which would give every WebID listed full access to the storage.

Copy link
Member

@csarven csarven Apr 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<script>alert()</script> in the literal of a concrete RDF syntax falls within the same realm of security concerns.

Actual security concern: Sanitise content before injecting into DOM or have a shape that validates the payload (e.g., to block or clear src, data, inline scripts, and so on.) so that the consumer doesn't inadvertently run stuff.

That's of course to prevent..

the agent that was somehow given append or write access permissions - read: trusted - to a storage who then turned out to be an "attacker" or unwillingly added malicious code won't cause chaos. /s

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<script>alert()</script> in the literal of a concrete RDF syntax falls within the same realm of security concerns.

I think we could separate RDF application security issues from HTML/SVG browser related security issues.

I definitely agree, that malicious RDF can be an issue and we need to be careful when interacting with this data. I've also written an article about this last year (which in retrospectively still makes important points, but maybe it is from a hardcore security perspective): https://github.com/Otto-AA/solid-security-basics.
This also goes beyond html injection: For instance, Penny blindly trusted the container data when making a recursive deletion, such that you could have tricked it to delete any other storage as well, not only child resources. So also for business logic in applications, it is important not to blindly trust RDF data.

However, I think we could keep this security issue separate from serving html files. I would see sanitization of RDF as a task for the application that uses and renders it (currently for web apps mostly). They fetch it and, if they want to render it, they should sanitize it.

For html files we cannot rely on apps to do this sanitization. If the HTML file is served publicly, the browser will render it and execute its malicious content. A way we could do this "sanitization" in browsers would be to tell it not to render the html, with CSP headers etc. Alternatively, maybe the server could return a html-rendering app that manually fetches the html and renders a sanitized version. However, in both of these cases, it would be the servers responsibility.

I think it would make sense to separate it with this distinction: security issues where apps are responsible and security issues where servers are responsible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you like to add a recommendation on sanitizing any RDF Literal before using it in the DOM?
This could be a separate PR


Impact of both scenarios: The attacker, pretending to be the victim, can access anything
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved
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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved

* 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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved

#### 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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved


### 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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved

* 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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved


#### 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 `<input>` 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
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved



### 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.
elf-pavlik marked this conversation as resolved.
Show resolved Hide resolved
3 changes: 3 additions & 0 deletions logo.include
@@ -0,0 +1,3 @@
<a href="https://solidproject.org/TR/" class="logo">
<img alt="Solid" src="https://solid.github.io/solid-oidc/solid.svg" width="72">
</a>