Javascript y 2 prácticas de (in)seguridad fáciles de evitar
Javascript es amor. Javascript NO es JAVA. Javascript no es pariente de JAVA. Javascript se llama así porque cuando estaba dando sus primeros pasos JAVA era el lenguaje de moda, todo esto por allá por 1995, en definitiva todo una cuestión de marketing.
En éste post quería resaltar 2 errores que veo comúnmente, el primero es hacer validaciones del lado del cliente de datos que no deberían ser visibles por un tercero, y el segundo esta relacionado con el acceso al sistema y la carga de librerías que no son estrictamente necesarias, recuerden que el código Javascript puede ser leído fácilmente por el usuario.
No expondrás tu validación al cliente
Ojo, se puede validar, por ejemplo, que el campo para el nombre solo contenga letras, espacios y guiones, ése tipo de validaciones están bien. El problema es cuando se valida un código el cual se obtiene a través de una función que toma datos conocidos por el cliente. La realidad es que esto es malo y no se debe hacer, pero si lo van a hacer, por lo menos no incluyan también el script de validación del lado del cliente.
Ejemplo. El sitio web de un municipio pide el DNI del dueño de una casa, la dirección de ésta y un código de validación para acceder a más datos sobre la misma, datos que solo deberían ser accesibles por el dueño. El código de validación se calcula a través del DNI y la dirección. La función realiza algunas modificaciones al DNI y la dirección y luego algunas cuentas mágicas y devuelve un código, que es el código de validación.
La práctica anterior es cuestionable, no deberían utilizarla si de verdad se preocupan por la confidencialidad de los datos, pero si la utilizan lo peor que pueden hacer es calcular el código de validación del lado del cliente utilizando Javascript, no, por favor, no. Y ojo, Javascript no tiene la culpa.
Incluir Javascript antes de autenticar al usuario
Este error ocurre a menudo, pasa mas o menos así.
- Un usuario intenta acceder a una función que requiere que éste esté logueado.
- El sistema muestra la pantalla de logueo.
- El sistema ya cargó los scripts del área “protegida”.
Esto no siempre está mal, el problema surge cuando los scripts exponen información sobre funciones internas del sistema, por ejemplo, llamadas AJAX a ciertos puntos de la aplicación. El peor escenario ocurre cuando esas URLs no verifican que el usuario esté autenticado y tenga la autorización correspondiente para ejecutar la acción.
Ojo, no está mal cargar librerías/scripts genéricos, como por ejemplo jQuery, pero de todos modos siempre intenten solo incluir lo justo y necesario para que el sitio permita realizar las acciones que corresponden. Y siempre verifiquen que el usuario esté autenticado y autorizado (que tiene el rol adecuado) para ejecutar una acción.
Relacionado con este ultimo punto, también se debe deshabilitar el listado de directorios en el servidor, ya que de nada sirve no incluir los archivos si alguien pueden navegar la estructura de archivos para llegar a ellos.
Conclusión
Si están dando sus primeros pasos en el desarrollo de aplicaciones, o si es la primera vez que van a hacer una aplicación que maneja datos sensibles, o si simplemente les interesa el tema, deberían darse una vuelta por el sitio de OWASP, donde van a encontrar mucha información útil sobre seguridad y buenas practicas para el desarrollo de aplicaciones seguras.