Changelog: il progetto OWASP Top 10

Le applicazioni Web sono esplose in complessità negli ultimi dieci anni. Si sono evoluti da semplici contenitori per moduli di contatto e sondaggi in applicazioni in piena regola. Possiamo confrontarli con le pesanti applicazioni desktop, sia per dimensioni che per prestazioni. Con un forte aumento della complessità e un numero crescente di applicazioni ricche di funzionalità, è diventata una necessità investire molto tempo e molta attenzione nel rendere tutti i componenti dell'applicazione il più sicuri possibile. Il massiccio aumento degli utenti di Internet ha reso ancora più importante affrontare il problema della protezione dei dati e degli utenti delle applicazioni. C'è un vasto pool di minacce che cercano di insinuarsi e causare forti mal di testa a tutte le persone coinvolte.

Nel 2001 è entrata in scena una nuova organizzazione. Il suo obiettivo era combattere i problemi di sicurezza che interessano siti Web e applicazioni. È stato opportunamente chiamato Open Web Application Security Project (OWASP). Oggi pubblica risorse, organizza conferenze e propone standard sulla sicurezza del web e delle applicazioni. Uno standard de facto per la sicurezza delle applicazioni web è il progetto OWASP Top Ten. Elenca le dieci minacce alla sicurezza più diffuse. I fattori influenti nel decidere cosa ottenere sono stati un'ampia quantità di dati e feedback della comunità. Alla fine del 2017 c'è stato un aggiornamento del progetto. Diversi nuovi problemi critici per molte applicazioni Web moderne hanno ricevuto il loro posto, mentre alcuni sono sfuggiti all'elenco.

Questo articolo integra l'elenco originale e illustra le ultime modifiche all'elenco. Descrive le minacce, cerca di fornire esempi chiari per una più facile comprensione e propone modi per combattere le minacce alla sicurezza.

Problemi rimossi dall'elenco OWASP Top 10

Prima dell'aggiornamento del 2017, l'elenco del 2013 era quello più recente. Considerando i cambiamenti nei modi in cui le applicazioni Web vengono ora create e utilizzate, aveva senso solo eseguire una revisione approfondita. I microservizi stanno prendendo il loro pezzo della torta e nuovi framework fantastici e brillanti stanno sostituendo l'equipaggiamento da battaglia del codice vanilla. Questi fatti significano che alcune delle minacce elencate prima sono state rimosse e alcune nuove hanno preso il loro posto.

Ci assicureremo di rinfrescare la nostra memoria dei problemi a lungo dimenticati in questo articolo, oltre a introdurre i nuovi lupi cattivi. Imparare la storia è l'unico modo sicuro per non ripetere gli stessi errori.

Falsificazione di richieste tra siti

La falsificazione di richieste cross-site (CSRF) è uno dei "perdenti" nella recente iterazione del progetto. È andato via perché molti framework Web moderni includono meccanismi di difesa CSRF. La probabilità di esporre le vostre applicazioni alla minaccia diminuisce quindi rapidamente.

Indipendentemente dal fatto che CSRF esca dall'elenco, è comunque bene rinfrescarci la memoria. Assicuriamoci che non torni più forte che mai.

In sostanza, CSRF è un exploit che sembra una bomba fumogena. Un utente malintenzionato inganna un utente ignaro per eseguire una richiesta o un'azione indesiderata all'interno di un'applicazione web. In poche parole, un utente malintenzionato costringe la sua vittima a inviare una richiesta a un'applicazione di terze parti e la vittima non è a conoscenza che la richiesta sia mai stata inviata. La richiesta potrebbe essere una richiesta HTTP GET per recuperare una risorsa o, peggio ancora, una richiesta HTTP POST che modifica una risorsa sotto il controllo della vittima. Durante l'attacco, la vittima pensa che tutto vada bene, il più delle volte senza nemmeno accorgersi che qualcosa sta accadendo in background. Dopo che l'aria si è schiarita, il danno è fatto o manca qualcosa e nessuno sa cosa sia successo.

