Require servers to prevent or sanitise HTML on write by default for unauthenticated users
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- html
- Domain
- documentation, security
Research direction
Read the Solid Protocol constraints problem-details section, then compare this issue with #514, #1596, and the LDN specification. Determine whether the specifications already cover unauthenticated write and append constraints; done means a clear normative requirement or a documented security mitigation, including the script-execution question.
Written by the indexing model from the issue text.
Description
This issue complements #514, which focuses on serving html rather than writing of HTML. It also follows up on an implementation specific issue raised on https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1596
The spec allows constraints to be specified (https://solidproject.org/TR/protocol#constraints-problem-details) but as far as I can tell does not currently require any constraints
At the moment the spec does not appear to prevent writing of HTML to a server by unauthenticated users in cases where public write or append permission has been granted.
Such permission is a useful part of an inbox, so it looks like this an issue for the LDN specification as well, but applies generally to writing to a server.
I believe a minimum requirement is for the spec to require that a server use constraints that by default prevent or sanitise executable code on write for unauthenticated users.
A stronger version would be that a server MUST apply security constraints to any resource exposed to write and append permissions by unauthenticated users.
Out of the box, we don't want to allow accumulation of spam documents with possible security risks, regardless of how their risk is mitigated when served or on the client side.
Depending on interpretation, this possibly also has implications for the question:
"Do features in this specification enable new script execution/loading mechanisms?"
Arguably the spec does enable new mechanisms for loading scripts into a server, and therefore into a privileged context from which new attack surfaces are possible.
If this issue is already somehow covered by the spec, it would be useful for the mitigation to be summarised in this or another security question.
- Dominant language
- HTML
- Stars
- 563
- Forks
- 110
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solid/specification
-
new-work-item
Difficulty 5/5 Over a week Newbie friendliness 25/100
solid/specification#806 · 11 comments · 4 reactions ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
solid/specification#804 · 9 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
solid/specification#799 · 1 reaction ·
-
topic: resource access
Difficulty 5/5 Over a week Newbie friendliness 30/100
solid/specification#797 · 4 comments · 2 reactions ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
solid/specification#788 · 4 comments · 1 reaction ·
All issues in solid/specification
Similar issues
-
Area: Excel support
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
orbeon/orbeon-forms#7893 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
docToolchain/docToolchain#1705 ·
-
kb-infra-drift
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
OCHA-DAP/ds-knowledge-base#653 · 1 comment ·
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
namespace operations
Difficulty 1/5 Under an hour Newbie friendliness 90/100
EclipseFdn/open-vsx.org#13419 ·