¿Cómo prevenir ataques contra las validaciones del lado del cliente?

Navega tus respuestas
4

Tengo un formulario de inicio de sesión donde estoy aceptando el número de teléfono móvil del usuario para iniciar sesión.

Cuando se envía el número de teléfono móvil, estoy llamando a un JavaScript para validar el número de teléfono móvil. Las validaciones de mi lado del cliente consisten en comprobaciones, como el número de móvil que comienza con 9, 8 o 7, es la longitud del número de móvil igual a 10, etc.

Una vez que se realizan este tipo de validaciones, verifico en el lado del Servidor si se ingresan las coincidencias de Número Móvil y Contraseña (Autenticación).

Ya que tengo algunos chequeos en JavaScript, uno puede ver la fuente y saber que este tipo de cheques están ahí. Y uno puede modificar este código y dejar que se refleje para todos los Usuarios. Por ejemplo, uno puede cambiar el código que verifica si el Número de móvil comienza con 9, 8 o 7 y reemplaza 9 con 1 (por ejemplo). Entonces, si uno ingresa el Número que comienza con 9, fallará.

  1. ¿Cómo prevenir este tipo de ataques? La forma obvia es poner estas comprobaciones en el lado del servidor, pero tengo al menos 10 comprobaciones diferentes y no quiero sobrecargar las comprobaciones del servidor.

  2. ¿Cómo puede un atacante cambiar esos valores en mi JavaScript y dejar que se refleje para todos los usuarios?

EDIT : el código de JavaScript del lado de mi cliente se ve a continuación, 

var checkMobileNumber = form.mobileNumber.value;
if (checkMobileNumber.charAt(0) != 9 && checkMobileNumber.charAt(0) != 8 && checkMobileNumber.charAt(0) != 7) {
  //Throw some error
}
    
pregunta Vikas V 21.02.2013 - 06:18
fuente

4 respuestas

10

Es probable que realizar 10 comprobaciones en el lado del servidor no suponga ningún problema para su servidor. A menos que esté en el punto de miles de solicitudes por segundo, estará bien. En ese momento, probablemente implementaría la agrupación en clúster, etc. La seguridad siempre vale la pena por los ciclos adicionales. La validación del lado del cliente nunca es suficiente. Cuando piense en la validación, debe pensar en filtrar RAW HTTP sin tener en cuenta el hecho de que el "navegador" puede haber generado el contenido.

Incluso si hay una validación del lado del cliente, todavía hay Ataques de hombre en el medio , donde pueden cambiar el contenido de la solicitud HTTP sin formato después de que se haya realizado la validación. La validación del lado del cliente es realmente para la conveniencia del usuario final, por lo que no se envía, aparece un mensaje de error y se debe volver a enviar. No consideraría la validación del lado del cliente en una aplicación basada en navegador para proporcionar seguridad para el procesamiento que se realiza en el servidor.

En cuanto a cómo un ataque puede modificar su validación, dependerá de muchas cosas. Por ejemplo, ¿cuáles son los valores dinámicos en la página? ¿Toma parámetros de las cadenas de consulta (parámetros GET) sin filtrar? Esto podría provocar ataques XSS o CSRF porque pueden cambiar esos valores y su aplicación los procesará. Por supuesto, puede protegerse contra esto con técnicas de escape adecuadas y otras técnicas. El ataque también puede haber cargado algún tipo de script o proxy de usuario que puede inyectar código en la página.

Dado que está utilizando "reflejado", es posible que desee leer más específicamente sobre un "XSS reflejado", que es solo un tipo de vector de ataque. De OWASP :

  

