analisi e gestione della sicurezza di una complessa applicazione ...

6.10 Denial of Service
CAPITOLO VI - Gli attacchi e il progetto OWASP
Come tutti i servizi di rete, anche le applicazioni web, soffrono degli attacchi di tipo DoS
(Denial of Service) in cui, attraverso l’esaurimento delle risorse del sistema, si satura la sua
capacità fino a determinarne il blocco temporaneo. In questa situazione i sistemi diventano
inutilizzabili per gli utenti legittimamente attivi.
Una grossa quantità di richieste HTTP è un primo e semplice esempio di come poter saturare le
risorse di un server web, bloccando l’accesso per tutti gli altri utenti. Pratiche di questo tipo
sono sempre più frequenti durante i net strike e, purtroppo, come meccanismo d’estorsione
verso siti che traggono profitto dalla pubblicità sul numero di visitatori.
Sebbene particolari configurazioni possono mitigare il problema, questa problematica è
comunque impossibile da risolvere. Si può attenuare un attacco tramite potenziamenti
dell’hardware, attraverso l’uso di load balancing e instaurando accordi con i fornitori del
servizio internet ma non è possibile escludere il problema: l’aggressore potrebbe potenziarsi a
sua volta oppure attaccare risorse diverse (ampiezza di banda, numero di connessioni al
database, spazio su disco, utilizzo della CPU e della memoria e così via).
Come regola generale conviene limitare, a livello software, il massimo numero di risorse
allocate per un singolo utente.
Per gli utenti autenticati, è possibile fissare una quota in modo da poter limitare il carico
massimo che un utente può applicare al sistema. In particolare, dovrebbe essere considerata la
possibilità di gestire una richiesta ad utente per volta, sincronizzandosi con le sessioni degli
utenti. E’ utile bloccare ogni HTTP request che viene processata da un utente nel momento in
cui la richiesta di un altro utente arriva al sistema.
Per gli utenti non autenticati, bisogna evitare tutti gli accessi al DB o ad altre applicazioni avide
di risorse ritenute superflue. E’ consigliabile progettare l’architettura dei flussi del sito, in modo
tale che un utente non autenticato non possa richiamare nessuna di queste funzioni onerose dal
punto di vista dell’effort sulle risorse dell’applicazione. Si potrebbe pensare di mantenere in
una cache il contenuto dei dati ricevuti da utenti non autenticati invece di eseguire delle query
direttamente sul DB. Inoltre sarebbe necessario controllare le modalità con cui vengono gestiti
gli errori, in modo tale da non inficiare le altre funzioni dell’applicazione.
147