La riuscita dell'autenticazione dell'utente precedente all'interno dell'applicazione di destinazione è ciò che consente alla trap di essere efficace. L'utente a un certo punto prima dell'attacco ha effettuato l'accesso a un'applicazione. L'applicazione ha inviato alla vittima un cookie per ricordarla. Una volta che il browser web ha inviato la richiesta dannosa, il cookie viene automaticamente inviato insieme a qualsiasi potenziale carico utile e l'applicazione non si oppone a servire la richiesta a un utente che già conosce.

Uno degli esempi più famosi è l'inganno di un utente a trasferire denaro dal proprio account a quello controllato da un utente malintenzionato. Un utente accede a un sistema di e-banking per controllare il saldo del proprio conto. Successivamente, visitano un forum online per controllare le recensioni di un nuovo telefono cellulare. Un aggressore, pescando con la dinamite, pubblica una recensione che include un'immagine con un collegamento ipertestuale apparentemente interrotto. Invece di un vero collegamento ipertestuale, l'attaccante utilizza un collegamento ipertestuale che il sistema di e-banking utilizza internamente per trasferire denaro dal conto A al conto B: https://payments.dummybank.com?receiver=attacker&amount=100 . Il sistema bancario fa dell'utente autenticato il mittente e il valore del parametro “destinatario” il destinatario dei fondi. Naturalmente, l'attaccante specifica il proprio account offshore come ricevitore.

Poiché il browser carica automaticamente le immagini durante il rendering della pagina, la richiesta avviene in background. Se il sistema di pagamento della banca implementa trasferimenti di denaro utilizzando una richiesta HTTP GET, nulla impedisce che si verifichi il disastro. Si noti che l'esempio è semplice e molto probabilmente i trasferimenti non vengono gestiti tramite HTTP GET. Tuttavia, l'attaccante può, con solo un po' più di difficoltà, riuscire a modificare l'attributo “azione” nel modulo di invio dei messaggi HTML del forum. Il browser invia quindi la richiesta al sistema di pagamento della banca, anziché al back-end del forum.

Rubare denaro è solo uno dei tanti esempi là fuori. Anche la modifica degli indirizzi e-mail degli utenti o l'esecuzione di acquisti non intenzionali rientrano in questa categoria. Come spesso accade, l'ingegneria sociale e alcune conoscenze tecniche sono una leva efficace contro un errore di ingegneria del software.

Quando progetti i tuoi sistemi, tieni presente quanto segue:

• Non utilizzare richieste HTTP GET per incapsulare azioni che modificano una risorsa. Dovresti usare queste richieste solo per recuperare le informazioni. Ricorda, la regola pratica è rendere idempotenti le richieste GET.
• Do , quando si trasferiscono i dati internamente utilizzando le richieste HTTP POST, tendono a inviare i dati in JSON, XML o in un altro formato diverso dalla codifica dei parametri come stringa di query. L'utilizzo di un formato dati non banale riduce il pericolo che qualcuno crei un modulo HTML falso che invierà i dati al tuo servizio.
• Assicurati di creare e includere un token unico e imprevedibile nei tuoi moduli HTML. Questi token dovrebbero anche essere univoci per ogni richiesta. Il controllo della presenza e della correttezza di tali token ridurrà i rischi che si verifichino minacce. Per scoprire il token e utilizzarlo nelle loro richieste false, gli aggressori dovrebbero accedere al tuo sistema e prendere un token direttamente da lì. Poiché i token sono monouso, non possono riutilizzarli nel codice dannoso.

Questa vulnerabilità ha effetti ancora peggiori se abbinata al cross-site scripting (XSS). Se un utente malintenzionato può iniettare codice dannoso in un sito Web o in un'applicazione preferiti, l'ambito dell'attacco diventa molto più significativo e pericoloso. Ancora più critico, gli aggressori possono aggirare alcuni dei meccanismi di protezione contro CSRF se sono possibili attacchi XSS.

Tieni presente che CSRF non è scomparso, semplicemente non è così comune come una volta.

