Sto eseguendo un sistema di commenti e accetto il testo normale e non formattato.
Non voglio nulla di troppo complicato, quindi ho pensato di cercare e sostituire tutto < nello spazio (tramite regex o un semplice ciclo for ), quindi <script src="http://malicioussite.com">apparirebbesolocomescriptsrc="http://malicioussite.com" .
C'è qualche ragione non per fare questo?
Un hacker può ancora cavarsela con un XSS?
Sostituire < e > caratteri non è sufficiente in tutti i casi. Certo, impedirà a qualsiasi utente di aprire un tag HTML, ma questo non gli impedirà di iniettare attributi HTML in un tag HTML.
Ad esempio, prendiamo un parser che trasforma [img=XXX] in <img src="XXX" /> , sostituendo solo < e > .
Un utente malintenzionato potrebbe immettere [img=X" onerror="alert(1)] e il parser restituirebbe:
<img src="X" onerror="alert(1)" />
E l'avviso verrà visualizzato, il che significa che è possibile un attacco XSS.
Potrebbe essere sufficiente e potrebbe non esserlo, ma non è sicuramente una buona idea.
Can a hacker still get away with a XSS?
Forse, a seconda della situazione.
@BenoitEsnard ha già descritto una situazione dove il filtraggio di < e > non è sufficiente: quando il l'input dell'utente viene riprodotto all'interno degli attributi dei tag HTML esistenti, poiché in tal caso un utente malintenzionato potrebbe semplicemente aggiungere nuovi attributi.
Ecco una lista con diversi contesti e come gestirli quando impedisce XSS .
Is there any reason not to do this?
Sì.
Supponiamo che tu in realtà elimini solo il commento all'interno di <textarea>COMMENT</textarea> durante la modifica di un commento e all'interno di <div id=comment>COMMENT</div> quando mostri un commento, da nessun'altra parte, e non vuoi affatto alcuna formattazione HTML, solo testo semplice come tu hai detto.
Se scrivi correttamente la tua funzione, sarebbe sicura. Ma non sarebbe molto facile da usare. A seconda del tipo di sito web che hai, gli utenti vorranno utilizzare < e > in molte situazioni, ad esempio: Love you <3 , 2 < 3 , use this: this->exec() , <font> is deprecated , >.< , ...
Quindi è sicuramente un problema di usabilità e probabilmente un problema di sicurezza in base al contesto e alla correttezza di implementazione .
Usa semplicemente le funzioni che sono comunemente usate invece di scrivere il tuo meccanismo (per esempio in PHP usa htmlentities quando echi l'input dell'utente in un HTML contesto in cui non vuoi analizzare l'HTML dato, usa alcune librerie come HTMLPurifier se hai bisogno di HTML e così via)
No, non è sufficiente - se inserisci ciecamente il testo inviato dall'utente nel tuo output HTML, ci sono molti diversi contesti in cui altri simboli possono essere trattati come parte del markup. Il modo più sicuro e, verosimilmente, corretto è quello di trattare esplicitamente il testo semplice come, beh, il testo semplice. Recupera questo testo con una richiesta separata basata su JavaScript dal tuo server come blocco di testo o impacchettato in JSON e assegnalo direttamente alla proprietà data del nodo di testo in DOM. In questo modo garantisci che non verrà mai elaborato come se fosse solo un semplice testo senza impedire all'utente la possibilità di utilizzare qualsiasi simbolo desideri.
// Obtain user somehow generated text. For this demonstration I'll just inline it.
var text = "some <funky> &text& with something that looks like </script> suspicious HTML"
// Find target text node in your page. For this demonstration I'll just create it myself.
var text_node = document.createTextNode('')
document.body.appendChild(text_node)
// Now just assign your text data to node
text_node.data = text
Leggi altre domande sui tag xss