Web Application

Scoprire le vulnerabilità delle web application

Scritto il 01/02/2016 • Sicurezza informatica, vulnerability assessment

Cosa sono le web application? Sono tutti i siti internet dotati di funzioni applicative specifiche: il sito che ci fa leggere la posta elettronica tramite browser è una applicazione web, il sito per pagare le multe online è una applicazione web, anche il sito che stai leggendo è una applicazione web, si basa su WordPress e mi permette di scrivere un articolo da solo senza essere un programmatore di siti.

Punto primo: io, utente delle web application

Le applicazioni web sono diventate milioni, ogni azienda ne ha anche più d’una e sono accessibili da qualsiasi parte al mondo.  Questa è quindi la prima vulnerabilità? Forse si, ma andiamo a ritroso e partiamo piuttosto da quello che comunemente facciamo noi utenti.

Password di accesso = Password1

La sicurezza delle web application parte dalle passwordIl comportamento utente è fondamentale per la sicurezza soprattutto perché le credenziali di accesso al sistema sono gestite quasi sempre in autonomia dall’utente.
Siccome gestire decine di siti con altrettante password è una noia terribile, tutti le gestiamo in maniera banale. Il risultato è che mettiamo password identiche, semplici, riconducibili a dati personali, il che significa regalare a sconosciuti le chiavi di casa.

Un’ottima soluzione a questo problema è utilizzare un password manager.

Un buon password manager risolve il problema delle password perché:

  1. se le ricorda tutte con una sola password di accesso
  2. crea in automatico password inattaccabili, del tipo O6prth$!3%$3gGgòI
  3. segnala eventuali password banali o poco sicure

Tra i migliori del mercato ne segnalo due:

  • Clipperz per la sua progettazione sicura con un database inaccessibile agli stessi sviluppatori del sito
  • Lastpass perché, nella versione enterprise, le aziende possono gestire centralmente le password  tramite una console centralizzata; i dipendenti possono quindi accedere ai vari portali senza neppure conoscere le password di accesso

Il WiFi insicuro

Altro punto critico che vede l’utente protagonista è il WiFi. Nel momento in cui scrivo questo articolo sono collegato al WiFi di un albergo e ci sono altre 19 persone collegate allo stesso WiFi:

wifi hotel

Che rischio corro se lavoro da un WiFi come questo, o meglio, che rischio faccio correre alla mia azienda con il mio comportamento?

Dipende dall’applicazione web. Se non è cifrata è possibile intercettare i dati che passano: devo sperare che tra quei 19 non ci sia nessuno che sul suo PC abbia un software per rubare le password di accesso ai siti.

Se invece l’applicazione a cui accedo è cifrata, il flusso di dati che passa dal mio PC al sito transita in maniera illeggibile a terzi.

Un esempio di sito munito di cifratura: un internet banking

certificato ssl

la presenza di quel lucchetto verde sul sito mi informa che l’accesso al sito avviene tramite un protocollo sicuro munito di certificato di sicurezza pubblico; il traffico quindi è cifrato da un capo all’altro del filo.

A meno che qualcuno non si metta in mezzo a quel filo.

The man in the middle

Se un’entità si pone in mezzo a quel filo, il traffico cifrato si può decifrare. Questa modalità è chiamata “Man in the Middle” e consiste nell’iniezione di un certificato privato che ha il compito di decifrare il flusso dei dati allo scopo di leggere i dati stessi. Potrebbe essere un’azione benigna, come il sistema  aziendale di analisi del traffico internet, ma è immotivata se avviene in un albergo, bar, o altro posto pubblico.

Quando si vede un messaggio come questo:

certificato privato

il 90% degli utenti in questo caso accetta il certificato privato ed accetta quindi che il suo traffico possa essere letto da terzi e che le proprie credenziali di accesso ai propri siti possano essere trasferite a terzi.

Questa azione avviene pertanto col consenso dell’utente. Quest’ultimo magari è al mare, ha una email urgente da leggere e non vede l’ora di accettare qualsiasi cosa pur di procedere verso la risoluzione del suo problema specifico.

