¿Cuál es una respuesta típica del servidor web para la solicitud POST?

La pregunta pareció lidiar con el método de respuesta HTTP elegido, y su impacto en el almacenamiento en caché. Consulte "POST Caching" a continuación para obtener la respuesta a esa pregunta.

Las aclaraciones hechas por el OP en los comentarios sugieren que el equipo de seguridad está preocupado por el hecho de que el navegador recuerde los valores ingresados en los formularios de campo, de modo que estén disponibles para el uso "atrás" o "autocompletar". Eso no tiene ninguna relación con la respuesta HTTP que el servidor decide emitir; incluso si se usa una redirección, eso solo aumenta el número de clics de "retroceso" necesarios para volver a la información.

El atributo de autocompletado de formularios HTML y atributo de autocompletado de entrada HTML se utilizan para solicitar que el navegador no recuerde los valores ingresados. Sin embargo, estas son peticiones, no prohibiciones. Los navegadores pueden hacer lo que quieran, y se sabe que ignoran o malinterpretan estas etiquetas y eximen a los que les parezcan interesantes. Chrome, por ejemplo, ha tenido esta cosa donde "off" no funciona pero "false" sí .

Entonces, hay cosas que puedes hacer para ayudarlo, pero no para controlarlo. Y un 302 en lugar de un 200 no es uno de ellos.

POST Caching

Un POST con una respuesta 200 no se almacenará en caché a menos que los encabezados HTTP adicionales en la respuesta lo soliciten específicamente. Consulte ¿Es posible almacenar en caché los métodos POST en HTTP? de StackOverflow; para citar su cotización de RFC 2616 :

  

9.5 POST

     

...

     

Las respuestas a este método no son cacheables, a menos que la respuesta   incluye los campos de encabezado Cache-Control o Expires apropiados. Sin embargo,   La respuesta 303 (ver Otro) puede usarse para dirigir al agente de usuario a   recuperar un recurso almacenable en caché.

Su equipo de seguridad tuvo un buen pensamiento, pero no pudo preguntar si los arquitectos de HTTP lograron tener el mismo buen pensamiento primero.

En términos prácticos, esto es por qué su navegador le pregunta cuándo intenta volver a cargar una página que fue la respuesta a un envío de formulario POST - le dice que la solicitud se volverá a enviar al servidor, porque el navegador no almacenó en caché la respuesta original.

He oído hablar del problema y sí, esto es algo que se puede observar en muchas aplicaciones web utilizando la extensión del encabezado HTTP en vivo. De hecho, devuelven 302 en lugar de 200 como código de estado. Sin embargo, también hay otros controles que deben usarse en combinación, los encabezados de control de caché HTTP .

Respecto a SSL; Tiene razón cuando se refiere al punto de que no hay ningún riesgo adicional al observar las credenciales en tránsito. El problema que resuelve esta solución se encuentra en una etapa anterior: el propio navegador. Hubo un momento en el que podía cerrar sesión en una aplicación web y pulsar el botón de retorno para volver a iniciar sesión. Esto incluso funcionó, si la aplicación web destruyó la sesión, porque la memoria caché del navegador contenía las credenciales de autenticación y se volvió a autenticar. Por lo tanto, el problema que esto resuelve es que ninguno que use el navegador puede autenticarse con credenciales previamente usadas y en caché.

Una redirección a un sitio diferente no hace que el navegador olvide los datos ingresados en el formulario. Si regresa a la historia, entonces todavía se pueden volver a enviar. Tratar de "borrar" el navegador de los datos confidenciales es probablemente cuestionable de todos modos, ya que el atacante tendría que estar dentro del navegador para acceder a estos datos y en este caso (s) podría haber capturado los datos cuando se ingresaron en la página o enviado al servidor, lo que probablemente requiera menos esfuerzo.

Tengo entendido que el hallazgo informado por el equipo de seguridad es válido. Veamos el escenario que probablemente informaron, ya que yo también lo he visto en las evaluaciones de aplicaciones manuales.

