L’avvento di tecnologie sempre più avanzate ha esteso la possibile complessità di un sito web ad un livello senza precedenti; teniamo inoltre conto di quanto digitalizzato sia ormai il nostro mondo da 20 anni a questa parte, in cui il web è diventato di uso quotidiano anche per processi burocratici e amministrativi in cui vengono maneggiati dati sensibili.

In quest’ottica, la sicurezza delle applicazioni web è diventato un pilastro fondamentale per la protezione di dati aziendali o personali per non incappare in accessi non autorizzati, furti d’identità o altre minacce informatiche.

Impatto degli attacchi informatici: dalle aziende agli individui

Come abbiamo detto, una violazione informatica può avvenire sia per grandi aziende che per i singoli; di seguito, esaminiamo due esempi emblematici che illustrano le conseguenze di tali attacchi su diverse scale.

N.B: Esiste un terzo gruppo soggetto (e oggetto) di attacchi informatici, ovvero gli enti governativi, ma in questo articolo analizzeremo solo gli altri due.

Azienda: questo tipo di violazione può variare per metodo, scopo e impatto ma generalmente sono individuabili alcune caratteristiche chiave che ne definiscono la natura e le conseguenze;

I punti comuni sono:

Vettori di attacco: gli aggressori, per infiltrarsi nel sistema utilizzano metodi come phishing, malware, ransomware oppure operazioni di exploit del sistema.
Obiettivi: differiscono in base al contesto del settore ma sono spesso mirati a rubare dati sensibili come informazioni finanziarie, dati dei clienti o segreti commerciali. Possono anche mirare a danneggiare l’infrastruttura IT dell’azienda per sabotare temporaneamente le operazioni ed estorcere denaro.
Impatto aziendale: gli impatti di un cyberattacco possono essere devastanti e includere la perdita di dati critici, interruzione delle attività, perdite finanziarie dirette (come nel caso di frodi o riscatti pagati) e indirette (come danni alla reputazione e perdita di clienti).

Per citare un esempio, un episodio che fece scalpore e che vide protagonista il sito web dell’INPS, fu quello che ha come sfondo un’Italia messa in ginocchio dal COVID-19 in cui tra i soggetti maggiormente colpiti si individuano gli intestatari di p. Iva.

Questi ultimi, beneficiari di un bonus che avrebbe dovuto essere erogabile in seguito alla presentazione di una domanda, si sono invece ritrovati il sito in down, oppure, nel peggiore dei casi, autorizzati a visualizzare dati privatissimi di altri utenti.

L’allora presidente dell’istituto, Pasquale Tridico, affermò che fu causato da un attacco hacker e gli investigatori confermarono queste dichiarazioni spiegando che si trattasse di campagne ddos, ovvero un ingolfamento del sistema reso non più operativo attraverso richieste massive al server (circa 300 domande presentate al secondo).

La conseguenza, come accennato, fu stato uno spettacolo utopico: persone che si sono ritrovate lanciate all’interno del portale con il profilo di altri utenti, in barba alle norme più elementari sulla tutela della privacy, fino a costringere l’istituto a mandare il sito offline.

Come è facilmente intuibile, tutto ciò causò il ritardo all’accesso al bonus oltre che un gravissimo danno d’immagine all’INPS ma non solo, rivelò evidenti fragilità nei sistemi dei portali web dell’amministrazione pubblica.

Individuo: Gli attacchi informatici diretti contro singoli individui avvengono spesso con il fine di rubare informazioni personali, causare danni finanziari o esercitare controllo e manipolazione.

I punti comuni sono:

