9. Considerazioni sulla sicurezza

Questa sezione è intesa a informare sviluppatori, fornitori di informazioni e utenti sulle considerazioni di sicurezza note relative alla sintassi, all'analisi e all'instradamento dei messaggi HTTP. Le considerazioni di sicurezza sulla semantica e sui payload di HTTP sono trattate in [RFC7231].

9.1. Stabilire l'autorità

HTTP si basa sulla nozione di risposta autorevole: una risposta che è stata determinata da (o su indicazione di) l'autorità identificata nel target URI come la risposta più appropriata per quella richiesta, dato lo stato della risorsa di destinazione al momento della creazione del messaggio di risposta. Fornire una risposta da una fonte non autorevole, come una cache condivisa, è spesso utile per migliorare prestazioni e disponibilità, ma solo nella misura in cui la fonte possa essere considerata attendibile oppure la risposta non attendibile possa essere usata in modo sicuro.

Purtroppo, stabilire l'autorità può essere difficile. Ad esempio, il phishing è un attacco alla percezione dell'autorità da parte dell'utente, percezione che può essere fuorviata presentando un branding simile nell'ipertesto, eventualmente con l'aiuto di userinfo che offusca il componente authority (vedere la Sezione 2.7.1). Gli user agent possono ridurre l'impatto degli attacchi di phishing consentendo agli utenti di ispezionare facilmente un target URI prima di compiere un'azione, distinguendo in modo evidente (o rifiutando) lo userinfo quando presente, e non inviando credenziali e cookie memorizzati quando il documento di provenienza è di origine sconosciuta o non attendibile.

Quando nel componente authority viene usato un nome registrato, lo schema URI "http" (Sezione 2.7.1) si basa sul servizio di risoluzione dei nomi locale dell'utente per determinare dove può trovare risposte autorevoli. Ciò significa che qualsiasi attacco alla tabella degli host di rete dell'utente, ai nomi in cache o alle librerie di risoluzione dei nomi diventa una via d'attacco per stabilire l'autorità. Allo stesso modo, la scelta dell'utente del server per il Domain Name Service (DNS), e la gerarchia di server da cui ottiene i risultati di risoluzione, potrebbero influire sull'autenticità delle mappature degli indirizzi; le DNS Security Extensions (DNSSEC, [RFC4033]) sono un modo per migliorare l'autenticità.

Inoltre, una volta ottenuto un indirizzo IP, stabilire l'autorità per un URI "http" è vulnerabile ad attacchi all'instradamento del protocollo Internet.

Lo schema "https" (Sezione 2.7.2) è inteso a prevenire (o almeno a rivelare) molti di questi potenziali attacchi allo stabilire l'autorità, purché la connessione TLS negoziata sia protetta e il client verifichi correttamente che l'identità del server comunicante corrisponda al componente authority del target URI (vedere [RFC2818]). Implementare correttamente tale verifica può essere difficile (vedere [Georgiev]).

9.2. Rischi degli intermediari

Per loro stessa natura, gli intermediari HTTP sono uomini nel mezzo e, quindi, rappresentano un'opportunità per attacchi man-in-the-middle. La compromissione dei sistemi su cui vengono eseguiti gli intermediari può causare seri problemi di sicurezza e privacy. Gli intermediari potrebbero avere accesso a informazioni relative alla sicurezza, a informazioni personali su singoli utenti e organizzazioni, e a informazioni proprietarie appartenenti agli utenti e ai fornitori di contenuti. Un intermediario compromesso, oppure un intermediario implementato o configurato senza riguardo per le considerazioni di sicurezza e privacy, potrebbe essere usato nella commissione di un'ampia gamma di potenziali attacchi.

Gli intermediari che contengono una cache condivisa sono particolarmente vulnerabili agli attacchi di cache poisoning, come descritto nella Sezione 8 di [RFC7234].

Gli implementatori devono considerare le implicazioni per la privacy e la sicurezza delle loro decisioni di progettazione e di codifica, e delle opzioni di configurazione che forniscono agli operatori (specialmente la configurazione predefinita).

