10 vulnerabilità di sicurezza Web più comuni

Per troppe aziende, è solo dopo che si è verificata una violazione della sicurezza che le migliori pratiche di sicurezza web diventano una priorità. Durante i miei anni di lavoro come professionista della sicurezza IT, ho visto più e più volte quanto il mondo dei problemi di sicurezza dello sviluppo web possa essere oscuro per molti dei miei colleghi programmatori.

Un approccio efficace alle minacce alla sicurezza web deve, per definizione, essere proattivo e difensivo. A tal fine, questo post ha lo scopo di innescare una mentalità di sicurezza, sperando di iniettare nel lettore una sana dose di paranoia.

In particolare, questa guida si concentra su 10 trabocchetti comuni e significativi per la sicurezza Web di cui essere consapevoli, compresi i consigli su come possono essere mitigati. L'attenzione si concentra sulle 10 principali vulnerabilità Web identificate dall'Open Web Application Security Project (OWASP), un'organizzazione internazionale senza scopo di lucro il cui obiettivo è migliorare la sicurezza del software in tutto il mondo.

Prima di iniziare, un piccolo manuale sulla sicurezza informatica: autenticazione e autorizzazione

Quando parlo con altri programmatori e professionisti IT, incontro spesso confusione riguardo alla distinzione tra autorizzazione e autenticazione. E, naturalmente, il fatto che l'abbreviazione auth sia spesso usata per entrambi aiuta ad aggravare questa confusione comune. Questa confusione è così comune che forse questo problema dovrebbe essere incluso in questo post come "Vulnerabilità Web comune zero".

Quindi, prima di procedere, chiariamo la distinzione tra questi due termini:

• Autenticazione: verifica che una persona sia (o almeno sembra essere) un utente specifico, poiché ha fornito correttamente le proprie credenziali di sicurezza (password, risposte a domande di sicurezza, scansione delle impronte digitali, ecc.).
• Autorizzazione: conferma che un determinato utente ha accesso a una risorsa specifica o ha ottenuto l'autorizzazione per eseguire una determinata azione.

Detto in altro modo, l'autenticazione è sapere chi è un'entità, mentre l' autorizzazione è sapere cosa può fare una determinata entità. Con questo in mente, entriamo nei primi 10 problemi di sicurezza di Internet.

Errore comune di sicurezza Web n. 1: difetti di iniezione

I difetti di iniezione derivano da un classico errore nel filtrare l'input non attendibile. Può succedere quando si passano dati non filtrati al server SQL (SQL injection), al browser (XSS – ne parleremo più avanti), al server LDAP (LDAP injection) o altrove. Il problema qui è che l'attaccante può iniettare comandi a queste entità, con conseguente perdita di dati e dirottamento dei browser dei client.

Tutto ciò che la tua applicazione riceve da fonti non attendibili deve essere filtrato, preferibilmente in base a una whitelist. Non dovresti quasi mai usare una lista nera, poiché ottenerla correttamente è molto difficile e di solito facile da aggirare. I prodotti software antivirus in genere forniscono esempi eccezionali di blacklist fallite. La corrispondenza del modello non funziona.

Prevenzione: la buona notizia è che la protezione contro l'iniezione è "semplicemente" una questione di filtrare correttamente l'input e pensare se ci si può fidare di un input. Ma la cattiva notizia è che tutti gli input devono essere adeguatamente filtrati, a meno che non ci si possa indiscutibilmente fidare (ma qui viene in mente il detto "mai dire mai").

In un sistema con 1.000 input, ad esempio, filtrarne con successo 999 non è sufficiente, poiché questo lascia ancora un campo che può fungere da guarigione di Achille per far crollare il tuo sistema. E potresti pensare che inserire il risultato di una query SQL in un'altra query sia una buona idea, poiché il database è attendibile, ma se il perimetro non lo è, l'input viene indirettamente da ragazzi con cattive intenzioni. Questo è chiamato Iniezione SQL del secondo ordine nel caso tu sia interessato.

