Posso fidarmi dell'IP sorgente di una richiesta HTTP?

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

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

Lo scopo di questi campi è che i proxy web (che potrebbero dire che il contenuto della cache serva più velocemente) possono comunicare ai server web l'indirizzo IP reale dell'utente piuttosto che l'indirizzo IP dei proxy (che potrebbe essere per centinaia di utenti). Tuttavia, dal momento che chiunque può impostare questo campo non dovrebbe essere considerato attendibile.

Can I trust the source IP of an HTTP request?

Puoi essere ragionevolmente sicuro che l'indirizzo IP di origine di una richiesta HTTP è l'indirizzo di origine della connessione TCP che ha generato la richiesta.

Quando fidarsi di un indirizzo IP è una domanda complicata relativa al contesto, ma non è proprio quello che stai chiedendo.

you are concerned about the impact of using/implementing per-IP rate limits at the application layer and any additional vulnerability to denial-of-service attacks?

     

Mi chiedo se farlo, nel livello dell'app, introduce ulteriori vulnerabilità, sì.

Dipende interamente dalla tua implementazione, sia politica che tecnologica.

• Che tipo di risorsa vuoi calcolare il consumo limite di?
• Che cosa vuoi ottenere creando questo limite di velocità?
• In quale arco di tempo vuoi eseguire la contabilità?
• Dove vuoi applicare il limite?
• L'indirizzo IP è la chiave migliore per il limite di velocità?
• Quali sono le probabili ragioni per un 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à può essere meglio posizionato altrove nell'infrastruttura del servizio, ad es. firewall dedicato, firewall locale. Oppure, se l'accesso è autenticato, la credenziale autenticata potrebbe essere una chiave migliore per il calcolo delle tariffe e i tuoi limiti saranno definiti.

Quale sarebbe il punto nell'emissione di SYN falsificato su un server HTTP se non si intende continuare l'handshake TCP? Il tuo server web non vedrà la richiesta HTTP a meno che il client (possibilmente falso) non riceva il SYN / ACK e continui a stabilire la sessione TCP e invia una richiesta HTTP.

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

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

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