Consentire frammenti di codice nell'input del modulo prevenendo gli attacchi di iniezione XSS e SQL

Question

Come si può consentire l'inserimento di frammenti di codice in un editor (come fa stackoverflow) come FCKeditor o qualsiasi altro editor, evitando XSS, iniezione SQL e attacchi correlati.

Answer 1

Parte del problema qui è che si desidera consentire determinati tipi di HTML, giusto? Link per esempio. Ma devi disinfettare solo quei tag HTML che potrebbero contenere attacchi XSS come tag di script o del resto anche attributi del gestore di eventi o un href o altri attributi che iniziano con & Quot; javascript: & Quot ;. Quindi una risposta completa alla tua domanda deve essere qualcosa di più sofisticato di & Quot; sostituisci caratteri speciali & Quot; perché ciò non consentirà collegamenti.

La prevenzione dell'iniezione SQL può dipendere in qualche modo dalla scelta della piattaforma. La mia piattaforma Web preferita ha una sintassi integrata per la parametrizzazione delle query che impedirà principalmente SQL-Injection (chiamato cfqueryparam). Se stai usando PHP e MySQL c'è una funzione nativa mysql_escape () simile. (Non sono sicuro che la funzione PHP crei tecnicamente una query con parametri, ma ha funzionato bene per me nel prevenire i tentativi di iniezione sql fino a quando ne ho visti alcuni che sono stati memorizzati in modo sicuro nel db.)

Per quanto riguarda la protezione XSS, utilizzavo espressioni regolari per sanificare l'input per questo tipo di motivo, ma da allora mi sono allontanato da quel metodo a causa della difficoltà implicata nel consentire entrambe le cose come collegamenti, rimuovendo anche il codice pericoloso. Quello a cui mi sono trasferito come alternativa è XSLT. Ancora una volta, il modo in cui si esegue una trasformazione XSL può variare a seconda della piattaforma. Ho scritto un articolo per il ColdFusion Developer's Journal qualche tempo fa su come farlo, che include sia un foglio XSL boilerplate che puoi usare e mostra come realizzarlo funziona con CF usando la funzione nativa XmlTransform ().

Il motivo per cui ho scelto di passare a XSLT per questo è duplice.

Innanzitutto la convalida del fatto che l'input sia un formato XML corretto elimina la possibilità di un attacco XSS utilizzando alcuni trucchi di concatenazione di stringhe.

In secondo luogo è quindi più semplice manipolare il pacchetto XHTML utilizzando i selettori XSL e XPath che con le espressioni regolari perché sono progettati specificamente per funzionare con un documento XML strutturato, rispetto alle espressioni regolari progettate per la manipolazione di stringhe non elaborate. Quindi è molto più pulito e più facile, ho meno probabilità di fare errori e se trovo che ho fatto un errore, è più facile da risolvere.

Anche quando li ho testati ho scoperto che gli editor WYSIWYG come CKEditor (ha rimosso la F) conservano un XML ben formato, quindi non dovresti preoccuparti di questo come potenziale problema.

Answer 2

Le stesse regole si applicano per la protezione: input filtro, output escape.

Nel caso di input contenente codice, il filtro significa solo che la stringa deve contenere caratteri stampabili e forse hai un limite di lunghezza.

Quando si memorizza il testo nel database, utilizzare i parametri di query oppure evitare la stringa per assicurarsi di non disporre di caratteri che creano vulnerabilità nell'iniezione SQL. Il codice può contenere più simboli e caratteri non alfa, ma quelli a cui devi fare attenzione rispetto all'iniezione SQL sono gli stessi del testo normale.

Non tentare di duplicare la corretta funzione di escape. La maggior parte delle librerie di database contiene già una funzione che esegue l'escaping corretto per tutti i caratteri che richiedono l'escaping (ad esempio, potrebbe essere specifico del database). Dovrebbe anche gestire problemi speciali con set di caratteri. Usa semplicemente la funzione fornita dalla tua libreria.

Non capisco perché la gente dice " usa le stored procedure! " I processi memorizzati non offrono alcuna protezione speciale contro l'iniezione SQL. Se interpoli valori senza caratteri di escape in stringhe SQL ed esegui il risultato, questo è vulnerabile all'iniezione SQL. Non importa se lo stai facendo nel codice dell'applicazione rispetto a un processo memorizzato.

Quando esci dalla presentazione web, evita i caratteri speciali HTML, proprio come faresti con qualsiasi testo.

Answer 3

La cosa migliore che puoi fare per prevenire gli attacchi SQL injection è assicurarti di usare query con parametri o procedure memorizzate quando effettui chiamate al database. Normalmente, consiglierei anche di eseguire anche una sanificazione di base dell'input, ma poiché è necessario accettare il codice dall'utente, questa potrebbe non essere un'opzione.

Dall'altro lato (quando si esegue il rendering dell'input dell'utente al browser), la codifica HTML dei dati comporterà il rendering di JavaScript o simili dannosi come testo letterale anziché eseguito nel browser del client. Qualsiasi framework di server di applicazioni Web decente dovrebbe avere la capacità.

Answer 4

Direi che si potrebbe sostituire tutto < di & amp; lt ;, ecc. (usando htmlentities su PHP, per esempio), quindi scegli i tag sicuri con una specie di whitelist. Il problema è che la whitelist potrebbe essere un po 'troppo severa.

Ecco un esempio di PHP

$code = getTheCodeSnippet();
$code = htmlentities($code);
$code = str_ireplace("&lt;br&gt;", "<br>", $code); //example to whitelist <br> tags
//One could also use Regular expressions for these tags

Per prevenire iniezioni di SQL, è possibile sostituire all 'e \ chars con un " innofensive " equivalente, come \ 'e \, in modo che la seguente linea C

#include <stdio.h>//'); Some SQL command--

Non si otterrebbero risultati negativi nel database.