Con los complementos de navegador web como Firebug, es fácil manipular el código fuente del lenguaje del lado del cliente como HTML y JS. Entonces, ¿esos idiomas son más vulnerables que los del lado del servidor?
Cuando uno está creando seguridad para su sitio, ¿es JS solo totalmente inútil?
Este es un problema de quién controla el código. Dejemos de lado que hay algunos marcos modernos como node para JavaScript en el lado del servidor.
Los lenguajes en sí mismos no son necesariamente más vulnerables. La mayoría de las fallas no son resultados del lenguaje subyacente, sino de varias comprobaciones lógicas, sensibilización de entrada, etc.
Dicho esto, no puede controlar el código del lado del cliente, lo que significa que el usuario local puede modificarlo. También puede ser modificado por un ataque de hombre en el medio en la red o por un ataque de hombre en el navegador donde el atacante ha comprometido la máquina / navegador local.
En el lado del servidor, tendrían que irrumpir en su servidor para modificar el código. Sin embargo, eso no significa que el código sea necesariamente más seguro.
Si bien puede modificar el JavaScript a través de su inspector de código localmente, si hiciera algo malicioso, se lo haría a usted mismo. Solo porque cambies el código no significa que afectará a otros usuarios. Sin embargo, puede crear ataques contra la solicitud de página que luego envíe a otra persona, lo que resultará en XSS o CSRF. Esto daría lugar a un ataque contra el usuario. Al mismo tiempo, puede cambiar la solicitud para que las solicitudes o datos maliciosos se envíen al servidor y se produzca un desbordamiento del búfer o una inyección de código (por ejemplo, inyección de SQL).
Una de las diferencias es que puede crear un ataque más fácilmente si tiene acceso al código. Ya que puede ver la fuente del HTML y JavaScript, puede ser más fácil crear un exploit, pero ese mismo conocimiento podría llevar a crear una inyección SQL.
Ahora, hasta tu último punto. Debe asegurarse de que todas sus comprobaciones de seguridad se realicen en el lado del servidor porque no puede confiar en la validación del lado del cliente, ya que solo afecta lo que está ocurriendo en el navegador. Un atacante localmente o MiTM aún puede cambiar el tráfico HTTP sin procesar, lo que resultaría en que la validación del lado del cliente sea efectivamente ignorada. La validación del lado del cliente es una conveniencia para sus usuarios y para ahorrar algunos ciclos en su servidor.
No son los idiomas en sí los que son fundamentalmente inseguros, es el mal uso de ellos lo que puede ser.
Realizar una validación de entrada solo con un idioma del lado del cliente es una mala idea, ya que cualquiera puede simplemente desactivar JavaScript o enviar manualmente solicitudes al servidor que contengan valores arbitrarios. Por ejemplo, intentar evitar XSS bloqueando varios caracteres con JavaScript en el lado del cliente no impedirá que alguien envíe una solicitud a su servidor que contenga varios caracteres dudosos y marcado.
Sin embargo, la validación de JavaScript es útil desde la perspectiva de la experiencia del usuario, ya que ayuda a evitar que usuarios legítimos envíen accidentalmente el formulario con datos no válidos, lo que les permite corregirlo antes de continuar. Lo importante a recordar es que esto solo debe considerarse una conveniencia, en lugar de una medida de seguridad.
JavaScript y otros idiomas del lado del cliente también pueden ser algo útiles desde una perspectiva de seguridad cuando se utilizan conceptos como prueba de conocimiento cero , o al cifrar el contenido de usuarios confidenciales a los que los operadores de servidores no deberían tener acceso. Esto puede ser útil en situaciones en las que el proveedor de la aplicación podría verse obligado a divulgar datos a través de la autorización, ya que los datos que están cifrados en el lado del cliente con una clave conocida solo por el usuario son inútiles para la parte solicitante.
La diferencia clave a tener en cuenta es que cualquier persona puede cambiar el comportamiento de su propio cliente, por lo que cualquier cosa que le envíe el cliente debe ser tratada como no confiable y potencialmente maliciosa. Básicamente, te encuentras con el mismo problema que DRM: si le das algo a un usuario, es fundamental que lo alteren y lo usen de la forma que deseen, te guste o no.
Lea otras preguntas en las etiquetas web-browser client-side