¿Puedo confiar en la IP de origen de una solicitud HTTP?

Sí (con sus suposiciones de descuidar que el cliente sea capaz de interceptar el retorno del protocolo de enlace en una IP falsa) si hace las cosas correctamente. Las solicitudes HTTP se realizan a través de TCP; hasta que se complete el protocolo de enlace, el servidor web no comienza a procesar la solicitud HTTP. Por supuesto, un usuario aleatorio podría intentar falsificar el final de un apretón de manos; pero como tienen que adivinar el ACK generado por el servidor, solo deberían tener una posibilidad de 1 en 2 ^ 32 (~ 4 billones) de hacerlo con éxito cada vez.

Como comentó Ladadadada, asegúrese de que no está recogiendo el valor incorrecto de la dirección IP remota en su aplicación web. Desea la dirección IP de encabezado del datagrama IP (específicamente, la dirección IP de origen). No desea valores como X-Forwarded-For / X-Real-IP que se pueden falsificar de forma trivial como se establecen en el encabezado HTTP. Definitivamente pruebe probando algunas direcciones IP; digamos un complemento del navegador o manualmente con telnet yourserver.com 80 .

El propósito de estos campos es que los proxies web (que pueden decir contenido de caché para servirlo más rápido) puedan comunicar a los servidores web la dirección IP real del usuario en lugar de la dirección IP proxies (que puede ser para cientos de usuarios). Sin embargo, dado que cualquiera puede configurar este campo, no se debe confiar.

  

¿Puedo confiar en la IP de origen de una solicitud HTTP?

Puede estar razonablemente seguro de que la dirección IP de origen de una solicitud HTTP es la dirección de origen de la conexión TCP que generó la solicitud.

Cuando confiar en una dirección IP es una pregunta complicada, específica del contexto, pero en realidad no es lo que estás preguntando.

  

    

¿Le preocupa el impacto de usar / implementar los límites de velocidad por IP en la capa de aplicación y cualquier vulnerabilidad adicional a los ataques de denegación de servicio?

  

     

Me pregunto si al hacer eso, en la capa de la aplicación, se introducen vulnerabilidades adicionales, sí.

Depende completamente de su implementación, tanto de la política como de la tecnología.

• ¿De qué tipo de recurso desea calificar el consumo límite?
• ¿Qué desea lograr al crear este límite de tasa?
• ¿En qué período de tiempo desea realizar la contabilidad?
• ¿Dónde desea aplicar el límite?
• ¿Es la dirección IP la mejor clave para el límite de velocidad?
• ¿Cuáles son las posibles razones para el consumo excesivo?
• ¿Cuál debería ser la experiencia del usuario en caso de consumo excesivo?

Dependiendo de las respuestas a estas preguntas, el límite de tasa puede ubicarse mejor en otra parte de la infraestructura del servicio, por ejemplo. firewall dedicado, firewall local. O si se autentica el acceso, entonces la credencial autenticada puede ser una mejor clave para la contabilidad de tasas y se definirán sus límites.

¿Cuál sería el punto de emitir SYN falsificado a un servidor HTTP si no tiene la intención de continuar el protocolo de enlace TCP? Su servidor web no verá la solicitud HTTP a menos que el cliente (posiblemente falso) obtenga el SYN / ACK, continúe estableciendo la sesión TCP y envíe una solicitud HTTP.

Almacene la base de datos en el disco, organícela inteligentemente (como un árbol) para búsquedas rápidas.

Si el cliente es falso o no, ¿realmente eso hace una diferencia para usted? Si se portan mal, se portan mal, no importa si son falsos o no.

Desde el punto de vista de un servidor web, consideraría que la IP remota es la verdadera IP remota.