Actualmente estamos trabajando en las correcciones de seguridad de OWASP e identificamos un escenario de ataque para el que estamos tratando de encontrar una posible solución:
- El usuario ingresa una solicitud HTTP válida a nuestra aplicación. La URL en el navegador del usuario está configurada para nuestra aplicación url, por ejemplo. %código%
-
Cualquiera de estos:
- A: El atacante intercepta la solicitud y la reenvía a un sitio malicioso en lugar de a nuestra aplicación. La URL en el navegador del usuario se establece en la URL de la aplicación, p. Ej.
https//www.abc.com/requestpero el contenido será el del sitio malicioso. - B: la aplicación procesa la solicitud y envía la respuesta a través de Apache. Mientras la respuesta está en ruta, un atacante intercepta la respuesta y reemplaza el contenido de la respuesta completa con algún sitio o mensaje malintencionado como "¡Estás hackeado!"
- A: El atacante intercepta la solicitud y la reenvía a un sitio malicioso en lugar de a nuestra aplicación. La URL en el navegador del usuario se establece en la URL de la aplicación, p. Ej.
- En cualquier caso, la respuesta se procesa en el navegador del usuario, con la URL aún apuntando a
https://www.abc.com/requesten el navegador pero el contenido es malicioso. Esto hace que el usuario crea que aún está en nuestra aplicación.
Podríamos replicar este escenario a través de nuestra herramienta proxy. Al ser https, puede ser que el atacante no pueda descifrar la respuesta, pero ciertamente puede cambiar el contenido de la respuesta o redirigir a algún sitio malicioso. ¿Hay alguna forma de identificar y evitar la representación de dichas respuestas en el navegador a través de Apache o encabezados HTTP personalizados?
¿Qué sucede si en el escenario (2A), el usuario se enruta desde un sitio HTTPS válido a un sitio HTTP malicioso?