Questo articolo presenta alcuni problemi di sicurezza nel protocollo HTTP , sollevati in due documenti RFC 7230 e RFC 7231. Gli esempi nell'articolo relativi a errori specifici sono referenziati da OWASP.
1. Rischi derivanti da fattori intermedi
HTTP consente l'utilizzo di intermediari per rispondere alle richieste attraverso una serie di connessioni. Esistono tre elementi intermediari comuni: proxy, gateway e tunnel.
Una richiesta o una risposta dovrà passare attraverso i punti A, B e C. Possono accedere alle informazioni sensibili trasmesse, come le informazioni personali di utenti o organizzazioni. La mancanza di attenzione prestata alla sicurezza e alla privacy da parte degli intermediari può portare ad un’ampia gamma di potenziali attacchi.
Gli sviluppatori e gli sviluppatori di sistema dovrebbero considerare i fattori di privacy e sicurezza durante il processo di progettazione, codifica e distribuzione del sistema.
Gli utenti devono essere consapevoli dei pericoli derivanti dall'utilizzo di proxy o gateway non attendibili.
2. Suddivisione della risposta
La suddivisione della risposta (nota anche come CRLF injection) è una tecnica di exploit web popolare. L'attaccante invia dati codificati, in alcuni parametri della richiesta, che vengono poi decodificati e ripetuti in un determinato campo dell'intestazione della risposta.
Se questi dati sono un simbolo che rappresenta la fine della risposta e viene avviata una risposta successiva, la risposta originale verrà divisa in due e il contenuto della seconda risposta sarà controllato dall'aggressore. L'aggressore può quindi effettuare un'altra richiesta all'interno della stessa connessione persistente e ingannare il destinatario (inclusi gli intermediari) facendogli credere che questa seconda risposta sia in risposta alla seconda richiesta.
3. Richiesta di contrabbando
Il contrabbando di richieste è una tecnica che sfrutta le differenze nell'elaborazione delle richieste da parte di diversi tipi di server per nascondere richieste apparentemente innocue aggiunte alla richiesta originale.
Consideriamo il seguente esempio:
Supponiamo che una richiesta POST contenga due campi "Content-length" nell'intestazione con due valori diversi. Alcuni server negheranno questa richiesta (IIS e Apache), ma altri no. Ad esempio, SunONE W/S 6.1 utilizza per primo il campo Lunghezza contenuto, mentre sunONE Proxy 3.6 utilizza per secondo il campo Lunghezza contenuto.
Supponendo che SITE sia il DNS di SunONE W/S, situato dietro un proxy SunONE, è presente un file veleno.html situato su SunONE W/S. Ecco come sfruttare il suggerimento di richiesta HTTP basato su incoerenze nell'elaborazione tra due server:
[Nota che ogni riga termina con un CRLF (“”), tranne la riga 10]
Consideriamo cosa succede quando una richiesta viene inviata a W/S tramite il server Proxy. Innanzitutto, il proxy analizzerà la richiesta dalle righe da 1 a 7 (blu) e incontrerà due campi Content-Length. Come accennato in precedenza, ignorerà il primo campo e comprenderà che il corpo della richiesta è lungo 44 byte. Pertanto, tratta i dati dalle righe da 8 a 10 come il primo corpo della richiesta (dalle righe da 8 a 10, i dati sono lunghi esattamente 44 byte). Il proxy analizzerà quindi le righe da 11 a 14 (in rosso) come seconda richiesta del client.
Ora vediamo come W/S interpreta i dati sopra, così come vengono inoltrati dal proxy. A differenza dei proxy, W/S utilizzerà il primo campo Content-Length e lo interpreterà come segue: la prima richiesta non ha corpo e la seconda richiesta inizia dalla riga 8 (nota che W/S analizzerà dalla riga 11 in poi come il valore del campo Bla).
Successivamente, vediamo come viene restituita la risposta al client. La richiesta che W/S capisce è “POST /foobar.html” (dalla riga 1) e “GET /poison.html” (dalla riga 8), quindi invierà al client 2 risposte con il contenuto della pagina foobar. html e veleno.html. Il proxy capisce che queste 2 risposte corrispondono a 2 richieste: "POST /foobar.html" (dalla riga 1) e "GET /page_to_poison.html" (riga 11). Il proxy memorizzerà nella cache il contenuto della pagina veleno.html corrispondente all'URL “page_to_poison.html” (cache Poison). Da lì, quando il client richiede "page_to_poison.html" riceverà il contenuto della pagina Poison.html.
4. Attacco basato sul percorso del file
I server Web utilizzano spesso il file system locale per gestire la mappatura dei nomi di file negli URI sulle risorse effettive sul server. La maggior parte dei file system non è progettata per proteggere da percorsi di file dannosi. Pertanto, il server deve evitare di accedere a file di sistema importanti.
Ad esempio, UNIX, Microsoft Windows e molti altri sistemi operativi utilizzano ".." come elemento di percorso per rappresentare una directory un livello sopra il file/directory corrente. Senza un adeguato controllo e autorizzazione dell'input, è possibile accedere a file/cartelle sensibili del sistema inserendo percorsi che puntano a tali file/cartelle.
5. Tipi di attacchi: Command Injection, Code Injection, Query Injection
[I server Web spesso utilizzano parametri nell'URI come input per eseguire comandi di sistema e query di database. Tuttavia, i dati ricevuti nella richiesta non sono sempre attendibili. Un utente malintenzionato può creare e modificare componenti nella richiesta (come metodi, campi nell'intestazione, corpo...), per eseguire comandi di sistema, interrogare il database...
Ad esempio, SQL Injection è un attacco comune in cui il server web riceve parametri nell'URI che fanno parte della query SQL. Pertanto, un utente malintenzionato può ingannare il server Web per eseguire query SQL illegali, al fine di rubare o sabotare il database.
In generale, i dati conferiti dagli utenti non devono essere utilizzati direttamente per eseguire operazioni sul server. Questi dati devono passare attraverso filtri che definiscono cosa è valido e cosa non è valido, eliminando così i dati indesiderati.
6. Rivelazione di informazioni personali
I client spesso contengono molte informazioni personali, comprese le informazioni fornite dall'utente per interagire con il server (come nome utente, password, posizione, indirizzo e-mail, ecc.) e informazioni sulle attività di navigazione Web dell'utente (cronologia, segnalibri, eccetera.). Durante l'implementazione, è necessario prestare attenzione a prevenire i punti che possono rivelare queste informazioni private.
7. Rivelazione di informazioni sensibili nell'URI
Gli URI, per impostazione predefinita, sono pensati per essere condivisi con tutti gli utenti e non è garantita la loro sicurezza. Gli URI vengono spesso visualizzati nel codice sorgente del sito Web e vengono archiviati nei segnalibri senza meccanismi di protezione. Pertanto, non sarà sicuro se l'URI contiene informazioni sensibili, informazioni personali, ecc.
Evitare di utilizzare il metodo GET per inviare informazioni personali al server, poiché verranno visualizzate nell'URI. Utilizzare invece il metodo POST.
8. Rivelazione delle informazioni sul software utilizzato
I campi User-Agent, Via, Server nell'intestazione solitamente forniscono informazioni sul software utilizzato dal mittente. In teoria, ciò consente agli aggressori di sfruttare più facilmente le vulnerabilità note di questi software.
