Codice vulnerabile suggerito su OWASP?

Questo codice consente a un utente malintenzionato che conosce il X-Forwarded-For: intestazione della vittima e l'ID di sessione della vittima per accedere come tale utente. Se la vittima non ha un'intestazione X-Forwarded-For: , l'utente malintenzionato può inserire l'indirizzo IP della vittima nella sua intestazione e il codice utilizzerà tale valore come suo indirizzo IP legittimo invece del suo effettivo indirizzo IP. Questa è la vulnerabilità .

• In uno scenario di sniffing della rete, l'utente malintenzionato ottiene entrambi questi valori allo stesso tempo, quindi l'aggiunta di questo codice non protegge dallo sniffing della rete.

• In uno scenario XSS, in cui l'utente malintenzionato inietta javascript per sottrarre il cookie dell'utente, di solito ciò avviene facendo in modo che il browser della vittima effettui una richiesta a un server Web controllato da un utente malintenzionato con il valore cookie aggiunto come GET parametro. L'intestazione X-Forwarded-For: della vittima sarebbe stata fornita all'attaccante in quella richiesta.

Non sono ancora stato in grado di pensare a uno scenario in cui un utente malintenzionato potrebbe ottenere il cookie di una vittima ma non è in grado di ottenere il valore di un'intestazione X-Forwarded-For: legittima o, se non è presente un'intestazione, l'indirizzo IP della vittima .

Quindi la risposta è sì , come scritto, questo codice non fa nulla per migliorare la sicurezza. Dovrebbe avere fiducia nell'indirizzo IP direttamente connesso solo .

Nota: se il tuo server di applicazioni web è dietro un proxy web inverso (come nginx, Varnish, HAProxy, mod_proxy, Amazon ELB e molti altri) che aggiunge sempre l'indirizzo IP di connessione a X-Forwarded-For header e crea una nuova connessione al server di applicazioni Web con il proprio indirizzo IP, puoi "fidarti" di parte del valore di questa intestazione.

Moduli come mod_rpaf o mod_remoteip per Apache possono essere configurati con un elenco di indirizzi IP proxy affidabili e sostituiranno il valore di REMOTE_ADDR con la parte attendibile dell'intestazione X-Forwarded-For per le connessioni provenienti da quelli indirizzi. Questo REMOTE_ADDR sarà disponibile in PHP come $_SERVER['REMOTE_ADDR] e verrà registrato nei tuoi file di log Apache come vero indirizzo IP di connessione.

Se non lo fai (o l'equivalente se non usi Apache), vedrai solo le connessioni da un indirizzo IP, il tuo server proxy inverso, e quindi tutte le sessioni conterranno lo stesso indirizzo IP.

Direi che hai ragione! Sembra che non abbiano tenuto a mente che l'intestazione HTTP X-FORWARDED-FOR potrebbe restituire '; DROP TABLE users;-- .

Lo suggeriscono per bloccare anche le sessioni per le persone dietro i proxy e nominare Tor come esempio. Questo è un po 'stupido; Tor non inoltra mai l'IP originale per ovvi motivi. Inoltre, non dovrebbe (non dovrebbe?) Nemmeno guardare il pacchetto stesso; semplicemente lo inoltra fino a quando non è fuori dalla rete. A cosa serve un proxy se l'IP originale viene comunque inoltrato? Basta bloccarlo all'indirizzo remoto, questa è l'unica scommessa sicura. Anche se dovessi convalidare l'intestazione x-forwarded-for come indirizzo IPv4 o IPv6 valido, potrebbe ancora contenere un IP arbitrario.

Sotto il codice di esempio su quella pagina, pensano agli IP locali e IPv6 (anche se gli esempi IPv6 contengono indirizzi non validi):

Keep in mind that in local environments, a valid IP is not returned, and usually the string :::1 or :::127 might pop up, thus adapt your IP checking logic.

Ma dovrebbero anche aver pensato che l'intestazione può contenere dati arbitrari. Bella scoperta!

Dato che è un wiki, immagino che chiunque abbia un account possa modificare la pagina. In caso contrario, dovresti contattarli. Questa è davvero una cattiva pratica e molte persone potrebbero persino inserire $IP senza escape in un database. Di solito non è possibile spoofare la variabile ambientale REMOTE_ADDR, quindi dovrebbe essere sicuro in circostanze normali (anche se non lo inserirò senza caratteri di escape anche se così fosse), ma l'intestazione X-forwarded-for rompe tutto qui.

Questo codice è un controllo di sicurezza e, come tale, deve essere valutato rispetto alla minaccia che intendeva controllare. In questo caso, non viene concesso alcun accesso speciale in base all'indirizzo IP. Invece, l'indirizzo IP viene utilizzato come vincolo aggiuntivo su un meccanismo di autorizzazione già strong (cookie HTTP).

È vero che un utente malintenzionato potrebbe falsificare l'IP di un utente tramite l'intestazione X-Forwarded-For e ignorare questo controllo aggiuntivo, ma ciò significa che l'utente malintenzionato non deve conoscere solo l'ID sessione dell'utente (cookie), ma anche l'utente Indirizzo IP. Ciò rende più difficile lo sfruttamento del XSS rubato in sessione.

Considera gli altri modi in cui questo controllo avrebbe potuto essere affrontato. Innanzitutto, se il controllo non fosse affatto a posto, qualsiasi attacco di furto di sessione (XSS, sniffing del traffico, SSL MITM, ecc.) Risulterebbe in una sessione completamente utilizzabile per l'utente malintenzionato, senza ulteriori interventi.

Invece, se il controllo fosse implementato senza consultare l'intestazione X-Forwarded-For, ma solo HTTP_REMOTE_ADDR, quindi un utente malintenzionato dietro lo stesso proxy (in una scuola o in un'azienda, per esempio) non avrebbe bisogno di alcuna conoscenza del controllo o l'IP interno dell'utente per avere una sessione completamente utilizzabile, dal momento che tutte le sessioni HTTP in uscita sembrano provenire dallo stesso IP (quello del proxy).

Aggiungendo il controllo per X-Forwarded-For, il controllo richiede a un utente malintenzionato di conoscere l'indirizzo IP dell'utente e la possibilità di spoofarlo nell'intestazione X-Forwarded-For (non tutti gli utenti malintenzionati sono completamente non vincolati, quindi c'è una riduzione del rischio, non un'eliminazione del rischio, dal momento che dobbiamo supporre che ci siano alcuni attaccanti non vincolati.)

Un modo per potenziare questo controllo sarebbe quello di conservare un ulteriore bit di informazioni: la fonte dell'ultimo indirizzo IP che è stato utilizzato. Ad esempio, se la sessione è stata inizialmente concessa e associata a un IP proveniente da HTTP_REMOTE_ADDR, il controllo potrebbe richiedere che il traffico futuro su quella sessione provenga da un IP ottenuto da HTTP_REMOTE_ADDR, non da X-Forwarded-For. Ciò elimina alcune possibilità di spoofing. I guadagni per l'implementazione del check in reverse (preferendo X-Forwarded-For su HTTP_REMOTE_ADDR) probabilmente non valgono la pena, dal momento che è molto più difficile spoofare un vero indirizzo di rete rispetto a un'intestazione HTTP.