Poiché il filtraggio è piuttosto difficile da eseguire correttamente (come la crittografia), quello che di solito consiglio è di fare affidamento sulle funzioni di filtraggio del tuo framework: è stato dimostrato che funzionano e sono attentamente esaminate. Se non usi i framework, devi davvero riflettere seriamente sul fatto che non utilizzarli abbia davvero senso nel contesto della sicurezza del tuo server. Il 99% delle volte no.

Errore comune di sicurezza Web n. 2: autenticazione interrotta

Questa è una raccolta di più problemi che potrebbero verificarsi durante l'autenticazione interrotta, ma non derivano tutti dalla stessa causa principale.

Supponendo che qualcuno voglia ancora eseguire il proprio codice di autenticazione nel 2014 (a cosa stai pensando ??), lo sconsiglio. È estremamente difficile rimediare e ci sono una miriade di possibili insidie, solo per citarne alcune:

1. L'URL potrebbe contenere l'ID della sessione e trasmetterlo a qualcun altro nell'intestazione del referer.
2. Le password potrebbero non essere crittografate né in archiviazione né in transito.
3. Gli ID di sessione potrebbero essere prevedibili, quindi ottenere l'accesso è banale.
4. Potrebbe essere possibile la correzione della sessione.
5. Potrebbe essere possibile il dirottamento della sessione, timeout non implementati correttamente o utilizzando HTTP (nessuna sicurezza SSL), ecc...

Prevenzione: il modo più semplice per evitare questa vulnerabilità della sicurezza Web è utilizzare un framework. Potresti essere in grado di implementarlo correttamente, ma il primo è molto più semplice. Nel caso in cui desideri eseguire il tuo codice, sii estremamente paranoico e informati su quali sono le insidie. Ce ne sono un bel pò.

Errore comune di sicurezza Web n. 3: Cross Site Scripting (XSS)

Questo è un errore di sanificazione dell'input abbastanza diffuso (essenzialmente un caso speciale di errore comune n. 1). Un utente malintenzionato fornisce all'input i tag JavaScript della tua applicazione web. Quando questo input viene restituito all'utente non disinfettato, il browser dell'utente lo eseguirà. Può essere semplice come creare un collegamento e persuadere un utente a fare clic su di esso, oppure può essere qualcosa di molto più sinistro. Al caricamento della pagina lo script viene eseguito e, ad esempio, può essere utilizzato per inviare i cookie all'attaccante.

Prevenzione: esiste una semplice soluzione di sicurezza web: non restituire i tag HTML al client. Questo ha l'ulteriore vantaggio di difendersi dall'iniezione di HTML, un attacco simile in base al quale l'attaccante inietta contenuto HTML semplice (come immagini o lettori flash invisibili ad alto volume) – non ad alto impatto ma sicuramente fastidioso ("per favore fallo smettere!"). Di solito, la soluzione alternativa consiste semplicemente nel convertire tutte le entità HTML, in modo che <script> venga restituito come <script> . L'altro metodo di disinfezione spesso utilizzato è l'uso di espressioni regolari per rimuovere i tag HTML utilizzando espressioni regolari su < e > , ma questo è pericoloso poiché molti browser interpretano correttamente HTML gravemente danneggiato. Meglio convertire tutti i personaggi nelle loro controparti sfuggite.

Errore comune di sicurezza Web n. 4: riferimenti a oggetti diretti non sicuri

Questo è un classico caso di fiducia nell'input dell'utente e di pagare il prezzo di una conseguente vulnerabilità di sicurezza. Un riferimento diretto all'oggetto significa che un oggetto interno come un file o una chiave di database viene esposto all'utente. Il problema è che l'attaccante può fornire questo riferimento e, se l'autorizzazione non viene applicata (o è interrotta), l'attaccante può accedere o fare cose a cui dovrebbe essere precluso.

Ad esempio, il codice ha un modulo download.php che legge e consente all'utente di scaricare file, utilizzando un parametro CGI per specificare il nome del file (es. download.php?file=something.txt ). Per errore o per pigrizia, lo sviluppatore ha omesso l'autorizzazione dal codice. L'autore dell'attacco può ora utilizzarlo per scaricare tutti i file di sistema a cui l'utente che esegue PHP ha accesso, come il codice dell'applicazione stesso o altri dati lasciati in giro sul server, come i backup. Uh Oh.