Come difendersi

In qualsiasi momento posso verificare se il certificato è pubblico o privato cliccando sul lucchetto stesso:

certificato pubblico

In questo caso il certificato è pubblico, nessuno ci ha infilato nulla in mezzo.

Ora tocca all’azienda

Furto di Dati con le Web ApplicationIl secondo punto focale: l’azienda, cioè le web application che l’azienda mette a disposizione dei suoi utenti, come sono fatte, come sono protette dagli attacchi.

Se abbiamo visto che i certificati pubblici ricoprono un ruolo fondamentale per cifrare il traffico dati, da e verso il sito, come mai allora rappresentano una falla terribile?

Le tecniche di decifratura a scopo di furto informatico evolvono di continuo, quindi evolve la qualità dei certificati. I certificati vecchi sono crackabili e vanno aggiornati: se ci si dimentica di aggiornarli la falla che creano è ancor più grande di un sito non protetto perché trasmettono una falsa sicurezza agli ignari utenti delle web application.

Al 30 settembre 2015 era stimato in 15 milioni di dollari il danno che globalmente ammonta (vedasi) il non aver aggiornato i certificati dei propri siti aziendali.

Lo stato dell’arte

Lo stato della tecnologia odierna prevede che il certificato di sicurezza di un sito ottemperi al livello di sicurezza SHA-2.

Si può in qualsiasi momento verificare che la propria web application abbia un certificato allo stato dell’arte usando dei semplici tool; quello che mi piace di più è questo sito: https://shaaaaaaaaaaaaa.com/

Per usarlo basta compilare l’unico campo presente immettendo la nostra web app, per esempio:

mail.aziendasrl.net

se il certificato è obsoleto, il sito restituirà questo risultato:

ssh-error

A riprova che è facile dimenticarsi di aggiornare i certificati offrendo su un piatto d’argento la porta principale ad ignoti aggressori. Quello che segue è il risultato che ho avuto testando il server postale di una importante azienda italiana, leader del suo mercato:

Certificato debole

Il certificato è obsoleto e scaduto, per cui, bucabile.

Andare oltre la superficie

Il certificato tutela il traffico dei dati, ma per essere sicuri di non regalare le nostre informazioni a chicchessia, quello che conta è come è fatta la web app.

Una web application è alla fine dei conti un programma software. Ogni software può avere buchi, ma se il software è esposto al mondo intero stiamo certi che questi errori saranno trovati. Parliamo di code injection, SQL injection, Denial of Service, eccetera.

Come fa a tutelarsi un’azienda di fronte a programmi realizzati sia in casa propria che a cura di società esterne?

Si dice giustamente che il miglior modo di collaudare un impianto industriale è farlo testare non da parte di chi lo ha prodotto.

Alla stessa maniera esistono aziende che effettuano verifiche periodiche dei siti in maniera esaustiva, analizzando le migliaia di possibili “bachi” che costantemente vengono a galla e che potrebbero compremettere il nostro sito.

Queste analisi non dovrebbero essere svolte da soggetti improvvisati, ma da realtà come Qualys o Mandiant che sono in grado di restituire al termine di ogni test le vulnerabilità trovate e le azioni correttive da mettere in atto.

Il piano di test deve essere periodico perché ciò che oggi è sicuro domani potrebbe non esserlo più anche solo perché un programmatore che ha fatto una “modifica al volo” può aver creato involontariamente una falla nel sistema.

In Serverlab consigliamo di creare un piano di test periodico con un prodotto standard come sopra per mettersi al riparo da sviste fatali:

Screen Shot 2016-01-31 at 17.11.43

Riassumendo

Non basta quindi che la web application funzioni a dovere. Risulta fondamentale guardare all’intero contesto in cui la web application viene usata. Se vi serve una mano o volete valutare la sicurezza delle vostre web app, sapete come contattarci. Azienda avvisata… 😉

Sei interessato a quest'argomento?
Compila il modulo e ti ricontatteremo al più presto

Serverlab