Los ataques reflejados son aquellos en los que el código inyectado se refleja.   El servidor web, como en un mensaje de error, resultado de búsqueda o cualquier otro   otra respuesta que incluye algunas o todas las entradas enviadas a la   Servidor como parte de la solicitud. Los ataques reflejados se entregan a   víctimas a través de otra ruta, como en un mensaje de correo electrónico, o en alguna   otro servidor web Cuando un usuario es engañado para hacer clic en un malicioso   enlace o envío de un formulario especialmente diseñado, el código inyectado viaja   al servidor web vulnerable, que refleja el ataque de vuelta a la   navegador del usuario. El navegador ejecuta el código porque viene   desde un servidor "confiable".

    
respondido por el Eric G 21.02.2013 - 06:26
fuente
2

ya sabes qué hacer, el problema es que tienes más cosas que validar. La respuesta simple es si quiere cosas seguras, haga todas las validaciones en el lado del servidor. Lo que haya hecho por las cosas del lado del cliente, los piratas informáticos pueden verlos y cambiar.

(no te olvides de los ataques mitm. La validación del lado del cliente no va a ayudar)

    
respondido por el user827918 21.02.2013 - 06:33
fuente
2

Tienes CERO control sobre lo que un usuario envía al servidor. Un concepto de seguridad fundamental nunca es confiar en el usuario, y esto se aplica en casos como estos. Use las protecciones del lado del cliente para evitar solicitudes mal formadas accidentales (errores de persona) y por razones de conveniencia. Tratar de endurecer estos controles para que se vuelvan "seguros" es fundamentalmente defectuoso.

Asegúrese de que todas las validaciones de seguridad se realicen en el lado del servidor, independientemente de la carga que a su vez coloque en su servidor, desafortunadamente no tiene otra opción.

    
respondido por el Peleus 21.02.2013 - 09:13
fuente
0

Bueno, si no quiere poner carga en el servidor, su "seguridad" está rota. Puede poner la seguridad que desee en el lado del cliente, un cliente inteligente siempre podrá enviar lo que quiera a su servidor. Su servidor no debe confiar en la entrada del cliente. No debe suponer que las cosas que recibe su servidor provienen del software que ha colocado en el lado del cliente. Este puede ser el caso nominal y el único caso que haya imaginado, pero un usuario experto puede enviar el contenido que quiera a su servidor. Puede modificar el software del lado del cliente, puede evitarlo ...

La carga del servidor no es una preocupación, de lo contrario, realmente tendrá que comprar un mejor hardware. Y la carga del servidor se puede minimizar.

Los

marcos de aplicaciones web agradables, como Vaadin , le permiten desarrollar la validación una vez y hacer que se ejecute en ambos lugares, en el cliente y en el servidor. Así que tienes estas ventajas:

  • La validación del lado del servidor es la validación segura.
  • La validación del lado del cliente es la validación reactiva, el usuario no tiene que esperar un viaje de ida y vuelta del servidor para recibir la retroalimentación de validación.
  • La mayoría de las veces, el servidor recibe una entrada de usuario válida, porque la mayoría de los usuarios han pasado primero la validación del lado del cliente. No hay viajes de ida y vuelta cliente / servidor por los errores usuales del usuario. Por lo tanto, se minimiza la carga del servidor, se minimiza la carga de la red, esto es bueno para ahorrar energía, es bueno para su factura de electricidad, esto es bueno para el planeta .

Y puedes ahorrar más haciendo menos. ¿Son todas sus limitaciones en el número de teléfono realmente buenas ideas? ¿Qué pasará si un usuario tiene un número de teléfono de un país en el que no pensó? ¿Sabes que las personas pueden llevar su teléfono móvil más allá de las fronteras? ¿Qué pasará si un usuario escribe su número de teléfono con espacios? Estos casos darán mala experiencia al usuario. ¿Existen realmente buenas razones para prohibir estos casos? ¿O sus limitaciones serán simplemente molestias que harán más daño que bien?

    
respondido por el Nicolas Barbulesco 23.02.2013 - 12:10
fuente

Lea otras preguntas en las etiquetas

Asegurar que un servicio web solo procese solicitudes de computadoras específicas Datos estadísticos sobre el rendimiento de varios algoritmos de cifrado