Reindirizzamenti e inoltri non convalidati

Molte applicazioni, dopo aver terminato un'azione, reindirizzano o inoltrano un utente a un'altra parte della stessa o anche a un'altra applicazione. Ad esempio, l'accesso corretto a un'applicazione attiva un reindirizzamento alla home page o alla pagina inizialmente visitata dall'utente. Molto spesso, la destinazione fa parte dell'azione del modulo o dell'indirizzo dei collegamenti. Se il componente che gestisce il reindirizzamento o l'inoltro non si assicura che l'indirizzo di destinazione sia effettivamente quello generato dall'applicazione, si verifica una potenziale minaccia. Questa è una vulnerabilità di sicurezza chiamata "reindirizzamenti e inoltri non convalidati".

I due motivi principali per cui reindirizzamenti e inoltri non convalidati sarebbero mai considerati pericolosi sono il phishing e il dirottamento delle credenziali. Un utente malintenzionato può riuscire a modificare la posizione di destinazione di reindirizzamento/inoltro e inviare un utente a un'applicazione dannosa quasi indistinguibile da quella originale. Un utente ignaro rivela le proprie credenziali e le informazioni riservate a una terza parte malintenzionata. Prima che si rendano conto di cosa era successo, è già troppo tardi.

Ad esempio, le applicazioni Web implementano molto spesso l'accesso con supporto per i reindirizzamenti all'ultima pagina visitata. Per poterlo fare facilmente, l'attributo action di un modulo HTML potrebbe avere un aspetto simile a http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Sei un grande ammiratore dei cuccioli, quindi aveva senso installare un'estensione del browser che sostituisse le favicon del sito Web con le miniature dei tuoi cuccioli preferiti. Sfortunatamente, è un mondo cane mangia cane. L'autore dell'estensione del browser ha deciso di incassare il tuo amore incondizionato e di introdurre un'ulteriore "funzione". Ogni volta che visiti il ​​tuo sito di fan dei cuccioli preferito, sostituisce il parametro "url" nell'attributo action del modulo con un collegamento al proprio sito. Dal momento che il sito sembra esattamente lo stesso, quando fornisci i dettagli della tua carta di credito per acquistare carte da gioco per cuccioli, in realtà stai finanziando un malintenzionato, non il tuo hobby.

La risoluzione della vulnerabilità implica il controllo della posizione di destinazione assicurandosi che sia quella prevista. Se un framework o una libreria esegue il reindirizzamento completo o la logica di inoltro, è utile controllare l'implementazione e aggiornare il codice, se necessario. In caso contrario, è necessario eseguire controlli manuali per proteggersi dall'attacco.

Ci sono diversi tipi di controlli che puoi fare. Per la migliore protezione, usa una combinazione di diversi approcci invece di attenersi a uno solo di essi.

• Convalida l'URL in uscita assicurandoti che punti al dominio che controlli.
• Invece di utilizzare indirizzi espliciti, codificarli sul front-end e quindi decodificarli e convalidarli sul back-end.
• Prepara una whitelist di URL affidabili. Consente l'inoltro e il reindirizzamento solo alle posizioni autorizzate. Preferisci questo approccio per mantenere una lista nera. Le liste nere di solito vengono riempite con nuovi elementi solo quando succede qualcosa di brutto. Le whitelist sono più restrittive.
• Impiega un approccio utilizzato da LinkedIn e alcune altre applicazioni: presenta ai tuoi utenti una pagina che chiede loro di confermare un reindirizzamento/inoltro, chiarendo che stanno abbandonando la tua applicazione.

Problemi uniti

La maggior parte dei problemi nell'elenco può essere etichettata come difetti nell'implementazione, dovuti alla mancanza di conoscenza oa un'indagine non sufficientemente approfondita di potenziali minacce. Entrambi questi motivi possono essere attribuiti alla mancanza di esperienza e la soluzione per considerarli in futuro è facile: assicurati solo di saperne di più ed essere più approfondito. Uno particolarmente complicato si basa su una combinazione del tratto pericoloso (ma molto umano) di fare troppe ipotesi insieme alla difficoltà di sviluppare e mantenere sistemi informatici complessi. Una vulnerabilità che rientra in questa categoria è il "controllo dell'accesso interrotto".

