Il filtraggio dei dati di input dell'utente è sufficiente o dovrebbe essere analizzato?

Per la convalida dell'input, raccomando un approccio di whitelist combinato con pass-or-reject. Definisci cosa è valido e accetta solo input validi, rifiuta tutto il resto.

Se si crea un editor di testo RTF che invia HTML al proprio server, è possibile utilizzare JavaScript per disinfettare l'input, in modo che l'incollatura di HTML da Word possa funzionare. Tuttavia il tuo server non accetterà alcun input non pubblicizzato.

Cercare di ripulire è soggetto a errori, in quanto solitamente è molto più complesso, quindi basta capire se l'input è valido o meno.

La whitelist è essenziale per una buona sicurezza. Puoi sempre decidere di accettare più input, mantenendo il controllo. Con un approccio blacklist, dovrai sempre aggiornarti con l'ultimo trucco.

Per l'output, vedi altre risposte.

Sono d'accordo con @ Jorn's risposta sulla convalida.

Tuttavia, stai ancora dimenticando un passaggio molto importante qui, e questo è codifica dell'output .
Per esempio. Codifica HTML (o codifica degli attributi, o codifica Javascript, ecc.) Prima di emettere qualsiasi cosa ... In effetti, questo è probabilmente anche più importante della convalida dell'input (probabilmente, non assolutamente, e sicuramente non in tutti situazioni ...)
In ogni caso non dovrebbe essere / o, è sicuramente sia la rigida validazione dell'input sia la codifica dell'output.

Ora, se ti riferisci a includere tag HTML "sicuri" nell'output (quindi non è molto chiaro nella tua domanda), allora dovresti ancora codificare ogni cosa, e quindi decodificare lo specifico tag che stai cercando senza nessuno degli attributi del tag .

P.S. Se ti stai riferendo a un'app .NET, MS AntiXSS (in WPL) fornisce un insieme di metodi .GetSafeHTMLXXX .

la tua domanda "I dati di input dell'utente, filtrano abbastanza o dovrebbero essere analizzati?" è più generale del caso XSS. Immagino che tu volessi essere specifico per XSS ma solitamente l'input dell'utente può causare molti altri exploit come SQL Injection, Path Traversal, XSS ... Come la tua domanda diventa più specifica su XSS, vorrei fare riferimento a ciò che è già detto e andare per il filtraggio degli input e la codifica dell'output (sempre lato server !!) con alcune contromisure conosciute come fornito da OWASP

Tuttavia, vorrei segnalarvi che il modo migliore per risolvere SQL Injection che può essere causato dall'input non controllato è nelle query parametrizzate ( Cheat Sheet di SQL Injection Prevention ), quindi se consideri le vulnerabilità di attraversamento di percorsi, il mio approccio sarebbe un approccio di whitelist.

La domanda è troppo ampia. La migliore risposta è: dipende. Dipende dal formato dei dati dell'utente e dalla politica di sicurezza che imponi.

• Ad esempio, se si includono dati utente in una query SQL, la risposta migliore è usare le istruzioni preparate.

• Ad esempio, se si includono dati utente, ad esempio il loro nome completo, in una pagina HTML, la risposta migliore potrebbe essere l'uso della codifica di output.

• Ad esempio, se si sta creando un servizio webmail che consente alle persone di inviare e-mail HTML e si desidera visualizzare un messaggio HTML all'utente, ma solo se l'e-mail non contiene alcun contenuto attivo, la risposta migliore coinvolgerà l'analisi e il filtraggio del contenuto analizzato.

La migliore risposta dipende dal dominio. Per ottenere una risposta più utile, dovrai fornire ulteriori dettagli sul problema concreto che stai cercando di risolvere.

Consiglio vivamente di non reinventare la ruota. Certo, ogni sviluppatore web deve conoscere le basi di sicurezza, ma se hai la possibilità di utilizzare una soluzione robusta, usalo. Ci sono alte probabilità che durante l'implementazione del tuo filtro ti manchi qualcosa. La corretta convalida dell'input non riguarda solo la rimozione di caratteri errati: questo è un argomento complesso. Ad ogni modo, se non hai altra opzione, guarda come funzionano gli altri WAF. Uno ben noto e robusto per le applicazioni PHP è link . E per quanto riguarda i vettori di attacco, giusto per ricordare quanto sono "sfocati": link .