Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Require servers to prevent or sanitise HTML on write by default for unauthenticated users

Aperta
#515 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
html
Ambito
documentation, security

Direzione di ricerca

Leggi la sezione constraints e problem-details di Solid Protocol, quindi confronta questa issue con #514, #1596 e la LDN specification. Determina se le specifiche coprono già i vincoli di scrittura e append non autenticati; il lavoro è considerato completato quando esiste un requisito normativo chiaro o una mitigazione di sicurezza documentata, inclusa la questione dell’esecuzione degli script.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
HTML
Stelle
563
Fork
110
Merge medio
4g 13h
PR unite (30g)
3

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/specification

Tutte le issue di solid/specification

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.