Su caso de uso no es, en el contexto, diferente de volver a mostrar un formulario de una sola página que el usuario no completó correctamente, y por conveniencia su código de servidor rellenó los campos que el usuario llenó correctamente Vemos muchos ejemplos de este tipo en toda la web. La única diferencia es que utiliza dos páginas para un conjunto completo de datos de usuario requeridos (y opcionales) que está recopilando. También podría estar usando veinte de estos pasos, en realidad no importa desde la perspectiva de la seguridad (puede que también lo sean los usuarios, pero eso es un asunto diferente), siempre y cuando:
- Te has ocupado de TLS
- Usted trata todas las entradas de los usuarios, independientemente de la página de la que provengan, como un todo
- No expone innecesariamente contraseñas de texto sin cifrar en el caché del usuario final
Usted mencionó en los comentarios que esto será en HTTPS, por lo que se cuida el primero. Los otros dos también son completamente manejables:
El código del lado del servidor que verifica la entrada del usuario tendrá que escribirse de tal manera que se adapte a múltiples páginas de formulario de usuario, pero también verifique las restricciones de entrada de manera incremental, lo que significa que cada página nueva verificará toda la entrada de datos en las anteriores. , hasta la página en la que el usuario está actualmente. También solo acepta todos estos formularios separados en su totalidad, lo que significa que una falla en uno vuelve a mostrar esa etapa de entrada del usuario final en particular, elimina todos los datos del formulario subsiguiente y muestra información relevante error para esa página (o etapa, paso, como quieras nombrarla). La parte importante es que usted acepta todos los comentarios del usuario solo una vez que todos los datos se verifican de acuerdo con sus requisitos en todas las etapas de ingreso de formularios. Solo entonces puede escribir cualquier cosa en su base de datos de forma segura, es decir, se cumplieron todos los requisitos.
¿Por qué el envío de contraseñas de usuario final en texto sin formato no es un problema? Porque ya lo has enviado al menos una vez en la otra dirección: al servidor. Si no se supone que eso sea un problema, enviarlo de vuelta con el mismo TLS no debería también. No debería , porque aún tendrá que considerar que los datos se almacenen en caché al final del usuario mediante el navegador, como lo señaló @ThomasPornin. Sin embargo, esto se puede controlar con las etiquetas de encabezado de la memoria caché del navegador, ya sea como etiquetas HTML o en los encabezados de respuesta del servidor HTTP. No voy a entrar en detalles sobre cómo lograrlo, ya que es un tema bien cubierto y también tiene muchos hilos en StackOverflow. La principal conclusión es que si su front-end ya estaba abierto por alguna inyección XSS, nada impide que esta inyección recopile datos del usuario final en el formulario enviado desde ese mismo campo de entrada, por lo que devolverlo no lo expone. más para estos tipos de ataques, pero aún se debe considerar la caché del cliente para evitar la exposición de contraseñas de texto sin cifrar a otros tipos de ataques.
Otros también han sugerido el uso de AJAX para partes de los datos de su formulario. Si bien es cierto que puede ayudar con las aportaciones del usuario, guiar a los usuarios sobre la marcha con retroalimentación, nunca debe aceptar solo datos parciales como algo en lo que confiar más adelante, al completar cualquiera de las dos etapas del envío del formulario o al completar El proceso en su conjunto. La verificación de la disponibilidad del nombre para mostrar, o similar, también está bien, pero si es en el tiempo que tarda otro usuario, seguramente no querrá confiar en la solicitud anterior de AJAX para decidir si el usuario actual aún puede usarla.