Input Sanitization vs Output Sanitization [duplicate]

Quando si disinfetta l'input, si rischia di alterare i dati in modi che potrebbero renderlo inutilizzabile. Pertanto, l'igienizzazione dell'input viene evitata nei casi in cui la natura dei dati è sconosciuta. Ad esempio, forse alcuni caratteri speciali hanno un significato nei dati e spogliarli significa distruggerli.

Uno scenario come questo potrebbe essere che il tuo sistema memorizza dati che possono essere successivamente estratti in un sistema di terze parti, e in quel sistema quei personaggi hanno un significato. Spogliandoli hai alterato i dati in modo significativo. Ad esempio, forse la stringa viene utilizzata come chiave per cercare un record nel sistema di terze parti e, eliminando il simbolo, si modifica la chiave in modo tale che il record non possa essere trovato.

È possibile utilizzare la disinfezione degli input quando la natura dei dati è nota e l'igienizzazione non influirà negativamente sui dati in alcun modo.

La decisione di disinfettare i dati di input è in parte una decisione aziendale. Il sistema di terze parti dipende dall'input esattamente come viene fornito? Se è così, probabilmente non è una buona idea. Tuttavia, potresti essere in grado di modellare le aspettative in modo tale che le terze parti capiscano che disinfetti i dati di input in base a criteri specifici che condividi con loro.

Gee ... "Sanitize output." In realtà non ho mai sentito quel termine usato prima. Ho fatto questo per, oh, non lo so. Almeno oltre un decennio. Non si "disinfetta l'output" si si codifica per il contesto appropriato all'interno dell'applicazione che viene presentata. encode l'output per HTML, HTML Attribute, URL, JavaScript ... Non ho mai visto o sentito qualcuno affermare che tu "disinfetti" il tuo output ... vuoi dire gente nel senso di whitelist o blacklist quali stringhe di caratteri particolari possono essere inviate nel cavo al browser, ad esempio? Nessuno lo fa. Non dovrebbero comunque, per le ragioni sopra elencate, non sapere quale possa essere l'uso legittimo di particolari dati per una data applicazione ... alcuni siti web (come, per esempio .. questo) devono consente il caricamento del codice e il rendering come codice w / nel ciclo di vita richiesta-risposta. Non permettendo l'uso di, ad esempio, un tag script, come potrebbero mai essere scambiati esempi di codice su siti di code-sharing?

A proposito "Non è mai possibile in retrospect passare attraverso il database e vedere quanti dei messaggi erano dannosi". semplicemente non è vero Sono disponibili scrubbers per passare attraverso un database e "scrub" di codice dannoso. Lo so, l'ho fatto l'anno scorso per un'importante compagnia di servizi finanziari.

Non sai come disinfettare i dati finché non li emetti, o più precisamente usali .

In molti casi potrebbe sembrare ovvio; nel tuo motore di blogging vuoi filtrare tag di script; sempre e così semplicemente li cancelli dall'input e non li pensi mai più.

In altri casi potrebbe non essere così facile; se gli stessi dati sono usati in diversi contesti. "<" deve essere convertito in "& lt;" in html ed è completamente innocuo se esportato come testo.

Ma anche se è semplice, rimuovendo < script > dal tuo input perdi dati importanti. Non è mai possibile in retrospect passare attraverso il database e vedere quanti dei messaggi erano dannosi.

Poi arriva la possibilità di spostare i post degli obiettivi: qualcuno trova un nuovo exploit che il tuo filtro non tratta. All'improvviso devi riapplicare un filtro fisso sull'intero database. Cosa succede se c'è un bug falso positivo nella tua correzione?

Ma anche se sei assolutamente sicuro che i dati pubblicati siano completamente privi di xss, virus e così via, è completamente sicuro mostrare in un browser; non puoi spingerlo nel tuo database volenti o nolenti. Ecco come nascono le iniezioni SQL.

La linea di fondo è che finché non usi i dati, non puoi sapere quali siano i "cattivi" dati e ogni tempo in cui usi i dati che devi disinfettare .

Cercare di correggere i dati in anticipo è come indossare le calze prima che ci sia un buco in loro.

È un rischio avere contenuto XSS nel tuo database. I database sono pensati per essere condivisi dalle applicazioni e sono longevi rispetto ai front-end Web.

Esempio: il nuovo stagista inizia a lavorare su una nuova app Web per il db, mostra il suo capo e bam, il suo cookie di accesso è a San Pietroburgo.

Non si desidera alter input dell'utente, si desidera validare l'input dell'utente e rifiutarlo se contiene XSS possibile. Questo è abbastanza facile e veloce con un parser HTML corretto come JSoup. È integrato in Hibernate Validator.

Non sto dicendo che non dovresti sfuggire all'input dell'utente in uscita. Con il numero di problemi XSS, ovviamente è facile perdere alcuni.

Suggerirei di convalidare l'imputazione e di disinfettare l'output. In questo modo puoi garantire che i dati validi vengano archiviati nel database e che i dati innocui vengano consumati alla fine degli utenti.

Se un campo si aspetta una data, assicurati di ricevere una data. Puoi facilmente verificare date, numeri, email, codici postali, numeri di telefono e molti campi. Quindi fallo.

Fatelo su javascript, sul lato client, E fatelo di nuovo dal lato server. Se si esegue la convalida sul lato client, è possibile generare un messaggio di errore molto più velocemente dell'attesa fino al server, della convalida e della restituzione. Fallo di nuovo sul server, perché se qualcuno disabilita la convalida sul lato client, sei ancora coperto.

Disinfetta prima di memorizzare i dati - non vuoi essere colpito da un'iniezione SQL. Usa le istruzioni preparate se possibile, e sfuggi ad ogni carattere di controllo se non possibile.

Sul lato di uscita, codifica i dati in modo da essere innocui nel formato back-end. Se si invia HTML, sfuggire a tutti i caratteri HTML speciali. Se si esegue l'output di JSON o XML, eseguire la codifica di conseguenza.

Come altri hanno detto, il filtraggio e la codifica dei dati sulla dimensione dell'input distruggono i dati e possono cancellare parte dei dati che sarebbero innocui in alcuni contesti, o mantenere dati pericolosi. Convalidare l'input e codificare l'output sarebbe l'approccio migliore.