La 'validazione del contenuto' è la regola d'oro per evitare tutti gli attacchi e le violazioni del web?

No, non ti immischerai mai completamente contro tutti i potenziali attacchi e violazioni di sicurezza. Convalidare l'input è un passo significativo nel difendere le tue risorse in termini di riduzione della possibilità di SQL injection e XSS. Leggi di nuovo la top ten OWASP: è un buon punto di partenza.

Prova e fai domande più specifiche su attacchi o contromisure e difese e riceverai risposte più utili e specifiche.

Sarai in grado di eliminare molti di loro, senza dubbio.

Ma, da un lato, alcune vulnerabilità derivano dalla tua architettura . In un certo senso si potrebbe dire che l'applicazione progettata non è sicura.

Supponiamo che il tuo codice di logout non distrugga correttamente la sessione, ma lo lascia in uno stato che è riconosciuto dalla pagina di accesso come "disconnesso". Apparentemente, tutto funziona bene. Passano tutti i test. C'è un test mancante che avrebbe cancellato - tentando di accedere a una risorsa dopo il logout. Ma manca il test.

Se apri due schede nello stesso browser, potresti scoprire che puoi uscire dalla prima pagina e continuare a navigare attraverso il sito utilizzando al 100% richieste regolari, superando tutte le convalide; ed essendo ufficialmente disconnesso, tutto ciò che fai non viene registrato - tutti i tentativi di registrazione si bloccano in silenzio. Il registro della console del tuo browser si riempie di errori e non ti interessa.

Ed è anche peggio di così. Se provi ad accedere a una risorsa superadmin, il sistema prova a verificare se sei autorizzato o meno e, a causa della circostanza imprevista di te che non ha più un lato server associato a entità utente, questo controllo fallisce . In modo che ora questa sessione abbia accesso superadmin .

Quindi ti rimane un'applicazione in cui input perfettamente legali , provenienti semplicemente da due diverse schede dello stesso browser, finiscono per concederti un accesso amministrativo completo all'applicazione, e qualcuno può bloccarlo < em> involontariamente .