Controllo degli accessi interrotto

Una vulnerabilità è causata da un'autorizzazione e un controllo dell'accesso inadeguati o completi per alcune parti dell'applicazione. Nelle precedenti iterazioni del progetto OWASP Top Ten, c'erano due problemi: riferimenti diretti agli oggetti non sicuri e controllo dell'accesso a livello di funzione mancante. Ora sono fusi in uno a causa della loro somiglianza.

Riferimenti diretti agli oggetti

I riferimenti diretti agli oggetti vengono spesso utilizzati negli URL per identificare le risorse su cui si opera. Ad esempio, quando un utente accede, può visitare il proprio profilo facendo clic su un collegamento che contiene l'identificatore del profilo. Se lo stesso identificatore è archiviato nel database e viene utilizzato per recuperare le informazioni sul profilo e l'applicazione presume che le persone possano accedere alla pagina del profilo solo tramite una pagina di accesso, la modifica dell'identificatore del profilo nell'URL espone le informazioni del profilo di un altro utente.

Un'applicazione che imposta l'URL del modulo di eliminazione del profilo http://myapp.example.com/users/15/delete chiarisce che ci sono almeno altri 14 utenti all'interno dell'applicazione. Capire come arrivare al modulo di eliminazione di altri utenti non è scienza missilistica in questo caso.

La soluzione a questo problema consiste nell'eseguire controlli di autorizzazione per ciascuna risorsa senza presumere che solo determinati percorsi possano essere presi per accedere ad alcune parti dell'applicazione. Inoltre, la rimozione dei riferimenti diretti e l'utilizzo di quelli indiretti è un altro passo avanti perché rende difficile per gli utenti malintenzionati capire come viene creato il riferimento.

Durante lo sviluppo, per precauzione, annotare un semplice diagramma della macchina a stati. Lascia che gli stati rappresentino pagine diverse all'interno dell'applicazione e le transizioni che gli utenti possono intraprendere. Ciò semplifica l'elenco di tutte le transizioni e le pagine che richiedono un'attenzione speciale.

Controllo dell'accesso a livello di funzione mancante

Il controllo dell'accesso a livello di funzione mancante è molto simile a riferimenti a oggetti diretti non sicuri. In questo caso, gli utenti modificano l'URL o qualche altro parametro per tentare di accedere alle parti protette dell'applicazione. Se non esiste un controllo di accesso adeguato che esamini i livelli di accesso, un utente può ottenere un accesso privilegiato alle risorse dell'applicazione o almeno una certa conoscenza della loro esistenza.

Prendendo in prestito dall'esempio per i riferimenti diretti agli oggetti, se un'applicazione presuppone che un utente che visita il modulo di eliminazione sia un superutente solo perché i superutenti possono vedere il collegamento al modulo di eliminazione, senza effettuare ulteriori autorizzazioni, si apre un'enorme falla di sicurezza. Contare sulla disponibilità di alcuni elementi dell'interfaccia utente non è un controllo degli accessi adeguato.

Il problema viene risolto assicurandosi sempre di eseguire controlli in tutti i livelli dell'applicazione. L'interfaccia front-end potrebbe non essere l'unico modo in cui gli utenti malintenzionati possono accedere al livello del tuo dominio. Inoltre, non fare affidamento sulle informazioni trasmesse dagli utenti sui loro livelli di accesso. Esegui il controllo della sessione appropriato e ricontrolla sempre i dati ricevuti. Solo perché il corpo della richiesta dice che l'utente è un amministratore, non significa che lo sia.

Il controllo dell'accesso interrotto ora combina tutti i problemi correlati al controllo dell'accesso insufficiente, sia a livello di applicazione che a livello di sistema, come un'errata configurazione del file system.