Vettori di attacco: phishing, smishing (via SMS), malware distribuito tramite email o siti web con basso livello di sicurezza, attacchi di social engineering che sfruttano la fiducia dell’individuo;
Obiettivi: ottenere credenziali di accesso, numeri di carte di credito ecc. Alcune volte, lo scopo può essere semplicemente quello di bloccare il dispositivo o l’accesso in cambio di qualcosa;
Impatto: possono variare da semplici inconvenienti come la necessità di cambiare password, a problemi più gravi come furto d’identità o perdite finanziarie; inoltre, l’utente potrebbe trovare difficoltà nel riscontro con le autorità competenti a causa della complessità nel rintracciare gli aggressori, finendo per ritrovarsi direttamente responsabile di quanto accaduto: questo può influenzare negativamente la percezione di sicurezza e fiducia nelle interazioni online.

In merito alle nuove sfide che l’evoluzione tecnologica pone ad ognuno di noi, Poste Italiane ha dedicato una sezione denominata Educazione Digitale, con l’obiettivo di istruire i propri utenti sulle regole della sicurezza online, in maniera semplice, accessibile e gratuita.

Di seguito, questo il link per un video che mostra una situazione ipotetica di un utente che si appresta ad aprire un collegamento di un sito web attraverso una email sospetta, e le cause che quest’azione imprudente ha portato.

I nuovi guardiani del web

Consequenzialmente all'aumento della criminalità informatica, c’è stato un incremento esponenziale nella domanda di figure specializzate in sistemi di sicurezza, nelle dinamiche tecniche relative agli attacchi virtuali: i cosiddetti Cyber Security Specialist.

Secondo l’Agenzia per la Cybersicurezza nazionale, si stima che solo in Italia ci siano 100 mila posti vacanti destinati a questo ruolo e simili (fonte qui).

Esistono infatti diverse tipologie di professionisti ognuno il quale si occupa di un preciso campo della Sicurezza ICT, di seguito alcune di queste figure sono:

Cyber Security Analyst: Monitora e analizza l'infrastruttura IT per rilevare possibili vulnerabilità o attacchi. Utilizza strumenti di analisi e monitoraggio per prevenire, identificare e mitigare gli incidenti di sicurezza.
Cyber Security Architect: Questo professionista progetta le architetture di sicurezza, integrando soluzioni di protezione adeguatamente robuste e scalabili e lavorando a stretto contatto con i team di sviluppo per garantire che le nuove tecnologie e applicazioni siano sicure da eventuali minacce.
Penetration Tester: O "pen tester", simula attacchi informatici contro i sistemi dell'azienda per identificare e correggere le vulnerabilità prima che possano essere sfruttate da malintenzionati.
Incident Response Manager: Gestisce la risposta dell'organizzazione agli incidenti di sicurezza. Questa figura coordina le attività di risposta agli incidenti, dalla valutazione del danno alla comunicazione con le parti interessate e la mitigazione delle minacce.

Difendere il Front-end: il ruolo dei professionisti negli attacchi informatici client-side

L’expertise di questi figure diventa ancora più critica quando si affrontano attacchi specifici mirati all’ambito client-side delle applicazioni web.

Vediamo in dettaglio da quali tipi di attacchi bisogna difendersi e le misure di sicurezza da adottare per risolverli o prevenirli:

XSS (Cross-Site Scripting): Il Cross-site scripting è una vulnerabilità nella sicurezza web definita injection attack, ossia l’intruso mira a far eseguire alla macchina uno script che contiene del codice malevolo. In quest’ottica, la pagina web diventa un “veicolo” che trasporta questo script al browser dell’utente; esempi di questi veicoli possono essere forum o siti che permettono di commentare e sono maggiormente attaccabili se utilizzano input non sanificati, ovvero non validati e puliti da eventuale codice dannoso.

A sua volta esistono 3 tipi di attacchi XSS:

Riflesso: è la variante più semplice, sorge quando un’applicazione riceve dati da una richiesta HTTP e include quei dati nella risposta immediata in modo non sicuro.

Un esempio di vulnerabilità:

https://sito-non-sicuro.com/status?message=Va+tutto+bene.

Stato: Va tutto bene.