Un altro esempio di vulnerabilità comune è una funzione di reimpostazione della password che si basa sull'input dell'utente per determinare la password da reimpostare. Dopo aver fatto clic sull'URL valido, un utente malintenzionato può semplicemente modificare il campo del username nell'URL per dire qualcosa come "admin".

Per inciso, entrambi questi esempi sono cose che io stesso ho visto apparire spesso "in natura".

Prevenzione: eseguire l'autorizzazione dell'utente in modo corretto e coerente e inserire nella whitelist le scelte. Il più delle volte, tuttavia, l'intero problema può essere evitato archiviando i dati internamente e non facendo affidamento sul fatto che vengano passati dal client tramite parametri CGI. Le variabili di sessione nella maggior parte dei framework sono adatte a questo scopo.

Errore comune di sicurezza Web n. 5: configurazione errata della sicurezza

Nella mia esperienza, i server Web e le applicazioni che sono stati configurati in modo errato sono molto più comuni di quelli che sono stati configurati correttamente. Forse questo perché non mancano i modi per sbagliare. Qualche esempio:

1. Esecuzione dell'applicazione con il debug abilitato in produzione.
2. Avere l'elenco delle directory abilitato sul server, che perde informazioni preziose.
3. Esecuzione di software obsoleto (pensa ai plugin di WordPress, al vecchio PhpMyAdmin).
4. Avere servizi non necessari in esecuzione sulla macchina.
5. Non modificare chiavi e password predefinite. (Succede molto più frequentemente di quanto tu possa credere!)
6. Rivelando agli aggressori informazioni sulla gestione degli errori, come le tracce dello stack.

Prevenzione: disporre di un buon processo di "compilazione e distribuzione" (preferibilmente automatizzato), che può eseguire test durante la distribuzione. La soluzione di configurazione errata della sicurezza del povero è hook post-commit, per impedire che il codice esca con password predefinite e/o materiale di sviluppo integrato.

Errore comune di sicurezza Web n. 6: esposizione di dati sensibili

Questa vulnerabilità della sicurezza web riguarda la protezione delle criptovalute e delle risorse. I dati sensibili devono essere crittografati in ogni momento, anche in transito e inattivi. Nessuna eccezione. Le informazioni sulla carta di credito e le password degli utenti non devono mai viaggiare o essere archiviate in modo non crittografato e le password devono sempre essere crittografate. Ovviamente l'algoritmo di crittografia/hashing non deve essere debole: in caso di dubbio, gli standard di sicurezza web consigliano AES (256 bit e oltre) e RSA (2048 bit e oltre).

E mentre è ovvio che gli ID di sessione e i dati sensibili non dovrebbero viaggiare negli URL e che i cookie sensibili dovrebbero avere il flag di sicurezza attivato, questo è molto importante e non può essere enfatizzato eccessivamente.

Prevenzione:

• In transito: utilizza HTTPS con un certificato appropriato e PFS (Perfect Forward Secrecy). Non accettare nulla su connessioni non HTTPS. Avere il flag sicuro sui cookie.

• In deposito: è più difficile. Innanzitutto, devi ridurre la tua esposizione. Se non hai bisogno di dati sensibili, distruggili. I dati che non hai non possono essere rubati. Non archiviare mai i dati della carta di credito, poiché probabilmente non vorrai avere a che fare con la conformità PCI. Iscriviti con un processore di pagamento come Stripe o Braintree. In secondo luogo, se disponi di dati sensibili di cui hai effettivamente bisogno, archiviali crittografati e assicurati che tutte le password siano sottoposte a hash. Per l'hashing, si consiglia l'uso di bcrypt. Se non usi bcrypt, informati sulle tavole salate e arcobaleno.

E a rischio di affermare l'ovvio, non archiviare le chiavi di crittografia accanto ai dati protetti . È come riporre la bicicletta con un lucchetto che contiene la chiave. Proteggi i tuoi backup con la crittografia e mantieni le tue chiavi molto private. E, naturalmente, non perdere le chiavi!

