Un firewall per applicazioni Web protegge solo il livello OSI 7?

A causa delle necessità architettoniche, i Web Application Firewalls (WAF) proteggono anche dagli attacchi degli altri livelli . Tuttavia, queste protezioni sono in gran parte accessorie e non esaustive. Lasciatemi illustrare questo con alcuni esempi:

Presentation Layer - supponiamo che l'applicazione da proteggere utilizzi TLS. In tal caso, il dispositivo WAF deve, per definizione, terminare la connessione TLS del client per decrittografare i dati dell'applicazione e applicare la relativa logica Application Firewall.

Ciò significa in pratica che un potenziale aggressore non interagisce mai con lo stack TLS sull'host di destinazione (applicazione) . E mentre il backend può eseguire uno qualsiasi numero di Application Framework, ognuno dei quali ha la propria implementazione TLS con le sue peculiarità, il WAF sarà generalmente costruito e venduto da qualcuno che ha capito che TLS è un grosso problema per avere ragione. (Nella mia esperienza, F5 è abbastanza buono nell'aggiornare il TLS come necessario).

Quindi il WAF fornisce protezione al Presentation Layer, infatti (se non come un punto vendita).

Session Layer - un WAF inserisce spesso i propri cookie di tracciamento per aiutare a rilevare e impedire alle persone di giocare con i dati dell'endpoint di sessione. Ciò è in parte dovuto al fatto che il WAF deve proteggere [qualsiasi] applicazione sul back-end, ma integra perfettamente il fatto che "per l'applicazione [casuale (qualsiasi)], si presuppone che sia stato scritto senza protezioni di sessione ragionevoli."

Transport Layer - Come TLS, il TCP verrà terminato al WAF, esentando quindi il server delle applicazioni dall'interazione diretta con il client. Eventuali ritocchi sintonizzati a mano su pacchetti, eventuali frammenti sovrapposti, qualsiasi gioco di violazione dello stato si romperanno contro il WAF e non sul server delle applicazioni. Il WAF sarà meglio in grado di gestirli? Difficile da dire, ma l'attaccante sarà ancora al di sotto del loro obiettivo.

Network Layer - di nuovo, terminando le connessioni e aprendone di nuove al server delle applicazioni, il WAF isolerà il server delle applicazioni dagli attacchi del livello IP ... Ad esempio, aspetterà fino a l'Handshake a 3 vie esterno (client) (3WHS) è completo prima di iniziare il 3WHS interno (Server), attenuando così i synfloods.

Queste protezioni sono generalmente accessorie e non progettate. Il produttore WAF non sta mettendo la capacità Stateful Inspection di, ad esempio, un CheckPoint nel loro WAF; stanno solo aspettando di avere una connessione esterna con stato valido prima di aprire la connessione interna. WAF può utilizzare lo stack OpenSSL TLS, proprio come fa il server delle applicazioni, ed entrambi sono vulnerabili agli stessi problemi ... ma il WAF è un passo rimosso dai dati utili sull'applicazione che l'utente malintenzionato vuole raggiungere .

* La definizione che sto usando qui è "moderna TLS preferisce cifrari chiave effimeri che rimuovono la capacità di un listener passivo di decrittografare il traffico, quindi supponiamo che qualsiasi cosa con TLS in questi giorni abbia bisogno di essere interrotta per essere decrittografata ".