Features

Mithril distribuisce la cache tra tutti i suoi nodi e dà agli utenti il controllo su cosa mettere o meno nella loro cache. Grazie alla sua Cache API, ogni utente può eliminare completamente tutta la cache o semplicemente cancellare un singolo contenuto.

Cos’è Mithril Proxy Caching e come funziona?

Una funzionalità utile di Mithril Proxy Cache è che tutti i contenuti in cache non scadono mai veramente. Se il tuo sito web diventa irraggiungibile o inizia a restituire errori, Mithril può prendere i contenuti vecchi dalla sua cache. Lo invia agli utenti del tuo sito web, evitando errori come 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, o 504 Gateway Timeout. Se il proxy caching non è abbastanza, Mithril può iniettare un semplice Service Worker per convertire il tuo sito o applicazione web in un’applicazione web offline.

Cos’è il Service Worker di Mithril e come funziona?

Service Worker è uno script che il browser dell’utente esegue in background, e può gestire e intercettare le richieste di rete e salvarle nella cache del browser dell’utente. Questo significa che qualsiasi contenuto proveniente dal tuo sito web e qualsiasi contenuto di terze parti, come Google Fonts o CDN, sarà memorizzato nella cache del browser dell’utente rendendo il tuo sito web “raggiungibile” offline.

I servizi DDoS a noleggio, noti anche come booters o stressers, offrono agli attori maligni un modo semplice per attaccare anonimamente qualsiasi obiettivo connesso a Internet. Utilizzando tali servizi, chiunque può inviare milioni di richieste HTTP contro qualsiasi sito web di destinazione, al fine di esaurire le risorse del server web, rendendolo non reattivo o irraggiungibile.

Come funziona un attacco DDoS?

I booters o stressers di solito usano i propri server e le proprie infrastrutture per eseguire gli attacchi, nascondendo i loro indirizzi IP pubblici dietro open proxy o abusando delle funzionalità pubbliche delle applicazioni web (come il pingback XMLRPC di WordPress, leggi qui). Ciò che tutti i booters hanno in comune, è che per generare il maggior numero di connessioni contro un obiettivo, utilizzano semplici HTTP clients che non sono in grado di eseguire contenuti JavaScript.

Come fa Mithril a proteggere il tuo server web e la tua applicazione dagli attacchi DDoS?

Grazie a questo, Mithril può generare una semplice sfida JavaScript sui suoi bilanciatori di carico pubblici che bloccano l’attacco DoS prima di raggiungere il server del cliente e scalano automaticamente per gestire tutte le connessioni in entrata. Secondo questa tecnica, Mithril può gestire centinaia di milioni di richieste HTTP simultanee, salvando il tuo server web e la tua applicazione web da questo tipo di esplosione di traffico senza alcun tempo di inattività.

I Bad Bot si sono evoluti durante l’ultimo decennio attraverso quattro diverse generazioni.Impariamo di più su di loro, per capire come funziona Bad Bot Protection.

1. La prima generazione è rappresentata da semplici script che (usando user-agent testuali come curl) non sono in grado di gestire sessioni autenticate o eseguire codice JavaScript. La prima generazione è molto facile da intercettare e bloccare solitamente solo filtrando ciò che è presente all’interno del request header “User-Agent”.
2. La seconda generazione include script un po’ più sofisticati che possono gestire sessioni autenticate ma non sono in grado di interpretare codice JavaScript. La seconda generazione solitamente impersonifica browser reali (come Chrome o Firefox) inviando uno User-Agent string plausibile all’interno del request header User-Agent.
3. La terza generazione è composta da reali browser controllati da WebDriver che è un “remote control interface” che permette di controllare remotamente browser tramite script. In poche parole, WebDriver permette di automatizzare richieste HTTP usando un reale browser che può gestire sessioni autenticate e può interpretare codice JavaScript. La terza generazione è più complicata da intercettare e bloccare perchè tutte le request HTTP sembrano provenire da reali browser e a prima vista sembrano indistinguibili da un utente umano.
4. La quarta generazione è composta da browser reali che possono simulare comportamenti umani come movimento del mouse, uso della tastiera, scroll della pagina, ecc…

Mithril tre tipi di JavaScript Challenges che riescono a intercettare e bloccare tutte le generazioni di Bad Bot appena descritte.

Cos’è una JavaScript challenge?

In poche parole, una JavaScript Challenge è una landing page che obbliga il browser dell’utente a interpretare codice JavaScript per ottenere un token di sessione. Questo token permette all’utente di visitare il sito web protetto per un periodo di tempo configurabile. Questo solitamente permette di separare semplici bot da utenti umani, ma non è abbastanza per le generazioni 3 e 4.

Come fa Mithril JavaScript Challenge a sconfiggere tutte e quattro le cattive generazioni di bot?

La JavaScript Challenge di Mithril è capace di identificare browser controllati da WebDriver e può essere eseguita in background durante la navigazione dell’utente per rilevare un comportamento sospetto e identificare bot più sofisticati.

Una delle attività più complicate da svolgere durante la fase di learning è quella di identificare tutti i parametri all’interno della querystring o nel request body che hanno una formattazione ben definita come valori numerici, solo alfabetici,  alfanumerici, ecc… tra tutti i “content types” come form urlencoded, JSON, XML, multipart form data, e molti altri.

Come funziona Mithril Learning Phase e Response Filtering?

Mithril ha un modulo di learning del traffico che analizza automaticamente le request HTTP del cliente e crea regole Web Application Firewall custom per limitare e sanitizzare lo user input. A volte ciò non è abbastanza per applicare una virtual patch su una web application.

Il nostro team può applicare virtual patches per risolvere le problematiche descritte all’interno di un report Penetration Test e di creare WAF Rules personalizzate o interi moduli dedicati per sanitizzare l’input utente anche intervenendo on-fly su ogni “response body” per censurare informazioni ed errori di debug.

Un esempio

Per esempio, se la tua web application accetta il parametro “newsid” e il suo contenuto è solo numerico e fa riferimento all’id numerico di una notizia sul database, il nostro modulo di learning produrrà automaticamente una regola WAF che avrà “ARGS:newsid” come variabile e controllando il suo contenuto con una regular expression tipo “^[0-9]+$”. Se il valore inviato non è solo numerico, Mithril bloccherà la richiesta HTTP rimuovendo così eventuali injection (come ad esempio SQL Injection).