Escenario 1: Tomemos, por ejemplo, la página de inicio de sesión de una aplicación o, mejor aún, un formulario de solicitud de tarjeta de crédito. Después de completar todos los campos del formulario y hacer clic en el botón 'Enviar', el cliente envía los datos confidenciales en una solicitud POST al servidor. Si la respuesta del servidor es "200 OK", el navegador mantendrá los datos POST en la memoria del navegador, lo que permitirá ataques de repetición. Como se indicó en una respuesta anterior, uno podría presionar el botón "atrás", luego "Reenviar" y luego "Actualizar" en el que el navegador reenviará los datos confidenciales de la POST nuevamente. A menudo recibirá un mensaje emergente de su navegador que le informará que está a punto de reenviar los datos enviados previamente.

Escenario 2: Los mismos datos se envían a través de una solicitud POST al servidor. Esta vez, el servidor responde con un código de estado de 300, probablemente un redireccionamiento 302 que envía al cliente a la página siguiente. Sin embargo, el navegador del cliente que recibió una respuesta de tipo 300 NO mantiene ni almacena en caché los datos de POST en la memoria del navegador. NO SE PUEDE repetir el experimento de retroceder, adelantar, actualizar y esperar ver los datos de POST publicados anteriormente. Todo esto depende de la respuesta del servidor.

Puede probarlo usted mismo si tiene acceso a un proxy local como Burp. Configure el navegador para que apunte a su proxy. Accede a la página web vulnerable. Rellene los campos, haga clic en enviar y observe la solicitud que se envió en su herramienta de proxy. Debería ver los diversos campos de formulario que contienen datos confidenciales en la sección de datos de la solicitud POST. Suponiendo que la respuesta del servidor fue un '200 OK', pase al siguiente paso. En el navegador, presione el botón Atrás, luego avance y luego actualice. Debería recibir el mensaje emergente de su navegador para avisarle que está a punto de reenviar los datos enviados previamente. Pulsa OK. Ahora mira esa última solicitud en tu herramienta proxy. Se reenviará la solicitud POST y los mismos datos confidenciales anteriores. AHORA, intente este mismo experimento en un sitio web que devuelve 302 redireccionamientos a datos de POST. NO podrá hacer que el navegador reproduzca los datos publicados.

Entonces, ¿cuál es el riesgo o la amenaza que puede plantear? En primer lugar están los ataques de repetición. Su mayor preocupación debe ser el malware. Tu segundo vector de amenaza más grande sería un dispositivo compartido. La preocupación es que el malware o una persona con acceso al dispositivo podrían "reproducir" la solicitud y luego ver los datos confidenciales que se enviaron en la solicitud POST. El malware solo leerá los datos directamente de la memoria del navegador. Una persona tendría que usar una herramienta para ver la solicitud POST nuevamente.

*** Algunas advertencias:

* El uso de Autocompletar = desactivado solo evita que los datos se almacenen en contenedores de almacenamiento de campos de formulario. Es independiente y no tiene relación con este tema. Sin embargo, sugeriría que se asegure de que cualquier campo de formulario que acepte información confidencial debe tener autocompletado configurado en "desactivado". El malware con frecuencia busca y lee datos de campos de formularios guardados, ya que generalmente contiene información jugosa.

** El uso de encabezados de control de caché tampoco tiene relación con este problema, ya que es para las páginas que se almacenan en caché en el disco (directorios temporales de Internet). Una vez más, debe utilizar las directivas de control de caché y evitar que los datos confidenciales se almacenen en texto sin cifrar en su sistema.

*** '200 OK' en los datos POST 'en una solicitud json no es un problema. Es casi el único escenario en el que puedo pensar que no se puede realizar el ataque de repetición cuando el servidor responde con un '200 OK'.

Espero que esto ayude. Estoy seguro de que no está listado como una vulnerabilidad de alta calificación debido a las limitaciones del vector de ataque. ¡Es solo 1 de innumerables capas en la cebolla de seguridad!

Como han indicado otras respuestas, responder a un POST con una redirección no hará nada para evitar que el contenido del formulario sea recordado. Sin embargo, resuelve un problema diferente: si el servidor responde con un "OK" de 200, el usuario hace clic en un enlace en la página y luego hace clic en el botón Atrás, el navegador puede volver a enviar todo el formulario. Si el servidor respondió a la POST con una redirección, esto no ocurrirá (el navegador volverá a cargar la página a la que fue redirigido).