Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Che cos'è l'iniezione dell’header HTTP?

18/11/21 CoreTech Blog

La vulnerabilità di iniezione dell’header HTTP è un termine di sicurezza dell'applicazione Web che si riferisce a una situazione in cui l'autore dell'attacco inganna l'applicazione Web per inserire intestazioni HTTP aggiuntive in risposte HTTP legittime. L'iniezione di intestazione HTTP è una tecnica che può essere utilizzata per facilitare attacchi dannosi come scripting tra siti, avvelenamento della cache Web e altro ancora. Questi, a loro volta, possono portare alla divulgazione di informazioni, all'utilizzo dell'applicazione in attacchi di phishing e ad altre gravi conseguenze.

L'iniezione dell’header HTTP è un caso specifico di una categoria di attacchi più generica: le iniezioni CRLF. Se l'attaccante è in grado di inserire una sequenza CRLF (carriage return e line feed) nella risposta, è in grado di aggiungere varie voci false o modificare i dati esistenti: non solo le intestazioni ma anche l'intero corpo della risposta.

Quali sono le cause delle vulnerabilità di iniezione dell’header HTTP?

Proprio come la maggior parte delle vulnerabilità di sicurezza delle applicazioni Web, le vulnerabilità di iniezione dell'intestazione HTTP (e le vulnerabilità di iniezione CRLF in generale) sono il risultato dell'eccessiva fiducia nell'input dell'utente. Se lo sviluppatore di un'applicazione Web utilizza dati esterni direttamente nelle risposte HTTP, di solito è possibile eseguire un attacco di header injection HTTP.

Ad esempio, immagina che la tua azienda si sia trasferita in un nuovo dominio e, per comodità, desideri che i segnalibri degli utenti continuino a funzionare. Il dominio originale era example.com ma ora il tuo sito è disponibile su example.info. Se il tuo utente normale visita un URL obsoleto come http://www.example.com/page1, desideri che il server web reindirizzi automaticamente l'utente al rispettivo nuovo URL: http://www.example.info/page1 .

Per raggiungere l'obiettivo di cui sopra, puoi creare una semplice applicazione web su example.com che prenda il percorso dalla richiesta HTTP e lo accoda a http://www.example.info/. Se lo sviluppatore di tale applicazione non elimina i caratteri speciali CR e LF dai dati di input prima di aggiungerli al nuovo URL di base, un utente malintenzionato può utilizzare questa applicazione per eseguire attacchi di intestazione HTTP.

Anatomia di un attacco HTTP header injection

Gli attacchi di header injection HTTP sono per molti versi simili agli attacchi di scripting cross-site (XSS). Pertanto, ci sono attacchi di iniezione di intestazione HTTP riflessi e (meno comuni) attacchi di iniezione di intestazione HTTP memorizzati.

Banner

Iniezione di intestazione HTTP riflessa

Immagina di essere il proprietario del dominio example.com e che un utente malintenzionato voglia sfruttare la vulnerabilità di iniezione dell'intestazione HTTP descritta sopra. Preparano una campagna di phishing e inviano il seguente URL:

http://example.com/page1%0d%0aLocation:vulnweb.com

Come risultato dell'inserimento dell'intestazione HTTP, i caratteri CRLF vengono inseriti nella risposta e seguiti da una nuova intestazione Location:. Il browser web (a seconda del tipo e della configurazione del browser) reindirizzerà l'utente al sito dell'attaccante (qui: vulnweb.com ).

Iniezione dell'intestazione HTTP memorizzata

Le vulnerabilità di iniezione dell'intestazione HTTP memorizzate e gli attacchi correlati sono piuttosto rari. In questo caso, l'input dell'utente malintenzionato viene archiviato dall'applicazione Web, ad esempio in un database, e quindi utilizzato direttamente nella risposta HTTP inviata ad altri utenti.

Proprio come nel caso delle vulnerabilità di scripting tra siti archiviate, l'iniezione di intestazione HTTP archiviata è più pericolosa perché potrebbe potenzialmente influenzare tutti gli utenti che visitano il tuo sito Web o utilizzano la tua applicazione Web.

Conseguenze degli attacchi di header injection HTTP

Abbiamo descritto il caso più semplice di un attacco di iniezione di intestazione HTTP sopra: l'attaccante può sfruttare una vulnerabilità di iniezione di intestazione HTTP direttamente per utilizzare il tuo dominio come base per un attacco di phishing.

Tuttavia, ci sono più potenziali conseguenze dell'iniezione di intestazione HTTP. Ad esempio, l'attaccante può utilizzare l'iniezione di intestazione HTTP per iniettare nuove intestazioni che allentano le restrizioni di sicurezza della politica della stessa origine, rendendo così possibile eseguire altri attacchi che altrimenti sarebbero impossibili, ad esempio CSRF.

Un altro potenziale utilizzo degli attacchi di iniezione dell'intestazione HTTP è la suddivisione della risposta HTTP. In tal caso, l'attaccante non solo inietta nuove intestazioni di risposta HTTP, ma anche l'intero corpo della risposta. Utilizzando l'intestazione Content-Length , sono in grado di far sì che il browser della vittima ignori completamente il corpo legittimo della risposta (e le intestazioni legittime rimanenti).

Come rilevare ed evitare le vulnerabilità di iniezione dell’header HTTP

Il modo migliore per rilevare le vulnerabilità di iniezione dell'intestazione HTTP è utilizzare uno scanner di vulnerabilità.

Poiché l'iniezione dell’header HTTP è il risultato di una neutralizzazione impropria delle sequenze CRLF, il modo migliore per evitare tali vulnerabilità è codificare le sequenze CRLF dall'input dell'utente prima di utilizzarle nelle risposte HTTP. Ciò previene anche le conseguenze di altri attacchi che sfruttano l'iniezione di CRLF, che possono persino portare a violazioni di informazioni riservate, corruzione dei file di registro o esecuzione di codice.


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23