it-swarm.dev

Posso fidarmi dell'IP di origine di una richiesta HTTP?

Per quanto ho capito, se provi a inoltrare una richiesta HTTP con un indirizzo IP contraffatto, l'handshake TCP fallisce, quindi non è possibile completare la richiesta HTTP, perché SYN/ACK dal server non raggiunge il client malvagio ...

... nella maggior parte dei casi. Ma ora ignoriamo principalmente questi quattro casi:
- Man in the middle (MITM) attacchi
- Il caso in cui il client malvagio controlla la rete del server Web
- Il caso in cui il client malvagio finge un altro IP sulla propria rete locale
- attacchi BGP

Allora posso davvero fidarmi dell'indirizzo IP di una richiesta HTTP?

Sfondo: Sto pensando di costruire una mappa di indirizzi IP e utilizzo delle risorse, e bloccare gli indirizzi IP che consumano troppe risorse. Ma mi chiedo se esiste, ad esempio, un modo per simulare un numero infinito di indirizzi IP (inviando richieste HTTP di successo con IP falsi), in modo che il server Web risorse-utilizzo-per-IP- buffer diventa enorme e causa errori di memoria insufficiente.

(Hmm, forse un malvagio router Internet potrebbe fingere molte richieste. Ma non sono malvagi, vero? (Questo sarebbe un attacco MITM? Ecco perché ho detto principalmente ignorare, sopra))

41
KajMagnus

Sì (con i tuoi presupposti di trascurare il client in grado di intercettare il ritorno della stretta di mano a un IP contraffatto) se fai le cose correttamente. Le richieste HTTP vengono eseguite su TCP; fino al completamento dell'handshake il server Web non inizia l'elaborazione della richiesta HTTP. Concesso a un utente casuale potrebbe tentare di falsificare la fine di una stretta di mano; ma poiché devono indovinare che il server ha generato ACK, dovrebbero avere solo 1 su 2 ^ 32 (~ 4 miliardi) possibilità di farlo ogni volta con successo.

Come ha commentato Ladadadada, assicurati di non raccogliere il valore errato dell'indirizzo IP remoto nella tua applicazione web. Si desidera l'indirizzo IP da intestazione datagramma IP (in particolare, l'indirizzo IP di origine). Non vuoi valori come X-Forwarded-For/X-Real-IP che possono essere banalmente forgiati quando sono impostati nell'intestazione HTTP. Sicuramente prova provando a falsificare alcuni indirizzi IP; con dire a plugin del browser o manualmente con telnet yourserver.com 80.

Lo scopo di questi campi è che i proxy Web (che potrebbero indicare contenuto della cache per servirlo più velocemente) possano comunicare ai server Web l'indirizzo IP reale dell'utente anziché l'indirizzo IP dei proxy (che può essere per centinaia di utenti). Tuttavia, poiché chiunque può impostare questo campo non dovrebbe essere attendibile.

23
dr jimbob

Posso fidarmi dell'IP sorgente di una richiesta HTTP?

Si può essere ragionevolmente certi che l'indirizzo IP di origine di una richiesta HTTP sia l'indirizzo di origine della TCP che ha generato la richiesta.

Quando fidarsi di un indirizzo IP è una domanda complessa specifica per il contesto, ma non è proprio quello che stai chiedendo.

sei preoccupato per l'impatto dell'utilizzo/implementazione dei limiti di velocità per IP a livello di applicazione e di ogni ulteriore vulnerabilità agli attacchi denial-of-service?

Mi chiedo se farlo, a livello di app, introduce ulteriori vulnerabilità, sì.

Dipende interamente dalla tua implementazione, sia politica che tecnologica.

  • Di quale tipo di risorsa vuoi limitare il consumo?
  • Cosa vuoi ottenere creando questo limite di tariffa?
  • In quale periodo di tempo desideri eseguire la contabilità?
  • Dove vuoi applicare il limite?
  • L'indirizzo IP è la chiave migliore per il limite di velocità?
  • Quali sono le probabili ragioni del consumo eccessivo?
  • Quale dovrebbe essere l'esperienza dell'utente in caso di consumo eccessivo?

A seconda delle risposte a queste domande, il limite di velocità potrebbe essere posizionato meglio altrove nell'infrastruttura di servizio, ad es. firewall dedicato, firewall locale. Oppure, se l'accesso è autenticato, le credenziali autenticate potrebbero essere una chiave migliore per la contabilità dei tassi e verrebbero definiti i limiti.

2
MattH

Quale sarebbe il punto nel rilascio di SYN contraffatto a un server HTTP se non si intende continuare l'handshake TCP? Il tuo server web non vedrà la richiesta HTTP a meno che il (eventualmente falso) il client ottiene SYN/ACK e continua a stabilire la TCP e invia una richiesta HTTP.

Archivia il database su disco, strutturalo in modo intelligente (come un albero) per ricerche veloci.

Se il cliente è falsificato o no, fa davvero la differenza per te? Se si comportano male, si comportano male, non importa se sono falsificati o meno.

Dal punto di vista del web server, considererei l'IP remoto come il vero IP remoto.

1
MattBianco