Mejores prácticas para asegurar la carga útil de la solicitud entre el cliente / servidor durante el nodo de transmisión posterior a la solicitud / express js

j_unknown

Partiendo de un tema amplio, tengo una pregunta específica (tal vez un poco de 'sombrero de papel de aluminio').

Esta pregunta se refiere a las mejores prácticas para proteger los datos transmitidos en una solicitud posterior entre el cliente y el servidor. El fondo es una aplicación web que estoy desarrollando para aprender más sobre node y express js.

Aunque el ejemplo que estoy usando es para las credenciales de inicio de sesión, realmente podría tratarse de cualquier información que se transmita en una solicitud posterior desde un formulario enviado a un servidor expreso.

ejemplo: el cliente envía los datos del formulario a través de un evento de clic de botón en el cliente. Estoy usando vue para la interfaz, pero esta es una pregunta genérica. En la página del cliente también estoy usando (dentro de una función asincrónica):

const resp = await axios.post("http://someurl.com/login", {client:email, pw:pw});

en las herramientas de desarrollo de Chrome en la pestaña de red, puedo ver la carga útil de la solicitud. En el ejemplo se ve así:

{client:"some email address", pw:"some password"}

¿Sería mejor transmitir la carga útil ya cifrada / codificada? Entonces, ¿lo ha descifrado / descifrado en el servidor? Para transmitir información sensible, ¿es mejor utilizar una cookie firmada?

El plan, si alguna vez supere todo esto, es usar Let'sEncrypt para HTTPS.

¿Es razonable confiar solo en HTTPS para proteger este tipo de carga útil?

Como referencia, en el servidor express, la contraseña se hash y se compara con una versión hash de una base de datos. He leído sobre Helmet y csurf y tengo la intención de usarlos también en el producto final. Hay mucha información excelente en esta respuesta. Lo cual es increíblemente asombroso y habla de la importancia de HTTPS sobre HTTP.

Se agradece cualquier referencia / pensamiento / consideración práctica adicional.

Kristian Sigston

El uso de HTTPS cifrará su carga útil entre su cliente y el servidor. Cualquier manejo de javascript en el front-end puede ser eludido por usuarios con suficiente conocimiento para que todo el frontend esté ahí principalmente para facilitar una mejor experiencia de usuario. Verificación de confirmación de contraseña, campos correctos completados, etc.

Su principal fuente de seguridad será su eventual certificado LetsEncrypt HTTPS y su hash y salazón aplicados en el servidor. Como supuso correctamente, HTTP envía contraseñas en texto claro, lo cual es incorrecto. Como advertencia, incluso HTTPS puede ser derrotado si alguien lo quiere lo suficiente con una serie de técnicas para aumentar las autoridades de certificación (creo que las CA raíz deberían estar fuera de línea de todos modos) o modificar los certificados de confianza en la PC de un usuario.

Aunque depende de la cantidad de esfuerzo requerido por el pirata informático frente al retorno potencial, por lo tanto, cuanto más intente proteger, mayor será la seguridad requerida antes de que no valga la pena el esfuerzo de cualquier pirata informático potencial para intentar eludir la seguridad de un sitio en particular. . (Hacks de reputación aparte, por supuesto)

Espero que esto ayude.

Este artículo se recopila de Internet, indique la fuente cuando se vuelva a imprimir.

En caso de infracción, por favor [email protected] Eliminar

Editado en
0

Déjame decir algunas palabras

0Comentarios
Iniciar sesiónRevisión de participación posterior

Artículos relacionados

TOP Lista

CalienteEtiquetas

Archivo