Indipendentemente dal framework o dalla lingua, ci sono alcune cose che dovresti prendere in considerazione:
- Di quali funzionalità ho bisogno (o voglio)?
- Come posso bilanciare le funzionalità con Principle of Least Privilege?
- Quali risorse ho che possono essere limitazioni?
La mia risposta sarà indipendente dalla lingua perché questi principi verranno applicati indipendentemente dalla lingua o dal framework che stai utilizzando.
Dal tuo post, vuoi avere la possibilità per gli utenti di aggiungere commenti (come quelli che sono qui su SE) e caricare le immagini. Ci sono alcuni metodi comuni per farlo.
- Controlli HTML per gli utenti (cattiva idea)
- BBCode o markup simile (può essere efficace, ma fastidioso per gli utenti)
- Markdown o RST (entrambi sono costruiti per essere più naturali)
- Testo normale (non consente la formattazione dell'interfaccia utente)
Come Wordpress e altre applicazioni hanno dimostrato, consentire agli utenti di pubblicare codice HTML è una cattiva idea (tm). Se si desidera che gli utenti dispongano della formattazione dell'interfaccia utente, il testo in chiaro è il più sicuro, ma non consente la formattazione dell'interfaccia utente. Così lascia BBCode e Markdown come le due restanti soluzioni comuni. SE usa Markdown. È più naturale per gli utenti digitare che è [b]Blah[/b]
perché per l'enfasi, gli utenti dovrebbero digitare **blah**
per testo in grassetto in ogni caso. Questo ovviamente non è l'unico metodo, ma riduce notevolmente (ma non elimina!) XSS. Quindi perché non eliminare? Se non stai attento con il tuo Markdown (o con qualsiasi linguaggio di markup scelto), puoi finire con gli attacchi XSS nei link. La maggior parte dei casi d'uso richiede solo http
e https
gestori di protocollo negli URL, quindi hai l'opportunità di esercitare il Principle Of Leamin Privilege lì.
Per quanto riguarda il caricamento delle immagini, questo può essere un po 'più difficile. È qui che entrano le risorse che ho citato. Hai la possibilità di acquistare un dominio sandbox? Se lo fai, oltre a elaborare le immagini, puoi servirle da un dominio sandbox in modo da limitare l'esposizione per XSS, RCE e altri attacchi. Un dominio sandbox è uno che rimuove il contenuto dall'origine dell'applicazione. Ad esempio, le applicazioni www.google.com (Gmail, Google Documenti) utilizzano googleusercontent.com come dominio sandbox. L'unico scopo di questo dominio è quello di fornire contenuti forniti dagli utenti. I cookie di Google e DOM non sono accessibili perché l'origine è diversa. Inoltre, questo dominio dovrebbe servire contenuto da un server che non ha la capacità di fare altro che servire contenuto statico, quindi non è possibile incorporare il codice PHP nelle immagini, o una vulnerabilità nell'elaborazione delle immagini non avrebbe alcun impatto sul database e sul codice dell'applicazione .
Elaborazione delle immagini? Un'altra buona pratica è passare i caricamenti di immagini attraverso l'elaborazione delle immagini. Se ti aspetti solo JPG e PNG, per esempio, questo è facile. Puoi ridimensionare un'immagine 1: 1, e fallirà con le immagini rotte, rimuovendo gran parte dei vettori XSS e dei vettori RCE.
Come avrai sicuramente notato, la mia risposta è stata sulla stratificazione delle difese. Quando si consumano dati utente, non esiste una panacea. Devi valutare i rischi, le funzionalità desiderate e come limitare al massimo l'esposizione delle funzionalità che desideri offrire agli utenti.