Errore comune di sicurezza Web n. 7: controllo dell'accesso a livello di funzione mancante

Questo è semplicemente un errore di autorizzazione. Significa che quando una funzione viene chiamata sul server, non è stata eseguita l'autorizzazione corretta. Molte volte, gli sviluppatori fanno affidamento sul fatto che il lato server ha generato l'interfaccia utente e pensano che le funzionalità che non sono fornite dal server non siano accessibili al client. Non è così semplice, poiché un utente malintenzionato può sempre falsificare richieste alla funzionalità "nascosta" e non sarà scoraggiato dal fatto che l'interfaccia utente non renda questa funzionalità facilmente accessibile. Immagina che ci sia un pannello /admin e che il pulsante sia presente nell'interfaccia utente solo se l'utente è effettivamente un amministratore. Nulla impedisce a un utente malintenzionato di scoprire questa funzionalità e di utilizzarla in modo improprio se manca l'autorizzazione.

Prevenzione: sul lato server, l'autorizzazione deve essere sempre eseguita. Si Sempre. Nessuna eccezione o vulnerabilità comporterà seri problemi.

Errore comune nella sicurezza Web n. 8: falsificazione delle richieste tra siti (CSRF)

Questo è un bell'esempio di un attacco confuso di un vice in cui il browser viene ingannato da un'altra parte facendogli un uso improprio della sua autorità. Un sito di terze parti, ad esempio, può fare in modo che il browser dell'utente utilizzi in modo improprio la propria autorità per fare qualcosa per l'attaccante.

Nel caso di CSRF, un sito di terze parti invia richieste al sito di destinazione (ad es. la tua banca) utilizzando il tuo browser con i tuoi cookie/sessione. Se hai effettuato l'accesso a una scheda della home page della tua banca, ad esempio, e sono vulnerabili a questo attacco, un'altra scheda può far sì che il tuo browser utilizzi in modo improprio le sue credenziali per conto dell'attaccante, provocando il problema confuso del vice. Il vice è il browser che abusa della sua autorità (cookie di sessione) per fare qualcosa che l'attaccante gli dice di fare.

Considera questo esempio:

L'attaccante Alice vuole alleggerire il portafoglio di Todd bersaglio trasferendole parte dei suoi soldi. La banca di Todd è vulnerabile a CSRF. Per inviare denaro, Todd deve accedere al seguente URL:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Dopo che questo URL è stato aperto, a Todd viene presentata una pagina di successo e il trasferimento è terminato. Alice sa anche che Todd visita spesso un sito sotto il suo controllo su blog.aliceisawesome.com, dove inserisce il seguente snippet:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

Dopo aver visitato il sito Web di Alice, il browser di Todd pensa che Alice si colleghi a un'immagine ed emette automaticamente una richiesta HTTP GET per recuperare l'immagine, ma questo in realtà indica alla banca di Todd di trasferire $ 1500 ad Alice.

Per inciso, oltre a dimostrare la vulnerabilità CSRF, questo esempio mostra anche l'alterazione dello stato del server con una richiesta HTTP GET idempotente che è di per sé una grave vulnerabilità. Le richieste HTTP GET devono essere idempotenti (sicure), il che significa che non possono alterare la risorsa a cui si accede. Mai, mai e poi mai utilizzare metodi idempotenti per modificare lo stato del server.

Curiosità: CSRF è anche il metodo utilizzato dalle persone per ripieno di biscotti in passato fino a quando gli affiliati non sono diventati più saggi.

