Categorías:

Etiquetas:

Inputs, sesiones y consejos

Validando información

Al trabajar con inputs de los usuarios se recomienda siempre validarlos, utilizando preferiblemente verificaciones del input contra carácteres válidos (known good) o de no ser posible, validarlo contra carácteres que deberían rechazarse (known bad). Partiendo de estas validaciones hay 4 enfoques:

  1. Match exacto: por ejemplo un input cuyos valores son únicos y conocidos, como un radio button.
  2. Aceptar válidos (known good): verificar que los caracteres que componen el dato sean válidos, por ejemplo un input de correo que debe contener un arroba y uno o más puntos.
  3. Rechazar no válidos (known bad): rechazar el dato si alguno de sus caracteres está presente en la lista de inadmisibles, por ejemplo un campo de unidades numéricas tendría que rechazar un valor que contenga letras.
  4. Codificar los no válidos (higienizar/sanitize): si se necesita guardar el dato y representarlo posteriormente, se puede optar por codificarlo en HTML para que no se interprete como texto o código ejecutable sino como un componente más.

Además, se recomienda evitar hacer logs de los errores/excepciones que encuentre la aplicación pues permite al atacante conocer más sobre la operación de la plataforma. También es importante verificar los máximos y mínimos de las peticiones pues estas pueden volverse una carga demasiado pesada para el servidor llegando a crear denegaciones del servicio si agotan los recursos.

Las validaciones de seguridad SIEMPRE deben hacerse en el servidor, las reglas que se utilizan en el cliente únicamente sirven para evitar que los usuarios hagan peticiones incorrectas al servidor, pero nunca deberían ser consideradas validaciones de seguridad. Es importante verificar el valor de los parámetros de la petición, pero también corroborar que los nombres de estos parámetros sean los adecuados.

Sesiones

Hay dos enfoques recomendados para trabajar con sesiones. Por un lado está el enfoque de variable encapsulada, que permite escribir el token de sesión, pero no permite leerlo, y se crea una función personalizada de fetch para que este módulo agregue automáticamente el token a las peticiones que lo requieran, la principal desventaja es que no es persistente y por ende se elimina cuando la página se cierra o se recarga.

El segundo enfoque es de a través de los Web Services, que sí son persistentes haciéndolos más prácticos para el usuario final, su implementación sin embargo es bastante más compleja. Se registra el web service en la página donde va a funcionar y se decide qué rutas va a vigilar (al utilizar «/» se vigilan todas), luego, en el archivo del web service, se deben definir las rutas que necesitan token de autorización, se declara una forma de obtener el token (habituálmente un post message), y se crea una función para agregar el header de autenticación, junto con un event listener que la llame cada que se intercepta un fetch.

Las contraseñas deberían evitar caracteres contiguos (abc), 2 números identicos juntos (por ejemplo 00) y deberían tener mínimo: 1 mayúscula, 1 minúscula, 1 número, 1 carácter especial, longitud de 8 caracteres. Además, una vez las contraseñas sean verificadas, deberían almacenarse codificadas con un hash de una vía (irreversible) para dificultar que posibles atacantes tengan acceso a las contraseñas planas, así como reducir la posibilidad de que los administradores conozcan contraseñas ajenas.

Cross site request forgery (XSRF)

Una de las principales preocupaciones de seguridad en plataformas web es el cross-site request forgery (creación de peticiones desde plataformas externas), resulta crítica pues aprovecha las sesiones que el usuario puede tener abiertas para hacer peticiones utilizando sus credenciales desde aplicaciones ajenas a las autorizadas. El navegador automáticamente hace la petición con las cookies de la página original, incluyendo la de sesión.

Servidor y cliente deben cooperar para mitigar esta vulnerabilidad, frecuentemente se aborda utilizando cookies. El servidor asigna al cliente un token aleatorio mediante una cookie llamada «XSRF-TOKEN» y verifica que las peticiones posteriores del cliente incluyan un header con exactamente el mismo valor que el que se asignó. Esto funciona porque solo el sitio web en el que se crean las cookies puede establecer un header personalizado leyendo ese token. Los valores deben ser únicos por usuario y díficiles de predecir.

Enlaces de interés