Skip to main content
Information Security

Return to Answer

added 333 characters in body
Source Link
dr jimbob
dr jimbob
  • 39.5k
  • 8
  • 95
  • 164

Yes (with your assumptions of neglecting the client being able to intercept the return of the handshake at a spoofed IP) if you do things correctly. HTTP requests are done over TCP; until the handshake is completed the web server doesn't start processing the HTTP request. As Granted a random user could attempt to spoof the end of a handshake; but as they have to guess the server generated ACK, they should only have a 1 in 2^32 (~4 billion) chance of doing it successfully each time.

As Ladadadada commented make sure you aren't picking up the wrong value of the remote IP address in your web application. You want the IP address from the IP datagram header (specifically, the source IP address). You do not want values like X-Forwarded-For / X-Real-IP that can be trivially forged as they are set in the HTTP header. (The Definitely test by trying to spoof some IP addresses; with say a browser plugin or manually with telnet yourserver.com 80.

The purpose of these fields is so web proxies (that may say cache content to serve it faster) can identifycommunicate to webservers the usersuser's real IP address rather than the proxies IP address; howeveraddress (which may be for hundreds of users). However, since anyone can set this) field it should not be trusted.

Yes if you do things correctly. HTTP requests are done over TCP; until the handshake is completed the web server doesn't start processing the HTTP request. As Ladadadada commented make sure you aren't picking up the wrong value of the remote IP address. You want the IP address from the IP datagram header (specifically, the source IP address). You do not want values like X-Forwarded-For / X-Real-IP that can be trivially forged as they are set in the HTTP header. (The purpose of these fields is so proxies can identify the users IP address rather than the proxies IP address; however anyone can set this).

Yes (with your assumptions of neglecting the client being able to intercept the return of the handshake at a spoofed IP) if you do things correctly. HTTP requests are done over TCP; until the handshake is completed the web server doesn't start processing the HTTP request. Granted a random user could attempt to spoof the end of a handshake; but as they have to guess the server generated ACK, they should only have a 1 in 2^32 (~4 billion) chance of doing it successfully each time.

As Ladadadada commented make sure you aren't picking up the wrong value of the remote IP address in your web application. You want the IP address from the IP datagram header (specifically, the source IP address). You do not want values like X-Forwarded-For / X-Real-IP that can be trivially forged as they are set in the HTTP header. Definitely test by trying to spoof some IP addresses; with say a browser plugin or manually with telnet yourserver.com 80.

The purpose of these fields is so web proxies (that may say cache content to serve it faster) can communicate to webservers the user's real IP address rather than the proxies IP address (which may be for hundreds of users). However, since anyone can set this field it should not be trusted.

Source Link
dr jimbob
dr jimbob
  • 39.5k
  • 8
  • 95
  • 164

Yes if you do things correctly. HTTP requests are done over TCP; until the handshake is completed the web server doesn't start processing the HTTP request. As Ladadadada commented make sure you aren't picking up the wrong value of the remote IP address. You want the IP address from the IP datagram header (specifically, the source IP address). You do not want values like X-Forwarded-For / X-Real-IP that can be trivially forged as they are set in the HTTP header. (The purpose of these fields is so proxies can identify the users IP address rather than the proxies IP address; however anyone can set this).