Nuovi numeri nella Top 10 di OWASP

L'avvento di nuovi framework front-end e l'adozione di nuove pratiche di sviluppo software hanno spostato i problemi di sicurezza su argomenti completamente nuovi. Le nuove tecnologie sono anche riuscite a risolvere alcuni problemi comuni con cui avevamo a che fare prima manualmente. Pertanto, è diventato utile rivedere l'elenco e adattarlo di conseguenza alle tendenze moderne.

Entità esterne XML

Lo standard XML offre un'idea poco conosciuta chiamata entità esterna, che fa parte della definizione del tipo di dati (DTD) del documento. Consente agli autori di documenti di specificare collegamenti a entità esterne che possono quindi essere referenziate e incluse nel documento principale. Un esempio molto semplice sarebbe:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Durante l'analisi, un riferimento &bar; viene sostituito con il contenuto dell'entità definita, ottenendo così <foo>baz</foo> .

Se l'applicazione accettasse input esterni e lo includesse, senza alcun controllo, direttamente nella definizione del documento XML, sarebbe possibile un'ampia gamma di fughe di dati e attacchi.

La cosa magica è che l'entità non deve essere una semplice stringa: può essere un riferimento a un file nel file system. Il parser XML sarà lieto di prendere il contenuto del file specificato e includerlo nella risposta generata, rivelando potenzialmente informazioni di sistema sensibili. Come illustrato da OWASP, sarebbe molto facile ottenere informazioni sugli utenti del sistema definendo l'entità come

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Una "caratteristica" particolarmente problematica di questa vulnerabilità è la possibilità di eseguire facilmente un attacco denial-of-service. Un modo semplice per farlo sarebbe elencare il contenuto di un file infinito come /dev/random . L'altro consiste nel creare una sequenza di entità, ognuna delle quali fa riferimento più volte alla precedente. Questo trasforma il riferimento finale in una radice di un albero potenzialmente molto ampio e profondo la cui analisi potrebbe esaurire la memoria di sistema. Questo attacco è anche conosciuto come Billion Laughs. Come mostrato su Wikipedia, vengono definite una serie di entità fittizie, che creano un'opportunità per un utente malintenzionato di includere un miliardo di lol nel documento finale.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

È possibile prevenire gli exploit di entità esterne XML utilizzando un formato di dati meno complesso. JSON è un buon sostituto, a condizione che vengano prese anche alcune precauzioni a causa di possibili attacchi contro di esso. L'aggiornamento delle librerie XML è d'obbligo, insieme alla disabilitazione dell'elaborazione di entità esterne e del DTD. Come sempre, convalida e disinfetta i dati provenienti da fonti non attendibili prima di utilizzarli o includerli nei tuoi documenti.

Deserializzazione insicura

Durante la scrittura del codice, gli sviluppatori hanno il potere di controllare i sistemi che stanno sviluppando utilizzando il codice che scrivono. Quanto sarebbe fantastico controllare il comportamento di sistemi di terze parti che scrivono solo una piccola parte o addirittura nessun codice? Grazie al fatto che le persone non sono perfette e che le biblioteche hanno dei difetti, questo è sicuramente possibile.

Lo stato e la configurazione dell'applicazione sono spesso serializzati e archiviati. A volte i browser fungono da motori di archiviazione se i dati serializzati sono strettamente associati all'utente corrente. Un'applicazione che cerca di essere intelligente e di risparmiare tempo di elaborazione potrebbe utilizzare un cookie per contrassegnare che un utente ha effettuato l'accesso. Poiché il cookie può essere creato solo dopo che l'accesso è stato eseguito correttamente, ha senso memorizzare il nome utente nel cookie. Un utente viene quindi autenticato e autorizzato in base all'esistenza e al contenuto del cookie. Se le persone non fossero malintenzionate, nulla potrebbe andare storto. Ad essere onesti, non devono nemmeno essere curiosi.

