Superficie di attacco

Per superficie di attacco di un sistema informatico si intende la somma dei punti (anche chiamati "vettori di attacco") da cui un soggetto non autorizzato può interagire con il sistema. Ad esempio tutti i punti dove esiste l'input da utente, tutti i servizi esposti di un server oppure tutti i dispositivi accessibili fisicamente. Avere un buona comprensione della propria superficie di attacco presenta vari vantaggi:

• permette di capire quali funzioni o quali parti del sistema hanno bisogno di revisioni o test per le proprietà di sicurezza,
• permette di identificare aree di codice ad alto rischio che richiedono una attenzione particolare durante lo sviluppo,
• permette la semplificazione delle operazioni di audit, in quanto possiamo concentrarci sui punti di ingresso di un eventuale attaccante.

Ad esempio, per una applicazione web la superficie di attacco potrebbe essere composta da:

• tutti gli endpoint, con particolare attenzione per quelli di login/autenticazione
• header HTTP e cookie
• local storage
• eventuali API esposte
• file provenienti da sorgenti non fidati (ad esempio da un upload di un utente).

Spesso però esistono altri punti di ingresso meno ovvi, come

• altri servizi esposti pubblicamente (ad esempio il database oppure servizi di caching)
• interfacce o pannelli da amministratore,
• deployment di test.

Una regola generale è che la "security through obscurity" non è un buon metodo di approccio per gestire la sicurezza. In altre parole

Gestione della superficie di attacco

Come regola generale, tenere la superficie di attacco controllata e piccola è una buona pratica di sicurezza. Questo aiuta a controllare la complessità dell'applicazione e a semplificare le analisi di sicurezza. Per esempio potrebbe avere senso semplificare le interfacce o API delle funzionalità già esistenti, oppure disabilitare completamente delle funzionalità poco usate.

Quando si fa una modifica al sistema, per esempio viene aggiunto un endpoint, viene modificata la semantica di una funzionalità o altro, bisogna farsi alcune domande:

• Cosa è cambiato nell'applicazione?
• Quale componente è stato modificato e quanto questo componente è critico?
• Quali punti di ingresso può aver introdotto questa modifica?

Ad esempio, se abbiamo una applicazione web e aggiungiamo una pagina di documentazione statica, la superficie di attacco è sicuramente aumentata, ma non in modo significativo. In altre parole è probabile che prima e dopo la modifica, le possibilità di un attaccante sono fondamentalmente le stesse. Invece se aggiungiamo per la prima volta una funzionalità che richiede l'upload di un file da parte dell'utente, questo introduce un nuovo punto di ingresso, che deve essere attentamente valutato. Allo stesso modo modifiche alla gestione dell'autenticazione oppure alla gestione delle sessioni devono essere attentamente revisionate perché stanno impattando componenti critiche dell'applicazione.

Tenere la superficie di attacco piccola tende a ridurre gli errori di sicurezza, non è una vera e propria tecnica di mitigazione. Infatti non previene in nessun modo i danni che un attaccante può fare se una vulnerabilità viene scoperta.