Tutti gli attacchi condividono il codice malevolo eseguito dal browser delle vittime per esportare dati sui server dell’aggressore

Sicurezza client side: cos'è e come implementarla
Tempo di lettura: 6 minuti

È possibile navigare sul web avendo la certezza che i propri dati siano davvero al sicuro? Anche se la risposta a questa domanda è tendenzialmente negativa, la norma è quella di fidarsi dei siti a tal punto da inserire le informazioni più sensibili come i dati della carta di credito o i dati personali. Se da un lato i proprietari di questi siti web considerano la sicurezza dei dati degli utenti come una delle loro priorità, dall’altro si continua a sentire parlare di furti di informazioni e data breach. Situazioni come queste sono i motivi per cui, sempre più spesso, le aziende chiedono soluzioni di sicurezza client side per i loro siti Internet.

Ma cosa sono le minacce Client Side? Con questo termine ci riferiamo in particolare al browser web. Gli attacchi client side sono quelli che colpiscono gli utenti che navigano, ma che sono una diretta conseguenza di una catena di attacchi più sofisticati. Attacchi dove l’entry point è il server web, ma i dati degli utenti sono l’unico obiettivo. Esempi recenti come Magecart, che avevano come target i siti web più grandi come quello di British Airways, NewEgg, e Ticketmaster, ma dove l’obiettivo finale sono i dati personali, finanziari e identificativi degli utenti. Questa tipologia di attacchi può essere facilmente mitigata grazie ad una completa comprensione delle loro dinamiche.

Scenario degli attacchi comuni

Ogni singolo attacco Client Side è diverso, ma tutti si basano sul fatto che gli attaccanti vogliono ottenere i dati degli utenti. Così alcuni attaccanti potrebbero fare affidamento sulla compromissione del server e sulla modifica del codice front-end, mentre altri potrebbero infettare terze parti (ad esempio, attaccare la supply chain). Ma quali sono gli scenari più comuni e come combatterli?

  • Server Violati: come primo scenario possiamo considerare un server compromesso, senza pensare alle modalità con cui questo dominio è stato colpito ma cominciando ad analizzarlo dal momento in cui l’attaccante ha raggiunto il server. Una volta che l’applicazione è stata compromessa, l’attaccante può iniettare un codice malevolo, come contenuto di prime parti nella pagina web, sotto forma di script inline (o riferimento ad un’altra risorsa remota/locale):
  • Terze Parti infettate: il secondo scenario ha a che fare con la stessa pagina di prima, ma questa volta il server non è stato compromesso. Il problema qui è che il sito dipende da risorse di terze parti (come jQuery, bootstrap etc). Questo tipo di dipendenza implica una fiducia a senso unico, cioè nei confronti dei contenuti provenienti dalle terze parti.

    In uno scenario dove il server della terza parte è stato violato, un attaccante può modificare il contenuto del presunto codice lecito, con un codice malevolo, esponendo in questo modo la pagina originale a un codice malevolo:

  • Rogue Extension: lo scenario finale illustra invece una situazione dove né il sito, né la terza parte da cui dipende sono stati violati, ma è il browser stesso ad essere infettato. Le estensioni del browser sono un elemento che può essere molto utile. Basti pensare alla gestione delle password degli utenti, le loro informazioni personali, gli adv block, e molto di più. Tuttavia, le estensioni del browser sono a rischio, e ci sono stati casi in cui i repository di estensioni ufficiali contenevano codice malevolo. In questo modo viene attivata una rogue browser extension:

Quello che tutti gli attacchi hanno in comune è il codice malevolo che viene eseguito dal browser delle vittime e che ha l’obiettivo di esportare alcuni dati (informazioni sensibili, come numeri di carte di credito, CVV, etc.) sui server dell’aggressore che beneficerà dell’attacco. Questi attacchi vanno individuati e mitigati. Quali sono le modalità per farlo?

Metodi di rilevazione e di mitigazione

Nel corso del tempo, i browser web sono diventati più efficienti e più “robusti”. Ad esempio, l’esecuzione di task asincroni nel browser era considerata un sogno nei primi tempi di Internet. Ora invece è possibile sfruttare alcune di queste moderne API per proteggere il client da tali minacce.

Osservare le mutazioni del sito web

Un approccio per proteggere i visitatori di un sito potrebbe essere quello di utilizzare la Mutation Observer API. Questa moderna API dà la possibilità di monitorare i cambiamenti che avvengono su una pagina web. Il proprietario del sito web può creare una lista di cambiamenti consentiti così che i comandi esterni a questa lista vengono immediatamente bloccati. I cambiamenti bloccati possono essere aggiunti a uno script tag o a un’immagine (che è una comune tecnica di infiltrazione). L’implementazione di una simile idea si può vedere in un progetto esistente chiamato DOMTEGRITY.

Validazione delle risorse

Un altro strumento è chiamato subresource integrity (SRI). Le sue caratteristiche permettono ai browser di verificare che le risorse che utilizzano (da prime o terze parti) siano eseguite senza modifiche non previste. Funziona fornendo un cryptographic hash alla risorsa che può essere calcolato a priori. In questo modo, quando il cliente visualizza la pagina per la prima volta, e prima di caricare la risorsa recuperata, ne convalida il contenuto confrontando l’hash fornito con quello calcolato.

CSP Policies

Una delle principali web feature che sta prendendo sempre più piede con il passare del tempo è la content security policy (CSP). Con l’utilizzo della CSP, il proprietario di un sito web può definire una content security policy per permettere o vietare alcune risorse da recuperare da origini diverse.

CSP lavora definendo una lista di tipologia di fonti, come immagini, connessioni, frame (che vengono anche definiti directives) oltre a origini da cui il sito può caricare una risorsa. Con tutte queste direttive ben definite, è possibile avere maggiore controllo. Un altro utilizzo funzionale della CSP è quello di poter bloccare le richieste di esportazione fatte durante un attacco al browser.

Nel recente attacco Magecart contro Forbes magazine, gli attaccanti hanno usato un approccio unico per esfiltrare i dati. Invece dei metodi comuni, hanno utilizzato un Web Sockets. Se ci fosse stata, una Content Security Policy avrebbe bloccato la connessione grazie ad una regola impostata.

Domain Name Inspection

Una volta che i dati vengono rubati dai browser degli utenti, gli attaccanti devono decidere dove inviarli. Possono decidere sia di mandarli a un indirizzo IP, che sembrerebbe estremamente sospetto, o di utilizzare un dominio. Ci sono dei metodi per decidere se il nome di un dominio risulti sospetto. Prima di tutto ci si può affidare alla blacklist, che include i principali domini coinvolti in attività malevole. In secondo luogo, è necessario controllare i domini che assomigliano al nome di dominio del sito web stesso. Un buon esempio è quello dell’attacco a NewEgg, dove l’esfiltrazione avveniva su “neweggstats[.]com”.

Conclusioni

Le minacce Client Side sono in crescita e viene registrato un ampio numero di siti o di loro dipendenze compromesse. Mentre queste minacce solitamente mirano ai visitatori di un sito, indirettamente anche i proprietari di quel sito vengono colpiti dall’attacco.

Anche se il sito stesso non è stato violato, l’impatto sugli utenti c’è in ogni caso e questo tipo di situazioni può portare ad un danno finanziario e reputazionale per il proprietario del sito che deve quindi essere preparato a proteggersi.

A cura di Daniel Abeles, Senior Security Researcher di Akamai Technologies