¿Vulnerable código sugerido en OWASP?

Este código permite que un atacante que conoce el encabezado X-Forwarded-For: header de la víctima y el ID de sesión de la víctima para iniciar sesión como ese usuario. Si la víctima no tiene un encabezado X-Forwarded-For: , el atacante puede poner la dirección IP de la víctima en su encabezado y el código usará ese valor como su dirección IP legítima en lugar de su dirección IP real. Esta es la vulnerabilidad .

• En un escenario de rastreo de red, el atacante obtiene ambos valores al mismo tiempo, por lo que agregar este código no protege contra el rastreo de la red.

• En un escenario XSS, donde el atacante inyecta javascript para robar la cookie del usuario, esto generalmente se hace al hacer que el navegador de la víctima realice una solicitud a un servidor web controlado por el atacante con el valor de la cookie adjunto como GET parámetro. El encabezado X-Forwarded-For: de la víctima se proporcionará al atacante en esa solicitud.

Todavía no he podido pensar en ningún escenario en el que un atacante pudiera obtener una cookie de la víctima pero no pudiera obtener el valor de un encabezado X-Forwarded-For: legítimo o, si no hubiera un encabezado, la dirección IP de la víctima .

Entonces, la respuesta es sí , como está escrito, este código no hace nada para mejorar la seguridad. Debe confiar en la dirección IP directamente conectada solo .

Nota: si su servidor de aplicaciones web está detrás de un proxy web inverso (como nginx, Varnish, HAProxy, mod_proxy, Amazon ELB y muchos otros) que siempre agrega la dirección IP de conexión a un X-Forwarded-For header y realiza una nueva conexión a su servidor de aplicaciones web con su propia dirección IP, puede "confiar" en parte del valor de este encabezado.

Los módulos como mod_rpaf o mod_remoteip para Apache se pueden configurar con una lista de direcciones IP de proxy confiables y reemplazarán el valor de REMOTE_ADDR con la parte confiable del encabezado X-Forwarded-For para las conexiones provenientes de esos direcciones Este REMOTE_ADDR estará disponible en PHP como $_SERVER['REMOTE_ADDR] y se registrará en sus archivos de registro de Apache como la verdadera dirección IP de conexión.

Si no hace esto (o el equivalente si no está utilizando Apache), solo verá las conexiones de una dirección IP, su servidor proxy inverso y, por lo tanto, todas sus sesiones contendrán la misma dirección IP.

¡Diría que tienes razón! Parece que no han tenido en cuenta que el encabezado HTTP X-FORWARDED-FOR podría devolver '; DROP TABLE users;-- .

Lo sugieren para bloquear también las sesiones para las personas detrás de proxies y nombrar a Tor como ejemplo. Esto es algo estúpido; Tor nunca reenvía la IP original por razones obvias. Además, no debería (¿no debería?) Siquiera mirar el paquete en sí; simplemente lo reenvía hasta que está fuera de la red. ¿Cuál es el uso de un proxy si la IP original se reenvía de todos modos? Solo bloquéelo en la dirección remota, esa es la única apuesta segura. Incluso si tuviera que validar el encabezado for-x reenviado como una dirección IPv4 o IPv6 válida, es posible que aún contenga una IP arbitraria.

Debajo del código de ejemplo en esa página, piensan en direcciones IP locales e IPv6 (aunque los ejemplos de IPv6 contienen direcciones no válidas):

  

Tenga en cuenta que, en entornos locales, no se devuelve una IP válida y, por lo general, puede aparecer la cadena ::: 1 o ::: 127, por lo que puede adaptar su lógica de comprobación de IP.

Pero también deberían haber pensado que el encabezado puede contener datos arbitrarios. Buen hallazgo!

Ya que es un wiki, supongo que cualquiera con una cuenta podría editar la página. Si no es así, debe ponerse en contacto con ellos. Esta es una mala práctica, y muchas personas pueden incluso insertar $IP sin escapar en una base de datos. Por lo general, no es posible falsificar la variable ambiental REMOTE_ADDR, por lo que debería ser seguro en circunstancias normales (aunque no lo insertaría sin escapar incluso si ese fuera el caso), pero el encabezado X-forwarded-for lo rompe todo aquí.

Este código es un control de seguridad, y como tal, debe ser evaluado contra la amenaza que estaba destinado a controlar. En este caso, no se otorga ningún acceso especial según la dirección IP. En su lugar, la dirección IP se está utilizando como una restricción adicional en un mecanismo de autorización ya fuerte (cookies HTTP).

Es cierto que un atacante podría falsificar la IP de un usuario a través del encabezado X-Forwarded-For y omitir esta verificación adicional, pero eso significa que el atacante no solo debe conocer el ID de sesión del usuario (cookie), sino también el usuario. Dirección IP. Esto hace que la explotación de XSS con robo de sesión sea más difícil.

Considere las otras formas en que este control podría haber sido abordado. Primero, si el control no estuviera en su lugar, entonces cualquier ataque de robo de sesión (XSS, rastreo de tráfico, SSL MITM, etc.) resultaría en una sesión completamente utilizable para el atacante, sin trabajo adicional.

En cambio, si el control se implementara sin consultar el encabezado X-Forwarded-For, pero solo HTTP_REMOTE_ADDR, entonces un atacante que esté detrás del mismo proxy (en una escuela o empresa, por ejemplo) no necesitaría ningún conocimiento del control o la IP interna del usuario para tener una sesión completamente utilizable, ya que todas las sesiones HTTP salientes parecerían provenir de la misma IP (la del proxy).

Al agregar la verificación de X-Forwarded-For, el control requiere que un atacante tenga conocimiento de la dirección IP del usuario y la capacidad de falsificarlo en el encabezado X-Forwarded-For (no todos los atacantes están completamente restringidos, así que hay una reducción en el riesgo. No una eliminación del riesgo, ya que debemos asumir que hay algunos atacantes sin restricciones.)

Una forma de posiblemente reforzar este control sería mantener un poco de información adicional: la fuente de la última dirección IP que se usó. Por ejemplo, si la sesión se concedió por primera vez y se asoció con una IP que provenía de HTTP_REMOTE_ADDR, el control podría requerir que el tráfico futuro en esa sesión deba provenir de una IP obtenida de HTTP_REMOTE_ADDR, no de X-Forwarded-For. Esto elimina algunas posibilidades de falsificación. Las ventajas de implementar la verificación a la inversa (preferir X-Forwarded-For sobre HTTP_REMOTE_ADDR) probablemente no valgan la pena, ya que es mucho más difícil falsificar una dirección de red real que un encabezado HTTP.