Lógica de negocio y validaciones en el navegador Web

Es común encontrar validaciones en el código de las aplicaciones y sitios Web, ¿pero es seguro solo tenerlas en el navegador Web? La respuesta es no, estas solo sirven para mejorar la experiencia de usuario y que no haya problemas o errores al llenar campos de entrada en el envío de datos al servidor.

Durante las revisiones de seguridad a aplicaciones, he encontrado un error común que debe ser entendido por todas aquellas personas inmersas en el mundo de la seguridad: aunque existen validaciones en el navegador Web (cliente) y también del lado del servidor, muchos desarrolladores solo implementan las primeras.

Para un atacante es fácil evadir una validación del lado del cliente y enviar valores que no son permitidos o incluso código ejecutable, ya que únicamente necesitaría una herramienta para la intercepción de peticiones (proxy).

Cuando un usuario ingresa a una página Web, el servidor envía el código necesario para que la aplicación pueda ser interpretada por el navegador y muestre lo que comúnmente conocemos como página Web.

Imagen 1. Comunicación cliente servidor

Durante la revisión de seguridad a una aplicación Web, se identificó que realiza la validación de los datos de entrada en el frontend, pero se comete uno de los errores más comunes al no hacer validación en el backend, lo que puede permitir que un atacante envíe código malicioso.

Imagen 2. Pagina vulnerable a XSS

La página muestra un campo para ingresar el nombre del usuario y un botón para enviar los datos, ¿pero qué pasaría si ingresamos valores que no son permitidos en los nombres? Como sabemos, estos no tienen números ni cráteres especiales, por lo que únicamente se deberían aceptar letras minúsculas y mayúsculas.

Además, al validar los datos ingresados por el usuario, el campo no debería estar vacío ni exceder cierta cantidad de caracteres, como se muestra a continuación:

Imagen 3. Mensaje de campo vacío
Imagen 4. Mensaje de exceso de caracteres
Imagen 5. Mensaje de caracteres no válidos

Cuando la validación de un dato de entrada es correcta, se manda al servidor y se recibe la respuesta mostrada a continuación:

Imagen 6. Nombre reflejado

A continuación, un ejemplo de cómo un atacante podría utilizar una herramienta para interceptar peticiones HTTP (proxy) para modificar los valores capturados y evadir estos controles.

Inserción de una cadena válida:

Imagen 7. Intercepción de petición HTTP

Petición original

Imagen 8. Petición HTTP

Petición modificada

Imagen 9. Petición HTTP modificada

Al mandar la petición modificada al servidor, su respuesta indica que no existe una validación en él, lo que en este caso lleva a un ataque de Cross-Site Scripting (XSS).

Imagen 10. XSS Reflejado

En conclusión la validación de los datos de entrada se debe considerar siempre del lado del servidor Web, dado que así siempre se tendrá más control sobre lo que suceda. Validar los datos del lado del servidor se considera como una necesidad, mientras que hacerlo del lado cliente se considera una comodidad.