^{E quando questo è successo, perché è realmente successo , la "soluzione" proposta è stata, avete indovinato, cercando di trovare un modo per impedire l'apertura di due schede nel browser invece di tracciando la fonte del problema . La soluzione "reale" era aggiungere una riga con session_destroy() nel sorgente. Il "quick patch" si è rivelato essere una settimana di kludgy Javascript da incubo} .

Un altro esempio è la debolezza casuale o la divulgazione di informazioni nella tua applicazione, che potrebbe consentire a qualcuno di indovinare come ottenere privilegi ingiustificati. Lo faranno emettendo i comandi legali - il problema sarà che loro sono stati in grado di scoprire questi comandi .

Ad esempio, alcune applicazioni possono fornire un menu con opzioni. Un utente a livello di amministrazione mostrerà dieci voci, un ospite ne mostrerà solo due. I collegamenti ai punti di accesso privilegiati non saranno nel codice HTML. Ma se il livello di privilegio dell'utente non è controllato da quei punti di ingresso , chiunque può accedervi a condizione che conosca o indovini i loro nomi.

Prevedibili errori di reimpostazione della password (ad esempio md5 (loginname + unix_timestamp)) consentiranno a un utente malintenzionato di accedere a qualsiasi account inviando una richiesta di reimpostazione della password a tarda notte e inviando ciecamente una conferma ( o un numero ragionevole di tentativi di forza maggiore). L'utente legittimo lo scoprirà la mattina dopo, e potrebbe essere troppo tardi.

Reimpostando la password prima arriva la conferma, e l'utilizzo di quest'ultimo per concedere l'accesso, comporterà un semplice rifiuto del servizio di tutti gli account.

E, naturalmente, potremmo trovare molti altri esempi a diversi livelli di vulnerabilità (dall'accesso a dati non autorizzati all'interruzione del funzionamento del sito) che funzioneranno ancora anche dopo tutte le possibili disinfezione.

D'altra parte, la corretta sterilizzazione degli input potrebbe rivelarsi impossibile, poiché potrebbe essere necessario elaborare combinazioni di input impossibilmente complesse o non essere in grado di dire facilmente se, ad esempio, l'input COTE D'OR è una richiesta legittima o un'iniezione SQL tentativo (nel caso questo sì, è ragionevolmente facile).

In alcuni scenari avresti bisogno di un interprete sicuro dell'input per essere in grado di dire se l'input è kosher o meno ... ma se tu avessi un tale interprete, avrebbe più senso usarlo per analizzare i dati di input nel codice di produzione. Questo tipo di "schermatura" vale ancora la pena quando non è possibile modificare il comportamento dell'applicazione e si è costretti a schierare un "front-end" più intelligente come scudo; ma come sviluppatore di app Web per app di tua scelta, questo non è il tuo caso.

Il mio consiglio è di pianificare e testare con cura la tua applicazione e provare a pensare a tutto ciò che potrebbe andare storto e cosa fare quando alla fine andrà male.

Applicare una "Grande Muraglia" di input igienizzati potrebbe farti cullare in un falso senso di sicurezza e, a lungo termine, fare più danni che benefici.

Detto questo, ci sono diverse librerie e framework che aggiungeranno l'igienizzazione dell'input in un secondo momento senza costi, ed è indubbiamente una strada che vale la pena perseguire. Che cos'è not è un "proiettile d'argento" che ti consente di "sbarazzarti di tutte le vulnerabilità".

Sì, la convalida del contenuto eseguita correttamente getterà le basi per un solido approccio alla sicurezza. OWASP Top 10 è una guida per stabilire una posizione di sicurezza di base.

No, la convalida del contenuto non è una regola d'oro per impedire attacchi e violazioni ALL . Mentre stabilire una solida implementazione della convalida dei contenuti ridurrà drasticamente il numero di attacchi riusciti, ma "c'è più di un modo per skinare un gatto."

Devi anche considerare i rischi e l'impatto che una violazione potrebbe creare. Un sito Web personale potrebbe non avere molto impatto e una violazione può essere risolta con un semplice ripristino dal backup. Un sito web che si occupa di informazioni finanziarie o sanitarie potrebbe avere importanti implicazioni da una singola violazione.

Tu, come sviluppatore web nuovo , non devi necessariamente conoscere intimamente tutti i metodi di attacco e difesa, ma devi almeno conoscere le nozioni di base su come proteggere correttamente i tuoi siti web. Con il passare del tempo dovresti continuare a sviluppare la tua conoscenza dei meccanismi difensivi.

Se l'idea di imparare a difendersi dagli attacchi ti turba, potresti sfortunatamente essere nel campo sbagliato. Al giorno d'oggi, la conoscenza delle best practice sulla sicurezza sta diventando sempre più importante.

Non penso che sia un buon approccio per entrare nella "convalida dei contenuti" per proteggere il tuo sito web. Invece, dovresti usare framework e tecnologie che evitino molti rischi sin dall'inizio. Quando si parla di SQL injection, non utilizzare alcuna convalida del contenuto, utilizzare istruzioni preparate. Esistono in Java, esistono in PHP. Mai e poi mai compilare le tue dichiarazioni con concatenazione di stringhe. Questo è tutto.

Quindi, devi pensare a XSS e alla falsificazione di richieste cross site. È una buona idea pensare a quali parti dell'input dell'utente vengono riflesse nella risposta http al browser. Tuttavia, invece di scrivere funzioni che analizzano l'input dell'utente (molto probabilmente mancherai qualcosa) html-encode l'output o userai un framework che lo fa per te. Non è una cattiva idea capire i più comuni vettori di attacco riguardanti XSS. Dovresti sapere che non solo le iniezioni del tipo < script > alert ('sth') < / alert > ma anche cose come onload = ... che evita i personaggi < e >.

Controlla le pagine OWASP per CSRF. Un modo relativamente facile per rendere CSRF molto più difficile è controllare il referrer quando elabori le richieste e rifiuti se il referrer non è il tuo sito.

Detto questo, la convalida dell'input è assolutamente necessaria quando si sa che un input ha un formato definito con precisione. Un buon esempio è una data. Assicurati che l'utente entri davvero in una data. Ciò migliorerà la qualità del tuo codice indipendentemente dalla sicurezza.

Un paio di altre cose:

• Non utilizzare l'esecuzione del codice. No eval, exec, qualunque sia il loro nome nella tua lingua
• Non utilizzare la serializzazione. Non deserializzare mai gli oggetti inviati da un client.