Attacchi a livello di applicazione - Best practice AWS per la resilienza DDoS

Attacchi a livello di applicazione

Un utente malintenzionato può colpire l'applicazione stessa utilizzando un attacco a livello 7 o a livello di applicazione. In questi attacchi, simili agli attacchi all'infrastruttura SYN Flood, l'utente malintenzionato tenta di sovraccaricare funzioni specifiche di un'applicazione per renderla non disponibile o non responsiva per gli utenti legittimi. Talvolta questo risultato può essere ottenuto con volumi di richieste molto bassi che generano solo un piccolo volume di traffico di rete, rendendo l'attacco difficile da rilevare e mitigare. Gli esempi di attacchi a livello di applicazione includono i flood HTTP, gli attacchi di cache-busting e i flood XML-RPC di WordPress.

In un attacco flood HTTP, un utente malintenzionato invia richieste HTTP che sembrano provenire da un utente valido dell'applicazione Web. Alcuni flood HTTP hanno come target una risorsa specifica, mentre i flood HTTP più complessi tentano di emulare l'interazione umana con l'applicazione, aumentando in questo modo la difficoltà di utilizzare tecniche di mitigazione comuni come la limitazione del tasso di richiesta.

Gli attacchi di cache-busting sono un tipo di flusso HTTP che utilizza variazioni nella stringa di query per aggirare la memorizzazione nella cache della rete di distribuzione dei contenuti (CDN). Invece di essere in grado di restituire risultati memorizzati nella cache, la CDN deve contattare il server di origine per ogni richiesta di pagina e questi recuperi dell'origine causano un ulteriore sforzo sul server Web dell'applicazione.

Con un attacco flood XML-RPC di WordPress, noto anche come pingback flood di WordPress, un utente malintenzionato prende di mira un sito Web ospitato sul software di gestione dei contenuti WordPress. L'utente malintenzionato utilizza in modo improprio la funzione API XML-RPC per generare un flusso di richieste HTTP. La funzione pingback consente a un sito Web ospitato su WordPress (sito A) di notificare un diverso sito WordPress (sito B) tramite un collegamento che il sito A ha creato al sito B. Il sito B tenta quindi di recuperare il sito A per verificare l'esistenza del collegamento. In un pingback flood, l'utente malintenzionato abusa di questa capacità per fare in modo che il sito B attacchi il sito A. Questo tipo di attacco ha una firma chiara: WordPress è tipicamente presente nell'Utente-agente dell'intestazione della richiesta HTTP.

Esistono altre forme di traffico dannoso che possono influire sulla disponibilità di un'applicazione. I bot di scraping automatizzano i tentativi di accesso a un'applicazione Web per sottrarre contenuti o registrare informazioni sulla concorrenza, come i prezzi. Gli attacchi di forza bruta e di credential stuffing sono degli sforzi programmati per ottenere l'accesso non autorizzato alle aree protette di un'applicazione. Non si tratta esclusivamente di attacchi DDoS, ma la loro natura automatizzata può assomigliare a un attacco DDoS e possono essere mitigati implementando alcune delle stesse best practice che verranno trattate in questo documento.

Gli attacchi a livello di applicazione possono anche colpire i servizi DNS (Domain Name System). Il più comune di questi attacchi è un flusso di query DNS in cui un utente malintenzionato utilizza molte query DNS ben formate per esaurire le risorse di un server DNS. Questi attacchi possono anche includere un componente cache-busting in cui l'utente malintenzionato randomizza la stringa del sottodominio per bypassare la cache DNS locale di un determinato resolver. Di conseguenza, il resolver non può sfruttare le query di dominio memorizzate nella cache e deve invece contattare ripetutamente il server DNS autorevole, amplificando l'attacco.

Se un'applicazione Web viene distribuita tramite Transport Layer Security (TLS), un utente malintenzionato può anche scegliere di attaccare il processo di negoziazione TLS. TLS è costoso dal punto di vista computazionale, quindi un utente malintenzionato, generando un carico di lavoro aggiuntivo sul server per elaborare dati illeggibili (o incomprensibili (testo cifrato)) come un handshake legittimo, può ridurre la disponibilità del server. In una variante di questo attacco, un utente malintenzionato completa l'handshake TLS ma rinegozia continuamente il metodo di crittografia. In alternativa, un utente malintenzionato può tentare di esaurire le risorse del server aprendo e chiudendo molte sessioni TLS.