Gli utenti devono essere consapevoli che gli intermediari non sono più affidabili delle persone che li gestiscono; HTTP stesso non può risolvere questo problema.

9.3. Attacchi tramite la lunghezza degli elementi di protocollo

Poiché HTTP usa soprattutto campi testuali delimitati da caratteri, i parser sono spesso vulnerabili ad attacchi basati sull'invio di flussi di dati molto lunghi (o molto lenti), in particolare quando un'implementazione si aspetta un elemento di protocollo senza lunghezza predefinita.

Per promuovere l'interoperabilità, vengono fornite raccomandazioni specifiche sui limiti minimi di dimensione per la request-line (Sezione 3.1.1) e per i campi di intestazione (Sezione 3.2). Si tratta di raccomandazioni minime, scelte in modo da poter essere supportate anche da implementazioni con risorse limitate; ci si aspetta che la maggior parte delle implementazioni scelga limiti sostanzialmente più alti.

Un server può rifiutare un messaggio che ha un request-target troppo lungo (Sezione 6.5.12 di [RFC7231]) oppure un payload di richiesta troppo grande (Sezione 6.5.11 di [RFC7231]). Codici di stato aggiuntivi relativi ai limiti di capacità sono stati definiti da estensioni a HTTP [RFC6585].

I destinatari dovrebbero limitare attentamente la misura in cui elaborano altri elementi di protocollo, inclusi (ma non limitati a) metodi di richiesta, frasi di stato delle risposte, field-name di intestazione, valori numerici e chunk del corpo. La mancata limitazione di tale elaborazione può comportare buffer overflow, overflow aritmetici o una maggiore vulnerabilità agli attacchi di denial-of-service.

9.4. Response splitting

Il response splitting (detto anche CRLF injection) è una tecnica comune, usata in vari attacchi all'uso del Web, che sfrutta la natura basata su righe dell'inquadratura dei messaggi HTTP e l'associazione ordinata tra richieste e risposte sulle connessioni persistenti [Klein]. Questa tecnica può essere particolarmente dannosa quando le richieste passano attraverso una cache condivisa.