Se un utente curioso trovasse un cookie sul proprio computer, potrebbe vedere qualcosa del genere:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Un dizionario Python perfettamente valido serializzato su JSON, niente di speciale. L'utente sempre curioso potrebbe modificare la data di scadenza per impedire all'applicazione di forzare la disconnessione. Un utente ancora più curioso potrebbe provare a modificare il nome utente in "jane.doe" . Se questo nome utente esistesse, si aprirebbe un mondo completamente nuovo per l'utente ignaro che ora ha accesso ai dati privati.

Un semplice esempio di serializzazione dei dati in JSON e di mantenere tutto trasparente è tutt'altro che la cosa peggiore che può capitarti. Se un utente malintenzionato riesce a modificare alcuni dati serializzati, potrebbe essere in grado di modificarli in un modo che costringe il sistema a eseguire codice arbitrario.

Supponiamo che tu stia creando un'API REST che consente alle persone di scrivere i propri modelli di machine learning in Python e caricarli sul tuo servizio. Il servizio valuterà i modelli caricati e li addestrerà utilizzando i tuoi set di dati. Ciò consente alle persone di utilizzare le tue risorse informatiche e un'ampia quantità di set di dati disponibili per la creazione di modelli semplice e veloce.

Il servizio non memorizza il codice in formato testo normale. Gli utenti selezionano il loro codice, lo crittografano utilizzando la loro chiave privata e lo inviano all'API per l'addestramento. Quando il servizio deve eseguire un modello, decrittografa il codice, lo deseleziona e lo esegue. La parte difficile è che il protocollo di pickle non è sicuro. Il codice può essere costruito in modo da consentire l'esecuzione di codice dannoso arbitrario durante la deserializzazione.

Il protocollo pickle di Python consente alle classi di definire un metodo __reduce__ , che restituisce informazioni su come deserializzare un oggetto personalizzato. Uno dei valori restituiti supportati è una tupla di due argomenti: un callable e una tupla di argomenti da passare al callable. Tenendo conto che il tuo sistema di addestramento del modello ML mira a fornire la massima flessibilità della struttura del codice, è possibile scrivere il seguente codice:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Una volta che l'oggetto deve essere deserializzato (deselezionato), viene chiamato un list di funzioni con un solo argomento. L' list di funzioni è un costruttore di elenchi in Python e la funzione itertools.count produce un iteratore infinito di valori, a partire dal parametro passato. Trasformare un iteratore infinito in un elenco finito può avere conseguenze disastrose per le prestazioni e la stabilità del tuo sistema.

L'unica vera cura per questo tipo di vulnerabilità è scegliere di non deserializzare i dati provenienti da fonti esterne. Nel caso ciò non sia possibile, si suggerisce di utilizzare un checksum o una firma digitale per prevenire la deserializzazione dei dati potenzialmente modificati da un utente malintenzionato. Inoltre, prova a configurare un ambiente sandbox disaccoppiato dal tuo sistema principale per limitare gli effetti dei problemi che potrebbero sorgere.

Quando si utilizzano librerie esterne per la deserializzazione dei dati, ad esempio da XML o JSON, provare a selezionare quelle che consentono di eseguire controlli del tipo di oggetto prima che venga eseguita una vera e propria procedura di deserializzazione. Ciò potrebbe rilevare tipi di oggetti imprevisti il ​​cui unico scopo è danneggiare il sistema.

Come per tutte le altre azioni eseguite dall'applicazione, imporre la registrazione e il monitoraggio estesi. Deserializzazioni che si verificano spesso o che falliscono più del normale sono segnali che sta accadendo qualcosa di brutto. Cogli i problemi in anticipo.

Registrazione e monitoraggio insufficienti

Quanto tempo dedichi per assicurarti di registrare tutti gli avvisi e gli errori che si verificano nella tua applicazione? Memorizzi solo gli errori che si verificano nel codice o registri anche gli errori di convalida? Cosa succede quando le regole aziendali del tuo dominio non vengono soddisfatte? La mancata persistenza di tutte le attività errate e sospette nell'applicazione rappresenta una compromissione della sicurezza e dei dati.