Prevenzione: archivia un token segreto in un campo modulo nascosto inaccessibile dal sito di terze parti. Ovviamente devi sempre verificare questo campo nascosto. Alcuni siti richiedono anche la tua password quando modificano impostazioni sensibili (come l'e-mail di promemoria della password, ad esempio), anche se sospetto che questo sia lì per prevenire l'uso improprio delle tue sessioni abbandonate (in un internet cafè, ad esempio).

Errore comune di sicurezza Web n. 9: utilizzo di componenti con vulnerabilità note

Il titolo dice tutto. Lo classificherei di nuovo come più un problema di manutenzione/distribuzione. Prima di incorporare un nuovo codice, fai qualche ricerca, possibilmente un po' di auditing. L'uso del codice che hai ricevuto da una persona a caso su GitHub o su qualche forum potrebbe essere molto conveniente, ma non è privo di rischi di gravi vulnerabilità della sicurezza web.

Ho visto molti casi, ad esempio, in cui i siti sono diventati di proprietà (ovvero, in cui un estraneo ottiene l'accesso amministrativo a un sistema), non perché i programmatori fossero stupidi, ma perché un software di terze parti è rimasto senza patch per anni in produzione. Questo succede sempre con i plugin di WordPress, ad esempio. Se pensi che non troveranno la tua installazione nascosta di phpmyadmin , lascia che ti presenti dirbuster.

La lezione qui è che lo sviluppo del software non termina quando l'applicazione viene distribuita. Ci deve essere documentazione, test e piani su come mantenerlo aggiornato, specialmente se contiene componenti di terze parti o open source.

Prevenzione:

• Fai attenzione. Oltre ovviamente a usare cautela quando si utilizzano tali componenti, non essere un programmatore copia-incolla. Ispeziona attentamente il pezzo di codice che stai per inserire nel tuo software, poiché potrebbe essere danneggiato in modo irreparabile (o in alcuni casi, attacchi alla sicurezza Web intenzionalmente dannosi a volte vengono involontariamente invitati in questo modo).

• Rimani aggiornato. Assicurati di utilizzare le versioni più recenti di tutto ciò di cui ti fidi e di avere un piano per aggiornarle regolarmente. Almeno iscriviti a una newsletter sulle nuove vulnerabilità di sicurezza relative al prodotto.

Errore comune di sicurezza Web n. 10: reindirizzamenti e inoltri non convalidati

Questo è ancora una volta un problema di filtraggio dell'input. Supponiamo che il sito di destinazione abbia un modulo redirect.php che accetta un URL come parametro GET . La manipolazione del parametro può creare un URL su targetsite.com che reindirizza il browser a malwareinstall.com . Quando l'utente vede il collegamento, vedrà targetsite.com/blahblahblah che l'utente ritiene attendibile e su cui è sicuro fare clic. Non sanno che questo li trasferirà effettivamente su una pagina di rilascio di malware (o qualsiasi altra pagina dannosa). In alternativa, l'attaccante potrebbe reindirizzare il browser a targetsite.com/deleteprofile?confirm=1 .

Vale la pena ricordare che inserire l'input definito dall'utente non disinfettato in un'intestazione HTTP potrebbe portare all'iniezione di intestazione, il che è piuttosto negativo.

Prevenzione: le opzioni includono:

• Non eseguire affatto i reindirizzamenti (sono raramente necessari).
• Avere un elenco statico di posizioni valide a cui reindirizzare.
• Inserisci nella whitelist il parametro definito dall'utente, ma può essere complicato.

Epilogo

Spero di essere riuscito a stuzzicare un po' il tuo cervello con questo post e a introdurre una sana dose di paranoia e consapevolezza della vulnerabilità della sicurezza del sito web.

Il punto centrale qui è che le pratiche software secolari esistono per una ragione e ciò che si applicava in passato per gli overflow del buffer, si applica ancora oggi alle stringhe in salamoia in Python. I protocolli di sicurezza ti aiutano a scrivere (più) programmi corretti, a cui tutti i programmatori dovrebbero aspirare.

Si prega di utilizzare questa conoscenza in modo responsabile e di non testare le pagine senza autorizzazione!

Per ulteriori informazioni e attacchi lato server più specifici, dai un'occhiata a: https://www.owasp.org/index.php/Category:Attack.

Il feedback su questo post e sui suoi consigli per la mitigazione è benvenuto e apprezzato. Sono previsti post futuri correlati, in particolare sulla questione delle vulnerabilità della sicurezza informatica del DDoS (Distributed Denial-of-Service) e della vecchia scuola (non web). Se hai una richiesta specifica sul tipo di protezione web di cui scrivere, non esitare a contattarmi direttamente all'indirizzo [email protected].

Alla sicurezza del sito web! Saluti.