Mientras leía ASVS 3.0.1, encontré el requisito V5.18:
Verifique que la validación del lado del cliente se use como una segunda línea de defensa, además de la validación del lado del servidor.
Umm ... ¿no se dice que la validación del lado del cliente no tiene ningún beneficio de seguridad?
Quiero decir, como una función de conveniencia para alertar a los usuarios de una entrada no deseada, sí, ¿pero como un requisito de seguridad? ¿Me he perdido algo?
Bien, entonces, las respuestas a mi pregunta en la lista de correo de ASVS arrojan algo de luz sobre el problema. Personalmente, considero que los dos siguientes son los argumentos más sólidos:
Aunque la validación del lado del cliente se puede omitir, ayuda a detectar ataques. Supongamos, por ejemplo, que hay un campo de entrada que tiene una longitud limitada a 10 dígitos. Si se supone que esto debe ser validado por el cliente y la aplicación recibe algo más largo o una cadena que no contiene dígitos, entonces está (en un sentido confuso) claro que algo está sucediendo.
Las aplicaciones con una gran cantidad de JavaScript que modifica el DOM donde el servidor en realidad nunca ve algo de la entrada, requieren esto. Solo entonces me di cuenta de que ASVS carece de una sección dedicada a las pruebas del lado del cliente (como lo ha hecho la Guía de pruebas).
Sí, la validación del lado del cliente se puede omitir de forma trivial. Aún así, está agregando algo de seguridad y minimizando el riesgo total, aunque sea por una cantidad muy pequeña.
Ser capaz de alertar (1) directamente desde mi navegador, en lugar de usar un proxy / extensión ES una ventaja para el atacante.
Este es un ejemplo: piense en un thin client interno bloqueado y endurecido, donde lo único que puede usar es un navegador (no puede deshabilitar javascript). Si no hay una validación del lado del cliente, puedo explotar ese SQLi que reside en la base de datos de producción manualmente.
Lea otras preguntas en las etiquetas client-side validation asvs