Esecuzione della convalida dell'input significa controllare l'input per essere sicuri di poterlo elaborare. La parte difficile è che, convalidandolo, stai già eseguendo qualche piccola elaborazione e questo può creare una vulnerabilità nascosta.
Il primo passo consiste in genere nella convalida della lunghezza dell'input. La maggior parte degli input finirà temporaneamente in un buffer finito. Assicurati che la quantità di input che copi nel buffer non superi la lunghezza del buffer: se c'è troppo input e non abbastanza buffer, questo può creare un classico problema di "buffer overflow"; sfruttarli è una base degli hacker.
Il prossimo passo è garantire che i dati siano nel formato che ti aspetti. Se stai aspettando un numero, assicurati che i byte contengano solo cifre e simboli numerici consentiti, come più, meno, separatore, punto decimale, simbolo di valuta, ecc. Si noti che questi sono specifici delle impostazioni locali: negli Stati Uniti, un milione di dollari potrebbe essere inserito come 1,000,000.00 , mentre in Germania è possibile inserire un milione di euro come 1.000.000,00 . Se ti aspetti caratteri e numeri alfanumerici, utilizza una "lista bianca" per accettare solo i caratteri che ti aspetti. È più sicuro fare affidamento su una lista bianca di buoni personaggi rispetto a una lista nera di personaggi cattivi; la tua lista nera potrebbe mantenerti al sicuro con la tua configurazione a partire da oggi, ma supponiamo che qualcuno in futuro sostituisca il tuo database con un altro database. È possibile che uno dei caratteri imprevisti consenta un'iniezione SQL. Lo stesso vale per lo scripting e l'HTML.
Notare che se si annullano questi controlli e si verificano i caratteri speciali prima di verificare la lunghezza dell'input, il codice di convalida potrebbe essere vulnerabile a un overflow del buffer. È importante eseguirli nell'ordine che ti mantiene più sicuro.
Quindi il prossimo passo è codificare appropriatamente l'input. Ad esempio, se accetti < e > e metti i risultati su una pagina web, probabilmente vorrai assicurarti di codificare in HTML i simboli in modo da non creare inavvertitamente un buco dove un utente malintenzionato può piantare un <script>attack!</script> nella pagina di output.
Si consiglia inoltre di tentare di proteggere contro le iniezioni SQL qui (proteggere qualcuno che inserisce qualcosa di brutto come ' OR 1=1;DROP TABLE STUDENTS-- , ma questa è un'arma a doppio taglio, perché non garantisce completamente la protezione. un controllo di validazione contro l'accettazione del carattere di apostrofo La riga di difesa successiva deve essere nel codice che si interfaccia con SQL e che il codice deve essere responsabile dell'esecuzione sicura delle query (utilizzando query SQL parametrizzate, ORM o altre strategie difensive). Potresti testare il tuo input con il suddetto attacco SQL injection e non trovare un difetto perché conosci solo un tipo di attacco di iniezione, ma supponiamo che l'hacker calcoli una nuova via di attacco e cerchi di usare la codifica HTML per ottenere attorno al tuo assegno, e scopre che hai dimenticato di testare e / o sanitizzare contro quel tipo di input. Potresti comunque essere vulnerabile a meno che tu non stia attento con la codifica SQL.Questo è un piccolo esempio di come una difesa in la strategia di profondità può aiutarti a rimanere al sicuro.