L'applicazione non esegue alcun tipo di elaborazione dei dati, quindi l’aggressore può facilmente costruire un attacco come questo:

https://sito-non-sicuro.com/status?message=

Se l'utente visita l'URL costruito, allora lo script si esegue nel browser dell'utente nel contesto della sessione. A quel punto, può compiere qualsiasi azione e recuperare qualsiasi dato a cui l'utente ha accesso.

Memorizzato: si verifica quando l’applicazione riceve dati da una fonte non attendibile e li include nelle sue risposte HTTP successive.

Un semplice esempio di questa vulnerabilità può avvenire in applicazioni in cui è presente una bacheca in cui gli utenti possono mandare messaggi:

<p>Ciao, questo è il mio messaggio!</p>

Anche qui, l’applicazione non esegue l’elaborazione dei dati, quindi un utente malintenzionato può facilmente inviare un messaggio che attacca altri utenti:

<p><script>/* Codice dannoso qui... */</script></p>

DOM-based: si verifica quando un’applicazione contiene del JavaScript lato client che elabora dati da una fonte non attendibile in modo non sicuro, di solito scrivendo i dati di nuovo nel DOM. Di seguito, un'applicazione che utilizza JavaScript per leggere il valore da un campo di input e scrive quel valore in un elemento all'interno dell'HTML:

var search = document.getElementById('search').value;

var results = document.getElementById('results');

results.innerHTML = 'Hai cercato: ' + search;

Se l’intruso riesce a controllare il valore del campo di input, può facilmente costruire un valore maligno che fa eseguire il proprio script:

Hai cercato: <img onerror="/* Codice dannoso qui... */" />

In un caso tipico, il campo di input sarebbe popolato da parte della richiesta HTTP, come un parametro della stringa di query URL, consentendo all'attaccante di eseguire un attacco utilizzando un URL maligno, allo stesso modo del XSS riflesso.

In sintesi, il test manuale per XSS riflessivi e memorizzati coinvolge l'inserimento di input semplici e univoci in ogni punto di ingresso dell'applicazione, l'identificazione di ogni luogo in cui l'input inviato viene restituito nelle risposte HTTP e il test di ciascun luogo individualmente per determinare se un input opportunamente creato può essere utilizzato per eseguire JavaScript arbitrario.

Per quanto riguarda il DOM-based XSS, il test manuale coinvolge un processo simile, ma con un'attenzione particolare all'utilizzo degli strumenti dello sviluppatore del browser per esaminare il DOM alla ricerca di eventuali punti di iniezione.

Tuttavia, per rilevare le vulnerabilità DOM-based che coinvolgono input non basati su URL (come document.cookie) o destinazioni non basate su HTML (come setTimeout), è necessario esaminare manualmente il codice JavaScript, il che può richiedere molto tempo.

CSRF (Cross-Site Request Forgery) Si tratta di un attacco il cui scopo è ingannare un utente autenticato portandolo a eseguire azioni non volute inviando richieste dannose senza che lo sappia esplicitamente.

In un attacco CSRF client-side, l’aggressore crea una pagina web o un’email (una forma di phishing) contenente un link o un form che esegue un’azione su un altro sito web in cui, l’hacker spera, la vittima sia autenticata.

Quando la vittima vi accede, il browser invia automaticamente richieste HTTP al sito target.

Un esempio di una possibile situazione potrebbe essere il seguente:

Un utente autenticato su un sito web di banca online naviga su un forum pubblico e apre un post maligno che contiene un link invisibile a una richiesta di trasferimento di denaro sul sito della banca.
Il link invisibile è programmato per inviare una richiesta di trasferimento di denaro dal conto dell'utente autenticato sul forum al conto del malintenzionato.
Quando l'utente visualizza il post “maligno”, il browser invia automaticamente la richiesta di trasferimento di denaro al sito della banca, utilizzando le credenziali autentiche dell'utente senza che questo sia consapevole dell'azione.

