/
index.bs
97 lines (71 loc) · 4.95 KB
/
index.bs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
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 OAuth 2.0.
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}
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.
Impact of both scenarios: The attacker, pretending to be the victim, can access anything
that the victim's account can access.
### Use Solid-OIDC DPoP-bound ID tokens to make authenticated requests
#### Prerequisites
* 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
#### 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
### Steal login credentials
#### 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
#### 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
### 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.