Immagina il seguente scenario. La tua applicazione contiene una pagina di accesso, come la maggior parte di loro. Il modulo ha due campi, uno per l'inserimento di un'e-mail e l'altro per la password. Se un utente tenta di accedere e fornisce una password errata, può riprovare. Sfortunatamente, il numero di tentativi errati non è limitato, quindi la pagina di accesso non verrà bloccata dopo N tentativi falliti. Un utente malintenzionato può sfruttare questa opportunità e, data un'e-mail corretta, continuare a inserire le password da una tabella arcobaleno fino a quando una combinazione non riesce. A condizione che la tua applicazione sia sufficientemente sicura e tu abbia eseguito l'hashing delle password prima di inserirle in un database, questo particolare attacco non funzionerà. Tuttavia, hai un meccanismo per identificare le intrusioni?

Solo perché questo tentativo non è riuscito ad aprire la tua pagina di accesso, non significa che qualcun altro non lo farà. La pagina di accesso probabilmente non è nemmeno l'unica potenziale backdoor che hai. Se non fosse per qualcos'altro, qualcuno potrebbe provare a usare il controllo di accesso interrotto contro di te. Anche le applicazioni perfettamente realizzate dovrebbero sapere che qualcuno sta cercando di attaccarle, anche se potrebbe non essere possibile. È sempre così, però.

Per fare del tuo meglio per proteggerti da tali attacchi, procedi nel seguente modo:

• Registra tutti gli errori e gli avvisi che si verificano nell'applicazione, siano esse eccezioni generate nel codice o errori di controllo dell'accesso, convalida e manipolazione dei dati. Tutte le informazioni memorizzate devono essere replicate e mantenute per un tempo sufficientemente lungo da rendere possibile l'ispezione e l'analisi retrospettive.
• È importante determinare il formato e il livello di persistenza. Avere un file enorme con un formato di testo arbitrario è facile da realizzare; elaborarlo in seguito non lo è. Scegli un'opzione di archiviazione che semplifichi l'archiviazione e la lettura dei dati e un formato che consenta una (de)serializzazione facile e veloce. L'archiviazione di JSON in un database che consente l'accesso rapido semplifica l'utilizzo. Mantieni il database piccolo eseguendo regolarmente il backup.
• Se hai a che fare con dati importanti e preziosi, tieni una traccia di azioni che possono essere seguite per verificare lo stato finale. Implementare un meccanismo per prevenire la manomissione dei dati.
• Fai in modo che i sistemi in background analizzino i registri e ti avvisino se viene fuori qualcosa. I controlli, semplici come testare se un utente tenta ripetutamente di accedere a una parte protetta dell'applicazione, aiutano. Tuttavia, non sovraccaricare il sistema con controlli fittizi. I sistemi di monitoraggio devono essere eseguiti come servizi separati e non devono influire sulle prestazioni del sistema principale.

Quando si risolve il problema, prestare particolare attenzione a non divulgare i registri degli errori agli utenti esterni. In caso contrario, sei suscettibile all'esposizione di informazioni sensibili. La registrazione e il monitoraggio dovrebbero aiutarti a risolvere i problemi, non gli aggressori a svolgere il proprio lavoro in modo più efficiente.

Prossimi passi

È importante essere consapevoli delle potenziali minacce e vulnerabilità nelle applicazioni web. È ancora più importante iniziare a identificarli nelle tue applicazioni e applicare le patch per rimuoverli.

L'attenzione alla sicurezza delle applicazioni è una parte importante di tutte le fasi del progetto di sviluppo del software. Gli architetti del software, gli sviluppatori e i tester devono tutti incorporare le procedure di test del software nei loro flussi di lavoro. È utile utilizzare elenchi di controllo di sicurezza e test automatizzati nelle fasi appropriate del processo di sviluppo del software per ridurre il rischio per la sicurezza.

