Angular , ReactJS, VueJS, Javascript— Quien tiene la culpa?, frontend o backend.
Llevo mucho tiempo realizando análisis de seguridad (pentesting) y BugBounty’s a aplicaciones Web , y entre estas me encontré portales que hacen uso de Javascript, AngularJS, ReactJS y VueJS, frameworks muy interesante que dan grandes funcionalidades para el lado del cliente y esto hace que también se pueda encontrar errores de seguridad. Algo que me llamo la atención es la divulgación de información y el mal manejo de sesiones, pero vamos paso a paso para ir entendiendo.
Que son estos frameworks?
Para no buscar definiciones mejor veamos los portales oficiales.
Al utilizar alguno de estos frameworks estos generan uno o varios archivos de extencion “.js” o “.ts”, lo primero que se puede hacer es un análisis de código estático pero muchos de estos archivos están ofuscados o minificados y llevan una gran cantidad de contenido y realizar el análisis de código estático manual se vuelve tedioso.
Primero debemos tener una lista de estos archivo JS.
Con la herramienta BurpSuite (ahora uso burp), podemos seleccionar los archivos .js o .ts y los copiaremos aun archivo.
Pero también podemos usar filtros que tiene BurpSuite.
Depende el portal podremos ver mayor o menor cantidad de archivos JS, en ambos casos podemos seleccionar la lista de URL’s y guardarlas para un análisis posterior.
Descarga de estos archivos
Para esto utilizare cURL les dejo un pequeño script que descarga todos los archivos JS.
for url in `cat $file`
do
echo $url
curl $url -O -s
done
Ahora que ya tenemos los archivos pasemos a des-ofuscar o des-minificar en algunos casos no es necesario esta tarea.
Para este paso hay opciones online como
una gran cantidad de paginas que nos ayuda a realizar esta tarea, pero también tenemos herramientas de linea de comando.
pero ahora debemos des-ofuscar o des-minificar todos los archivos descargados. (Bash automatizara esta tarea)
for file in `ls *.js`
do
echo "un-minified file: $file"
js-beautify $file > $file.txt
done 
Divulgación de información (API/Webservices/RestFull/Funciones).
Ahora que ya tenemos los archivos listos para analizar lo primero que buscaremos seran las URL o rutas que utilizan esos servicios para funcionar correctamente.
Un paso tedioso pero muy útil es realizar el análisis manual para verificar y buscar funciones donde se realizan peticiones de tipo GET, POST, PUT, etc.
También podemos utilizar herramientas que nos ayudara a extraer la información que necesitamos.
Automatizamos con bash esta tarea para revisar todos nuestros archivos (con extención txt).
for file in `ls *.txt`
do
# echo $file
ruby ~/Tools/relative-url-extractor/extract.rb $file
doneLinux tambien nos ayuda para extraer las URL y algunas rutas relativas, también podemos crear diferentes expresiones regulares según las rutas que encontremos.
Extrae información adicional
grep -iEo '(http|https)://[^/"]+/.*' nombre_archivoExtrae solo las URLs encontradas.
grep -iEo '(http|https)://[^/"]+/' nombre_archivoExtrae rutas adicionales.
grep -Eo '('/'|'')([a-zA-Z]+/[a-zA-Z]+/.*)' nombre_archivo
Estos son algunos portales que tenia gran información interesante, pero existen otros portales de bancos e instituciones publicas y privadas que muestran una gran cantidad de información sobre las rutas y dominios de sus API/Restful, WebServices, etc.
Preguntando a algunos amigos sabios de javascript, angular, react, me comentaron que esto se puede controlar enviando los archivos JS con pocas funcionalidades y a medida se utilice el portal se enviara mayor información, pero este es un trabajo adicional para los de backend y frontend.
Bueno con esta información ya extraída un atacante puede realizar pruebas para encontrar vulnerabilidades que los desarrolladores no conocen o se les olvido darle mayor seguridad.
El mal manejo de sesiones es una vulnerabilidad que constantemente encuentro en aplicaciones web con estas nuevas tecnologías, como también la divulgación de información, el inadecuado manejo de errores, etc.
Ahora aquí viene la pregunta, quien tiene la culpa?, cuando se tiene reuniones para solucionar este tipo de errores, estos equipos se pasan la bolita o buscan formas de pasarle la tarea al otro equipo, pero bueno es una pelea constante con equipos de desarrollo que no realizan código seguro. (también hay el problema de seguridad y/o funcionalidad discusión para otro día)
OWASP nos presenta un Top Ten de las vulnerabilidades:
que en mi opinión todos los desarrolladores deben leer.
Espero que sea un post útil para sus futuros trabajos de pentesting o desarrollo. Happy Hacking.