Il response splitting sfrutta una vulnerabilità nei server (di solito all'interno di un application server) per cui un attaccante può inviare dati codificati all'interno di qualche parametro della richiesta, che viene poi decodificato e riprodotto all'interno di uno qualsiasi dei campi di intestazione della risposta. Se i dati decodificati sono confezionati in modo da sembrare che la risposta sia terminata e ne sia iniziata una successiva, la risposta è stata divisa e il contenuto all'interno della presunta seconda risposta è controllato dall'attaccante. L'attaccante può quindi effettuare qualsiasi altra richiesta sulla stessa connessione persistente e indurre i destinatari (inclusi gli intermediari) a credere che la seconda metà della divisione sia una risposta autorevole alla seconda richiesta.

Ad esempio, un parametro all'interno del request-target potrebbe essere letto da un application server e riutilizzato all'interno di un reindirizzamento, con il risultato che lo stesso parametro viene riprodotto nel campo di intestazione Location della risposta. Se il parametro viene decodificato dall'applicazione e non correttamente codificato quando viene inserito nel campo della risposta, l'attaccante può inviare ottetti CRLF codificati e altri contenuti che faranno sembrare la singola risposta dell'applicazione come due o più risposte.

Una difesa comune contro il response splitting consiste nel filtrare le richieste relative a dati che sembrano CR e LF codificati (ad es. "%0D" e "%0A"). Tuttavia, ciò presuppone che l'application server esegua solo la decodifica URI, anziché trasformazioni di dati più oscure come la transcodifica di charset, la traduzione di entità XML, la decodifica base64, la riformattazione sprintf, ecc. Una mitigazione più efficace consiste nell'impedire a qualsiasi cosa diversa dalle librerie di protocollo principali del server di inviare un CR o un LF all'interno della sezione di intestazione, il che significa limitare l'output dei campi di intestazione ad API che filtrano gli ottetti non validi e non consentire agli application server di scrivere direttamente sul flusso del protocollo.

9.5. Request smuggling

Il request smuggling ([Linhart]) è una tecnica che sfrutta le differenze nell'analisi del protocollo tra i vari destinatari per nascondere richieste aggiuntive (che altrimenti potrebbero essere bloccate o disabilitate da una policy) all'interno di una richiesta apparentemente innocua. Come il response splitting, il request smuggling può portare a una varietà di attacchi all'uso di HTTP.

Questa specifica ha introdotto nuovi requisiti sull'analisi delle richieste, in particolare per quanto riguarda l'inquadratura dei messaggi nella Sezione 3.3.3, per ridurre l'efficacia del request smuggling.

9.6. Integrità dei messaggi

HTTP non definisce un meccanismo specifico per garantire l'integrità dei messaggi, affidandosi invece alla capacità di rilevamento degli errori dei protocolli di trasporto sottostanti e all'uso di un'inquadratura delimitata da lunghezza o da chunk per rilevare la completezza. Meccanismi di integrità aggiuntivi, come funzioni di hash o firme digitali applicate al contenuto, possono essere aggiunti selettivamente ai messaggi tramite campi di intestazione di metadati estensibili. Storicamente, la mancanza di un unico meccanismo di integrità è stata giustificata dalla natura informale della maggior parte della comunicazione HTTP. Tuttavia, la diffusione di HTTP come meccanismo di accesso alle informazioni ha portato a un suo uso crescente in ambienti in cui la verifica dell'integrità dei messaggi è cruciale.

Gli user agent sono incoraggiati a implementare mezzi configurabili per rilevare e segnalare i fallimenti dell'integrità dei messaggi, in modo che tali mezzi possano essere abilitati in ambienti in cui l'integrità è necessaria. Ad esempio, un browser usato per visualizzare la storia clinica o informazioni sulle interazioni tra farmaci deve indicare all'utente quando tali informazioni vengono rilevate dal protocollo come incomplete, scadute o corrotte durante il trasferimento. Tali meccanismi potrebbero essere abilitati selettivamente tramite estensioni dello user agent o la presenza di metadati di integrità del messaggio in una risposta. Come minimo, gli user agent dovrebbero fornire qualche indicazione che consenta a un utente di distinguere tra un messaggio di risposta completo e uno incompleto (Sezione 3.4) quando tale verifica è desiderata.

9.7. Riservatezza dei messaggi

HTTP si basa sui protocolli di trasporto sottostanti per fornire la riservatezza dei messaggi quando questa è desiderata. HTTP è stato progettato specificamente per essere indipendente dal protocollo di trasporto, cosicché possa essere usato su molte forme diverse di connessione cifrata, con la selezione di tali trasporti identificata dalla scelta dello schema URI o all'interno della configurazione dello user agent.

Lo schema "https" può essere usato per identificare risorse che richiedono una connessione riservata, come descritto nella Sezione 2.7.2.

9.8. Privacy delle informazioni nei log del server

Un server è in grado di salvare nel tempo dati personali sulle richieste di un utente, che potrebbero identificare i suoi schemi di lettura o i suoi argomenti di interesse. In particolare, le informazioni di log raccolte presso un intermediario contengono spesso una storia delle interazioni dello user agent, attraverso una moltitudine di siti, che può essere ricondotta a singoli utenti.

Le informazioni di log HTTP sono di natura riservata; la loro gestione è spesso vincolata da leggi e regolamenti. Le informazioni di log devono essere archiviate in modo sicuro e devono essere seguite linee guida appropriate per la loro analisi. L'anonimizzazione delle informazioni personali all'interno delle singole voci aiuta, ma generalmente non è sufficiente a impedire che tracce di log reali vengano reidentificate sulla base della correlazione con altre caratteristiche di accesso. Pertanto, le tracce di accesso associate a un client specifico non sono sicure da pubblicare anche se la chiave è pseudonima.

Per ridurre al minimo il rischio di furto o di pubblicazione accidentale, le informazioni di log dovrebbero essere ripulite dalle informazioni personalmente identificabili, inclusi identificatori utente, indirizzi IP e parametri di query forniti dall'utente, non appena tali informazioni non sono più necessarie a supportare le esigenze operative di sicurezza, auditing o controllo delle frodi.