Ottieni l'indirizzo IP reale del client su Heroku

Question

Su Heroku Cedar, volevo ottenere l'IP del client. Primo tentativo:

ENV['REMOTE_ADDR'] 

Questo non funziona, ovviamente, perché tutte le richieste vengono passate tramite proxy. Quindi l'alternativa era quella di usare:

ENV['HTTP_X_FORWARDED_FOR'] 

Ma questo non è abbastanza sicuro, vero?

Se contiene solo un valore, prendo questo. Se contiene più di un valore (separati da virgola), potrei prendere il primo.

Ma cosa succede se qualcuno manipola questo valore? Non posso fidarmi di ENV['HTTP_X_FORWARDED_FOR'] come ho potuto con ENV['REMOTE_ADDR']. E non c'è nessuna lista di proxy fidati che potrei usare, neanche io.

Ma ci deve essere in qualche modo per ottenere in modo affidabile l'indirizzo IP del client, sempre. Ne conosci uno?

In their docs, Heroku descrive che X-Forwarded-For è "l'indirizzo IP di origine del client che si connette al router Heroku".

Sembra che Heroku possa sovrascrivere lo X-Forwarded-For con l'IP remoto di origine. Ciò impedirebbe spoofing, giusto? Qualcuno può verificare questo?

Answer 1

Da Jacob, direttore della sicurezza di Heroku al momento:

Il router non sovrascrive X-Forwarded-For, ma non garantisce che la vera origine sarà sempre l'ultima vocenella lista.

Ciò significa che, se si accede a un app Heroku in modo normale, sarà solo vedere il tuo indirizzo IP nel X-Forwarded-For intestazione:

$ curl http://httpbin.org/ip 
{ 
    "origin": "123.124.125.126", 
} 

Se si tenta di falsificare l'IP, il presunto l'origine è riflessa, ma - in modo critico - così è il tuo vero IP. Ovviamente, questo è tutto quello che dobbiamo, quindi non c'è una soluzione chiara e sicura per ottenere l'indirizzo IP del client su Heroku:

$ curl -H"X-Forwarded-For: 8.8.8.8" http://httpbin.org/ip 
{ 
    "origin": "8.8.8.8, 123.124.125.126" 
} 

Questo è esattamente l'opposto di what is described on Wikipedia, tra l'altro.

applicazione PHP:

function getIpAddress() { 
    if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { 
     $ipAddresses = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']); 
     return trim(end($ipAddresses)); 
    } 
    else { 
     return $_SERVER['REMOTE_ADDR']; 
    } 
} 

Answer 2

Non si può mai davvero fidarsi di qualsiasi informazione proveniente dal cliente. È più una questione di chi ti fidi e come lo verifichi. Persino Heroku può essere influenzato per fornire un valore errato HTTP_X_FORWARDED_FOR se ha un bug nel loro codice, o viene hackerato in qualche modo. Un'altra opzione potrebbe essere un'altra macchina di Heroku che si collega al server internamente e bypassando del tutto il proxy mentre simulando REMOTE_ADDR e/o HTTP_X_FORWARDED_FOR.

La migliore risposta qui dipenderà da ciò che stai cercando di fare. Se stai provando a verificare i tuoi clienti, un certificato sul lato client potrebbe essere una soluzione più appropriata. Se tutto ciò di cui hai bisogno per l'IP è geo-localizzazione, fidarti dell'input potrebbe essere abbastanza buono. Nel peggiore dei casi, qualcuno falsificherà la posizione e otterrà il contenuto sbagliato ... Se hai un caso d'uso diverso, ci sono molte altre soluzioni tra questi due estremi.

Answer 3

Io lavoro nel reparto di assistenza di Heroku e hanno trascorso un po 'di tempo a discutere di questo con i nostri ingegneri di routing. Volevo pubblicare alcune informazioni aggiuntive per chiarire alcune cose su cosa sta succedendo qui.

L'esempio fornito nella risposta sopra ha avuto l'IP del client visualizzato per ultima coincidenza e questo non è realmente garantito. Il motivo per cui non è stato il primo è perché la richiesta di origine ha affermato che stava inoltrando per l'IP specificato nell'intestazione X-Forwarded-For. Quando il router Heroku ha ricevuto la richiesta, ha semplicemente aggiunto l'IP che si collegava direttamente all'elenco X-Forwarded-For dopo quello che era stato iniettato nella richiesta. Il nostro router aggiunge sempre l'IP collegato all'ADB di AWS di fronte alla nostra piattaforma come ultimo IP nell'elenco. Questo IP potrebbe essere quello originale (e nel caso in cui vi sia un solo IP, è quasi certamente), ma nell'istante in cui vi sono più IP concatenati, tutte le scommesse sono disattivate. La convenzione è sempre quella di aggiungere l'ultimo IP della catena alla fine della lista (che è ciò che facciamo), ma in qualsiasi punto della catena tale catena può essere modificata e possono essere inseriti diversi IP. In quanto tale, l'unico IP affidabile (dal punto di vista della nostra piattaforma) è l'ultimo IP nell'elenco.

Per illustrare, diciamo che qualcuno avvia una richiesta e aggiunge arbitrariamente 3 indirizzi IP aggiuntivi per l'intestazione X-Forwarded-For:

curl -H "X-Forwarded-For: 12.12.12.12,15.15.15.15,4.4.4.4" http://www.google.com 

Immaginate IP di questa macchina era 9.9.9.9 e che doveva passare attraverso un proxy (ad es. un proxy universitario di livello universitario). Diciamo che il proxy ha avuto un IP di 2.2.2.2. Supponendo che non fosse configurato per rimuovere le intestazioni X-Forwarded-For (che probabilmente non sarebbe), si limiterebbe a virare l'IP 9.9.9.9 alla fine dell'elenco e passare la richiesta a Google. A questo punto, l'intestazione sarebbe simile a questa:

X-Forwarded-For: 12.12.12.12,15.15.15.15,4.4.4.4,9.9.9.9 

Tale richiesta sarà poi passare attraverso endpoint di Google, che aggiungerà IP del proxy universitaria di 2.2.2.2, quindi l'intestazione finalmente questo aspetto nei registri di Google :

X-Forwarded-For: 12.12.12.12,15.15.15.15,4.4.4.4,9.9.9.9,2.2.2.2 

Quindi, qual è l'IP del client? È impossibile dirlo dal punto di vista di Google. In realtà, l'IP del client è 9.9.9.9. L'ultimo IP elencato è 2.2.2.2 e il primo è 12.12.12.12. Tutto ciò che Google potrebbe sapere è che l'IP 2.2.2.2 è sicuramente corretto perché quello era l'IP effettivamente connesso al loro servizio, ma non saprebbero se quello era il client iniziale per la richiesta o meno dai dati disponibili. Allo stesso modo, quando in questa intestazione c'è un solo IP, questo è l'IP direttamente connesso al nostro servizio, quindi sappiamo che è affidabile.

Dal punto di vista pratico, questo IP sarà probabilmente affidabile maggior parte del tempo (perché la maggior parte delle persone non saranno preoccuparsi di spoofing loro IP). Sfortunatamente, è impossibile prevenire questo tipo di spoofing e quando una richiesta arriva al router Heroku, è impossibile per noi sapere se gli IP in una catena X-Forwarded-For sono stati manomessi o meno.

Tutti i problemi di affidabilità a parte, queste catene IP devono sempre essere lette da sinistra a destra. Il client IP dovrebbe essere sempre l'IP più a sinistra.