En los Viejos Tiempos
El último apunte teórico antes de adentrarnos en los ataques basados en DOM son los frameworks de frontend modernos. Aplicaciones web convencionales donde el DOM entero se actualiza con cada petición.
Cada vez que un usuario navega una sección diferente de la web, la respuesta dada ofrece un código HTML diferente y el DOM reconstruido desde cero. Sin embargo, esto reducía la responsividad de las aplicaciones web.
El Auge de los Tiempos Modernos
Con el auge de los frameworks modernos, se dio a luz a un nuevo modelo de aplicación llamado Single Page Application (SPA). Las SPAs son cargadas una única vez cuando el usuario visita el sitio web por primera vez y todo el código se carga en el DOM. Usando JavaScript, en lugar de recargar el DOM con cada nueva petición, el DOM se actualiza automáticamente.
En lugar de recargar el DOM con cada petición, las respuestas sólo contienen la información requerida para actualizar el DOM. Esto reduce drásticamente el tiempo de espera de cada petición (aunque la primera carga pueda tardar más).
Los frameworks de frontend modernos como Angular, React y Vue permiten a los desarrolladores crear estas SPAs. En lugar de que el servidor sea responsable del DOM, el SPA es cargado una vez y luego las interfaces a través de peticiones a la API. Aunque esto incrementa la responsividad, puede llevar a vulnerabilidades por configuración pobre.
Confusión del Límite de Seguridad
El primer error común es confundir donde están las fronteras de seguridad. Hay un dicho común en la seguridad de aplicaciones que dice: "Los controles del lado del cliente son sólo para la experiencia del usuario, todos los controles de seguridad deben de estar del lado del servidor".
No entender este principio suele conllevar a bypasses de autorización. Un ejemplo de esto es cuando los desarrolladores deshabilitan el botón editar en JavaScript. Sin embargo, como puedes alterar el DOM en tu navegador, puedes rehabilitarlo y hacer la petición, bypasseando la autorización. Aunque hace una mejor experiencia de usuario tener el botón deshabilitado, se necesita una comprobación del lado del servidor.
Validación Insuficiente del Input del Usuario
El segundo error común es no validar suficiente el input del usuario. Esto suele pasar cuando los equipos de desarrollo del frontend y el backend no se comunican para precisar quién toma la responsabilidad de qué controles de seguridad. El equipo de frontend suele implementar filtros para sanitizar o validar el input del usuario antes de mandar la respuesta al servidor. Sin embargo, el equipo del backend debe realizar las mismas comprobaciones y la sanitización de dicho input. Lo que pasa es que el equipo de backend suele mandar la información raw, esperando que el frontend haga validaciones.
Esto suele derivar en que ninguno de los dos equipos tome la responsabilidad de la validación del input. Como cada equipo espera que el otro se encargue de la seguridad, suele acabar con brechas de seguridad permitiendo ataques como XSS o CSRF. Esto en los días modernos puede derivar en que el input introducido en la aplicación A sea inocuo para la aplicación A, pero la aplicación B puede pensar que el input ya ha sido sanitizado y por consiguiente creando un agujero por donde los atacantes se meten.