Uno de los beneficios de ser un especialista en seguridad es trabajar con numerosos equipos. Después de una auditoría, los especialistas en seguridad tendrán la oportunidad de trabajar con administradores y analistas de bases de datos. Para que una aplicación funcione de manera adecuada y segura, estos equipos intentan lidiar con las vulnerabilidades de seguridad que tienen una base común. Los diálogos entre estos equipos plantean algunos problemas con la propiedad intelectual real.
Conceptos de proxy e IP real
Las aplicaciones web actuales se ejecutan en múltiples servidores de aplicaciones y sistemas de bases de datos. Imagine dos servidores de aplicaciones compartiendo el mismo código fuente. Las solicitudes del usuario están listas para ser satisfechas por cualquiera de estos servidores dependiendo de la situación de carga. El mecanismo de equilibrio de carga, que maneja las solicitudes HTTP frente a los servidores de aplicaciones, decide qué solicitud reenviar a qué servidor de aplicaciones. Esto plantea una gran pregunta para los administradores de sistemas de middleware y los desarrolladores de software: ¿cuál es la dirección IP real del usuario?
Los proxies se encargan de transmitir datos entre dos sistemas. El balanceador de carga es el mecanismo a cargo del proxy. En otras palabras, un solo sistema se comunica tanto con el usuario como con el servidor de aplicaciones. En términos de tráfico de red, los servidores web A o web B siempre se comunican con la dirección IP del balanceador de carga. Lo mismo puede decirse de los usuarios. Para los profesionales de la seguridad, los balanceadores de carga causan serios problemas en los ataques de inyección SQL basados en el tiempo. Pero el el enfoque principal aquí es la suplantación de IP.
X-reenviado-para y relación de IP
Considere la relación entre X-Forwarded-For, desarrollador y middleware. Por ejemplo, supongamos que la tarea del desarrollador de una aplicación es registrar todas las actividades, como los intentos de contraseña incorrectos por parte de los usuarios, con sus direcciones IP. Al principio, el desarrollador determinará la dirección IP del usuario cuando se cumpla la solicitud HTTP con el oportunidad que le brinda el lenguaje de programación que utiliza y tratará de seguir utilizando estos datos en el solicitud.
Dado que su dirección IP será fija durante todo el proceso de desarrollo, siempre verá la misma dirección durante las pruebas porque, en general, las computadoras de los usuarios en las redes corporativas funcionan con IP estática sobre la dirección MAC. La unidad realizará algunas pruebas de aceptación; sin embargo, habrá problemas con estos. La unidad de prueba enviará este problema al desarrollador de software.
En esta etapa, el desarrollador puede escribir un controlador en el entorno de desarrollo y ver la solicitud HTTP transmitida a la aplicación sin procesar, ya que todos tienen la misma dirección IP. Esto dará como resultado trabajar con X-Forwarded-For.
información del encabezado llamado X-Forwarded-For se enviará al servidor de aplicaciones. En esta etapa, el desarrollador de software verá su dirección IP, que controla con ipconfig, no el balanceador de carga que ve en los registros. Muchos programadores piensan que pueden resolver este problema con un bloque de código como este:
funciónobtener dirección IP() {
$ipKeys = formación(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_REENVIADO',
'REMOTE_ADDR'
);
para cada ($ipKeys como $clave) {
si (array_key_exists($clave, $_SERVIDOR) verdadero) {
para cada (explotar(',', $_SERVIDOR[$clave]) como $ip) {
$ip = recortar($ip);
si (validar_ip($ip)) {
devolver $ip;
}
}
}
}
devolverEstá establecido($_SERVIDOR['REMOTE_ADDR'])? $_SERVIDOR['REMOTE_ADDR']: FALSO;
}
Esto no será suficiente: el desarrollador debe verificar si el valor entrante es una dirección IP válida.
Todo lo anterior pertenecía a la parte manejada por el desarrollador. Pero para que una aplicación funcione correctamente y de forma segura, los equipos, trabajando juntos en teoría, pero en realidad, en puntos extremos entre sí, trate de lidiar con las vulnerabilidades de seguridad que tienen un base común. Ahora intente ver el problema desde la perspectiva de la persona responsable de la configuración del balanceador de carga.
Los administradores del sistema pueden pensar que los desarrolladores registran información como X-Forwarded-For porque no se puede confiar en los datos de la solicitud HTTP. Esos administradores a menudo transmiten X-Forwarded-For; sin embargo, también transmiten la dirección de origen TCP del sistema que envió la solicitud como un segundo valor de encabezado. La estructura True-Client-IP es un buen ejemplo de esto.
Cuando junta todas estas cosas, dos unidades diferentes siguen caminos diferentes para el mismo problema, conocido como suplantación de IP del cliente. El resultado es un problema crítico en el que no funcionará el registro de IP ni la autorización basada en IP.
¿Cómo se detecta la suplantación de IP del cliente en las pruebas de penetración?
La mayoría de los probadores de penetración usan Firefox para sus controles de seguridad. Configuran Firefox con un complemento simple, X-Forwarded-For: 127.0.0.1 para todas las solicitudes HTTP. Y así, aumenta la posibilidad de detectar tales vulnerabilidades en todas las pruebas de penetración. Realización de una auditoría de acuerdo con el Lista de verificación de OWASP se asegura de que verifique tales vulnerabilidades. Sin embargo, para detectar la vulnerabilidad X-Forwarded-For, necesita un módulo en la aplicación que muestre su dirección IP o las acciones realizadas.
Cómo resolver la vulnerabilidad X-Forwarded-For
Las organizaciones necesitan un documento obligatorio de desarrollo de aplicaciones seguras para todos los equipos de software y empresas de subcontratación. Por ejemplo, si necesita una dirección IP de usuario, la empresa debe planificar con anticipación y establecer una regla sobre la información del encabezado que utilizará aquí. De lo contrario, diferentes equipos producirán diferentes soluciones. Si tal situación no se puede abordar, las aplicaciones de subcontratación entrarán en juego, lo que dificultará la medición de los códigos fuente. En general, las empresas no quieren seguir ese camino.
Pero para resolver este problema, puedes usar la siguiente regla F5:
cuando HTTP_REQUEST {
HTTP:: encabezado eliminar X-Forwarded-Para
HTTP:: inserción de encabezado X-reenviado-Para [IP:: dirección_remota]
}
Esto elimina el campo X-Forwarded-For en la solicitud HTTP del mundo exterior. Luego transmite la solicitud agregando la dirección IP del sistema que le envió la solicitud. De esa forma, se crea una lista confiable para el software que actúa de acuerdo con X-Forwarded-For.
Para resumir, el principal objetivo aquí es realizar algunas comprobaciones en las solicitudes HTTP y crear un entorno fiable. El bloque de código anterior es un buen ejemplo que puede usar para esto.
Marcos de ciberseguridad y documentación para empresas
Las unidades que parecen independientes entre sí son en realidad partes de un todo. Es por eso que todo tiene que funcionar sistemáticamente. Las reglas determinadas de antemano deben aplicarse entre cada unidad. Si no se adopta dicho sistema de trabajo, pueden ocurrir muchos problemas, como la vulnerabilidad X-Forwarded-For. Para esto, se debe considerar todo de antemano y se debe utilizar una documentación lo más completa posible.
Y cada unidad en este gran sistema necesita adoptar e implementar marcos de seguridad cibernética. Su punto de partida debe ser investigar y aprender la lógica de trabajo de estos marcos.