Sia che tu stia analizzando un'applicazione esistente o sviluppandone una nuova, dovresti esaminare il progetto OWASP Application Security Verification Standard Project (ASVS). L'obiettivo del progetto è sviluppare uno standard per la verifica della sicurezza delle applicazioni. Lo standard enumera i test e i requisiti per lo sviluppo di applicazioni Web sicure. Ai test vengono assegnati livelli da uno a tre, dove uno indica la minor quantità di pericolo e tre indica la più alta minaccia potenziale. La classificazione consente ai gestori delle applicazioni di decidere quali minacce sono più probabili e importanti. Non è necessario includere ogni test all'interno di ogni applicazione.

Sia i progetti di applicazioni Web nuovi che quelli esistenti, in particolare quelli che seguono i principi Agile, beneficiano di una pianificazione strutturata degli sforzi per proteggere le loro applicazioni. La pianificazione dei test OWASP ASVS è più semplice se si decide di utilizzare OWASP Security Knowledge Framework. È un'applicazione per la gestione di sprint orientati ai test di sicurezza, fornita con una serie di esempi su come risolvere problemi di sicurezza comuni e liste di controllo facili da seguire basate su OWASP ASVS.

Se hai appena iniziato a esplorare la sicurezza delle applicazioni Web e hai bisogno di un ambiente sandbox sicuro, utilizza un'implementazione di applicazioni Web di OWASP: WebGoat. È un'implementazione intenzionalmente non sicura di un'applicazione web. L'applicazione ti guida attraverso le lezioni, con ogni lezione concentrata su una minaccia alla sicurezza.

Durante lo sviluppo dell'applicazione, assicurati di:

• Identificare e dare priorità alle minacce. Definisci quali minacce possono verificarsi realisticamente e rappresentare un rischio per la tua applicazione. Dai la priorità alle minacce e decidi quali meritano il massimo sforzo di sviluppo e test. Non ha molto senso fare molti sforzi per risolvere la registrazione e il monitoraggio insufficienti se stai servendo un blog statico.
• Valuta l'architettura e il design della tua applicazione. Alcune vulnerabilità sono molto difficili da risolvere durante le fasi successive dello sviluppo dell'applicazione. Ad esempio, se si intende eseguire codice di terze parti e non si prevede di utilizzare un ambiente sandbox, sarà molto difficile difendersi da attacchi di deserializzazione e injection non sicuri.
• Aggiorna il processo di sviluppo del software. Il test contro le minacce delle applicazioni Web deve, per quanto possibile, essere un processo automatizzato. È utile aumentare i flussi di lavoro CI/CD con test automatizzati che cercano di trovare falle di sicurezza. Puoi persino utilizzare il tuo sistema di unit test esistente per sviluppare test di sicurezza ed eseguirli periodicamente.
• Impara e migliora. L'elenco dei problemi e delle vulnerabilità non è statico e sicuramente non è limitato a dieci o quindici minacce. Nuove funzionalità e idee aprono le porte a nuovi tipi di attacchi. È importante leggere le tendenze attuali nel mondo della sicurezza delle applicazioni Web per rimanere aggiornati. Applica ciò che impari; altrimenti stai perdendo tempo.

Conclusione

Anche se, come suggerisce il nome, l'OWASP Top Ten Project elenca solo dieci vulnerabilità di sicurezza, ci sono migliaia di possibili trappole e backdoor che minacciano le tue applicazioni e, soprattutto, i tuoi utenti ei loro dati. Assicurati di essere alla ricerca e aggiorna costantemente le tue conoscenze perché i cambiamenti e i miglioramenti delle tecnologie hanno sia vantaggi che svantaggi.

Oh, e, non dimenticare, il mondo non è in bianco e nero. Le vulnerabilità della sicurezza non vengono da sole; sono spesso intrecciati. Essere esposti a uno spesso significa che un gruppo di altri sono dietro l'angolo, in attesa di alzare le loro brutte teste e a volte, anche se non è colpa tua, come sviluppatore della sicurezza del sistema, sei comunque destinato a riparare le scappatoie per frenare crimine informatico. Per un esempio, vedi I numeri delle carte di credito hackerate sono ancora compatibili con Google .