Per prevenire gli attacchi CSRF client-side, le applicazioni web devono implementare misure di protezione come i token CSRF, ossia dei lunghi codici randomici di sicurezza, unici per sessione utente.

Quello che succede in un’applicazione protetta da attacchi CSRF è che, ad esempio al login, lato server, sta creando il token e lo sta inviando alla sessione dell’utente.

/* semplificato lato server */

const sessionId = crypto.randomUUID()
const csrfToken = crypto.randomUUID()
SESSION.set(sessionId, {user, csrfToken })
  res
     .cookie("sessionId", sessionId, {
         secure: true,
         httpOnly: true,
         sameSite: "none"
       })
       .json({ csrfToken, message: `Auth as ${req.body.username}`
  })

salvandolo lato client (in questo modo, non sarà in nessun modo accessibile); inoltre, lo si include nel body per ogni richiesta.

/* semplificato lato client */
let csrfToken;
function login(username) {
  fetch("http://localhost:3000/login", {
    method: "POST",
    credentials: "include",
    headers: { 
      "Content-Type": "application/json" 
    },
    body: JSON.stringify({ username })
    })
    .then(res => res.json())
    .then(data => { 
      csrfToken = data.csrfToken;
      responsesDiv.textContent = data.message;
    })}

A questo punto, se avviene una richiesta, questa controllerà non più solo la sessione, ma anche se i token CSRF combaciano, e solo in quel caso la richiesta andrà a buon fine.

app.post("/delete-user", (req, res) => {
    const session = SESSION.get(req.cookies.sessionId)
    if (
        session == null ||
        session.user == null ||
        session.csrfToken !== req.body.csrfToken
    ) {
        res.sendStatus(401)
        return
    }
    USERS.delete(session.user.username)
    SESSIONS.delete(req.cookies.sessionId)
    res.send(`Deleted ${session.user.username}`)
})

La difesa contro questi attacchi è fondamentale per la sicurezza delle applicazioni web, ma c’è da sottolineare che i browser moderni si sono migliorati sempre di più e hanno adottato politiche stringenti per mitigarli. Una di queste è la "SameSite" cookie attribute, che può essere impostata su "None”, "Strict" o "Lax". Quest’ultima, particolarmente efficace contro gli attacchi CSRF, limita gli invii cross-site:

Quando un cookie ha l'attributo SameSite=Lax, il browser permette l'invio del cookie in richieste di tipo GET effettuate tramite navigazione top-level (ad esempio, cliccando su un link). Tuttavia, il cookie non verrà inviato in richieste cross-origin che utilizzano metodi HTTP non sicuri come POST, che sono comuni in attacchi CSRF.

N.B: Eccezioni per navigazione top-level: questa funzione consente l'invio del cookie quando un utente arriva a un sito attraverso un link da un altro sito, il che è una pratica comune durante la navigazione web.

Questo rende la politica meno restrittiva rispetto a "SameSite=Strict", che non consente il passaggio di cookie in nessun contesto cross-site, migliorando l'usabilità senza sacrificare significativamente la sicurezza.

Conclusioni

Alla luce di quanto detto, dunque, considerando che gli attacchi informatici sono sempre più in aumento (in Italia si è visto un aumento del 169% nel 2022) e che la prospettiva del concetto di IoT è sempre più presente nella vita di tutti i giorni, sarebbe da sprovveduti affermare che la situazione non sia preoccupante.

In questo contesto, è fondamentale che ogni organizzazione adotti un approccio proattivo alla sicurezza informatica, educando i propri utenti e impiegati sulle migliori pratiche e gli strumenti disponibili.

Solo attraverso un impegno collettivo e un'attenzione costante possiamo sperare di stare al passo con le minacce in continua evoluzione e proteggere il nostro mondo sempre più digitalizzato.

Sicurezza Informatica nell’attuale realtà digitalizzata

Security risk assessment

Filtra per categorie