I01 – Uso de secuencias de comandos en sitios cruzados (XSS)

I01 – Ús de seqüències d'ordres en llocs creuats (XSS)

13 gener de 2025 Celia Catalán

Generalment anomenada per la seva nomenclatura anglesa, Cross-Site Scripting, aquest tipus de la vulnerabilitat en les aplicacions sovint és infravalorada pels equips de desenvolupament de les empreses, perquè tradicionalment s'han associat a atacs purament del navegador que afecten al client, sense anar més enllà de 'alguna enllaç com a intent de phishing, etc. Però la realitat és que aquest tipus' d'atacs, especialment combinats amb l'explotació d'altres vulnerabilitats existents, pot ocasionar un perjudici important.

Consisteixen principalment en la injecció de codi maliciós (generalment JavaScript, tot i que també vbscript en casos concrets), en el contingut d'aplicacions o pàgines web que altres usuaris poden veure. Mitjançant aquest codi, es poden arribar a robar dades. sensibles, com cookies o credencials, redirigir l'usuari a llocs maliciosos, o suplantar la identitat de l'usuari afectat, per realitzar accions en el seu nom sense el seu consentiment.

Hi ha diversos tipus de XSS, destacant fonamentalment tres grans classificacions, que es detallarà a continuació.

Per això, i abans de començar, es emplearà una aplicació amb determinades vulnerabilitats activades (en aquest caso les relatives a XSS), per aprenentatge. L'aplicació consisteix en un formulari de login bàsic, on s'accedeix, bé amb rol d'usuari o de administració a un panell, des d'on es gestionen uns articles amb la seva preu i en cas de ser l'administrador, la gestió d'usuaris de la aplicació, així com altres aspectes.

Tipus

XSS reflectit

Succeeix bàsicament quan l'entrada de l'usuari és processada i reflectida directament a la pàgina web, sense ser validada o codificada adequadament. Això permetria la injecció de codi de tal manera que quan s'executi aquesta petició, es reflecteixi el resultat d'aquesta injecció. D'aquesta manera, es podria enviar la URL (potser amagada sota un escurçador d'adreces web, que s'enviaria a l'usuari, destinatari de l'atac). D'aquesta manera, l'usuari, en executar aquest enllaç, executaria també el codi JavaScript contingut a la URL, que podria ser una redirecció al lloc web de l'atacant on, per exemple, es procediria al robatori de la cookie de sessió de l'usuari a la web actual. Un altre exemple seria l'execució d'un "hook" maliciós contra el navegador web de la víctima, controlat a partir d'aquest moment per l'atacant (mitjançant l'aplicació Beef, un framework força conegut per a l'explotació web, per exemple).

Així, tornant a l'aplicació vulnerable esmentada, si es comprova a la secció de la llista d'articles, el camp de cerca que permet a l'usuari cercar per determinats articles:

'Connectant-se a l'aplicació com a user1, es poden accedir als articles d'aquest usuari, a la llista d'articles, a través del menú "Gestiona els teus articles".'

Si es busca un article (nom o descripció) que existeixi, per exemple "article 1":

Com es pot observar, el resultat es reflecteix en la resposta.

Ara es provarà de buscar per una seqüència de comandes per veure si el navegador interpreta com a codi o no la resposta:

- Injectant codi HTML (per exemple, la típica capçalera entre tags

...

Indicatiu que, almenys, està interpretant el codi HTML sense cap filtre, deixant inyectar codi HTML, que és interpretat pel navegador.

- Injectant codi JavaScript. No s'aconseguirà amb els típics missatges. , però existeixen moltíssims payloads, tenint un bon referent a la pàgina de PortSwigger Academy. O si no, provant amb URL encodings diferents. Un dels possibles payloads, per exemple, seria injectar un objecte HTML de tipus imatge el qual error en la càrrega motivi l'execució d'un script (i aquí sí, per provar, el típic alert):

- Interceptant la petició amb BurpSuite, s'analitza la resposta que rep realment la cerca que carregarà via Ajax el resultat a través del paràmetre search en items_search.php:

En reenviar la resposta al navegador, es pot comprovar la vulnerabilitat:

El següent pas seria, per exemple, aixecar un petit servei web a la màquina atacant de tal manera que es modifiqui lleugerament el payload (per exemple, per per aconseguir robar la galeta de l'usuari que realitzarà el reenvio d'aquesta consulta. Per exemple, si se li envia la URL amb el payload en el paràmetre de cerca codificat i introduït en un escurçador d'adreces web a l'administrador del lloc.

XSS emmagatzemat

Aquesta és una de les vulnerabilitats més crítiques dins dels diferents tipus de XSS, ja que és l'únic cas on la injecció pot ser persistent, ja que el codi maliciós queda emmagatzemat permanentment al servidor, i afecta a tots els usuaris que visualitzen el contingut, no només als que fan clic en l'enllaç maliciós. És a dir, hi ha una interacció amb el servidor, amb la qual cosa es podria combinar amb altres vulnerabilitats per arribar fins i tot a controlar l'accés al mateix. És el típic cas referent als formularis de comentaris d'opinió en un lloc, etc. Encara que també podria donar-se en un altre tipus de dades, com taules que emmagatzemen resultats prèviament introduïts per l'usuari, on els camps no han estat validats adequadament.

Tornant a l'exemple anterior de l'aplicació vulnerable. En la gestió dels articles, es pot apreciar que hi ha un botó per a la creació de nous articles (Add New Item). Si s'aconsegueix injectar codi en qualsevol dels camps del nou article (ja sigui a través de cada camp, o interceptant la petició amb un proxy web) tenint en compte la codificació URL dels espais i altres caràcters especials), aquest XSS quedarà emmagatzemat per a tots els usuaris de l'aplicació.

Havent iniciat sessió amb un altre usuari (user2), es tracta ara d'inserir un XSS determinat per provar si la pàgina és vulnerable en aquest punt. Per exemple, en el mateix exemple d'abans, es permet crear nous articles. Si s'insereix un payload del tipus al camp descripció (que és prou llarg per poder inserir els caràcters necessaris). En desar l'article:

Una vegada comprovat que és vulnerable, s'elimina l'article (o s'edita, i es reemplaça la descripció) i es crea un altre que no mostri directament el resultat per pantalla, sinó que enviï, per exemple, la cookie de l'usuari a un servidor web que corre a la màquina atacant, amb el següent payload:

En executar la modificació/alta, no s'observarà res aparentment estrany a la taula resultant:

Tanmateix, al servidor web que s'executa a la màquina atacant:

Quan l'usuari administrador, que té accés a tots els articles, obri aquesta pàgina:

i es llanci silenciosament el script executat per l'atacant, la cookie de l'administrador es mostrarà com a part del paràmetre de la petició realitzada al servidor web de l'atacant:

La diferència (i la criticitat) respecte al XSS reflectit és notable: qualsevol usuari que tingui accés a aquest registre estarà afectat, mentre que, en el reflectit, es requeriria l'enviament de l'enllaç maliciós a cadascun dels usuaris objectiu d'aquest atac.

Igualment, aquest script podria ser reemplaçat per un hook.js de Beef per controlar el navegador dels usuaris que es connectessin a aquesta pàgina, o executar scripts més sofisticats que poguessin posar en perill altra informació del servidor web.

XSS basat en DOM

En el XSS basat en DOM (Document Object Model), el codi maliciós s'executa directament al costat del client, manipulant el DOM del navegador sense interaccionar amb el servidor. Així, el que es fa és una manipulació o modificació del contingut dinàmic de la pàgina, mitjançant l'execució de codi JavaScript al client, en aquells paràmetres o camps de la pàgina que no han estat codificats ni validats correctament. Així, tots els usuaris que executin la pàgina que ha estat manipulada, es veuran afectats per aquest tipus d'atac.

A l'aplicació d'exemple, quan un usuari aconsegueix iniciar sessió al lloc web, se li mostra com a transició un llenguatge de benvinguda, que està injectant directament i sense validar, el nom de l'usuari que ha iniciat sessió, en un .innerHTML de l'objecte HTML destinat a contenir el missatge de benvinguda.

Es pot manipular aquest .innerHTML injectant el script corresponent, de tal manera que es modifiqui el DOM de la resposta, en temps d'execució, al navegador del client:

I es roba la cookie de sessió de l'administrador, tal com es pot apreciar al servidor de l'atacant:

Com el missatge de benvinguda es redirigeix al panell d'administració, al cap de dos segons, l'administrador no haurà estat conscient que s'ha robat la seva galeta de sessió.

Atacs combinats: Evasió de token CSRF explotant vulnerabilitat XSS

A l'aplicació d'exemple, hi ha un panell d'administració (users_mgmt.php), gestionat només pel administrador del lloc (user admin):

El camp Observacions és vulnerable a XSS. Cada usuari pot modificar el seu perfil, un cop iniciada sessió a la seva corresponent pàgina de canvi de perfil, user_edit.php (incloent la contrasenya).

Si s'observa el detall del codi, la pàgina web conté un token que preveu possibles atacs de CSRF/XSRF (Cross-Site Request Forgery).

Si es realitza un estudi de la fortalesa i la aleatorietat d'aquests tokens, mitjançant el seqüenciador de BurpSuite, es pot arribar a la conclusió que és un token prou robust i fiable, com per intentar ser endevinat fàcilment, molt lluny de poder ser atacat per força bruta.

En 2260 tokens analitzats, cap d'ells es repetia ni una sola vegada.

No obstant això, com s'ha avançat abans, se sap que el camp d'observacions és vulnerable a XSS. En cas que això ocorri, no importa la fortalesa o la aleatorietat del token emprat: la pàgina serà vulnerable a CSRF, encara que s'hagi protegit.

Així doncs, es podria abusar d'aquesta injecció sobre el camp d'observacions, per crear un script que llegeixi el token (anti) CSRF de la pàgina actual i ajudi a evadir-lo, executant per exemple un canvi de contrasenya per a l'usuari administrador (observi's que l'identificador del registre ve donat per un id, i aquest id s'utilitza en la gestió d'usuaris, per editar cada usuari, incloent l propi administrador (presumiblement l'identificador 1 de la taula, ja que l'usuari "hacker" té l'identificador 6).

Així, l'usuari "hacker" després d'interceptar amb Burp i estudiar les peticions de modificació de cadascun dels camps i els resultats, podria crear, per exemple, el següent script, per capturar del DOM dinàmicament el token vigent, i amb ell modificar la contrasenya de l'usuari "admin", robant-li el compte:

Així, inserint el script al camp Observacions:

s'aconseguiria, que quan l'usuari "administrador" entri en la gestió d'usuaris, activi sense saber-ho el script, que canviarà automàticament la contrasenya, permetent que l'usuari "hacker" pugui robar el seu compte:

En aquest moment, l'usuari "hacker" podrà entrar amb el compte de l'administrador i la nova contrasenya...

Conclusió

Mai s'ha de subestimar el poder de les injeccions XSS, perquè poden derivar en problemes greus, fins i tot la presa de control del servidor web sencer, si se sap combinar bé amb altres vulnerabilitats existents al lloc.

Mesures de prevenció

Per a una correcta mitigació de XSS, s'haurien d'aplicar una sèrie de bones pràctiques en el desenvolupament d'aplicacions web:

Validació del costat del servidor i del client

No n'hi ha prou amb aplicar validacions dels camps o paràmetres d'entrada d'usuari al client, perquè podrien saltar-se aquests controls (simplement evitant les validacions al costat del client mitjançant l'omissió dels scripts corresponents). És necessari tenir una correcta validació al costat del servidor, validant les dades introduïdes (o interceptades i manipulades mitjançant un proxy web), i descartar aquelles que podrien ser perilloses o que no s'ajusten a la funcionalitat específica de l'aplicació.

Aplicació correcta de funcions per a l'escapat i la codificació

S'ha de garantir que la codificació de les dades introduïdes per l'usuari sigui la correcta abans que les dades siguin interpretades pel navegador, escapant els caràcters considerats com a "perillosos" mitjançant la funcionalitat existent en el llenguatge de servidor emprat, destinada a tal efecte. Per exemple, en PHP hi ha funcionalitats com htmlspecialchars o htmlentities que escapen certs caràcters (o tots els possibles, en el cas de l'última) a la seva equivalent en HTML. Aquestes mesures per si soles no són 100% fiables, ja que existeixen mesures d'evasió, però combinades amb la resta i una bona validació, són una bona opció defensiva.

Ús de "llistes blanques"

'Ús de llistes blanques davant de l'ús de llistes que descarten l'ús de certs caràcters o expressions registrades. És millor sempre autoritzar l'ús d'alguna informació, que rebutjar l'ús d'una altra, per la qual sempre es podria buscar un sistema d'evasió o substitució. Això sempre s'hauria de tenir en compte a l'hora d'establir determinades regles en el WAF (Web Application Firewall) emprat.'

Ús de mètodes per evitar la construcció dinàmica del DOM (Document Object Model)

S'han d'intentar utilitzar sempre mètodes segurs que evitin la inserció de dades no validades al DOM, a través de JavaScript, com ara setAttribute o textContent, en lloc d'innerHTML, per exemple.

Ús de capçaleres de seguretat

Política de Seguretat de Contingut (CSP)

Implementar, amb aquesta capçalera de seguretat, una política de seguretat de continguts per restringir quin tipus de recursos poden executar-se a l'aplicació web, evitant o bloquejant la injecció de scripts maliciosos.

Content-Security-Policy: default-src 'self'; script-src 'self' http://example.com; object-src 'none'

>El codi anterior permetrà carregar recursos únicament de la mateixa origen del servidor, permetent únicament la càrrega de scripts de la mateixa origen o del lloc fictici https://example.com, bloquejant completament la càrrega d'objectes tipus embed, object o applet, que podrien ser determinats vectors d'atac,

X-Content-Type-Options

Evitar atacs basats en l'anàlisi de contingut (MIME sniffing) per intentar d'aquesta manera executar scripts maliciosos:

X-Content-Type-Options: no-sniff

X-XSS-Protecció

Activar mitjançant aquesta capçalera el filtre XSS emprat per alguns navegadors per prevenir l'execució de certs scripts maliciosos. No tan robust en quant a seguretat com les anteriors capçaleres, però una mesura addicional útil: S'habilita el filtre i si es detecta un atac XSS, el navegador bloqueja l'execució de l'script, en comptes d'intentar sanejar el contingut (de totes maneres, s'haurien d'implementar mesures de sanejament a nivell de servidor sempre).

X-XSS-Protection: 1; mode=block

X-Frame-Opcions

Mitjançant la prohibició explícita que es pugui incrustar aquesta pàgina dins d'algun X-Frame, s'assegura que no es poden produir atacs de clickjacking que es puguin combinar amb XSS, incorporant una pàgina atacant que executi el script maliciós injectat dins d'un iframe.

X-Frame-Options: DENY

Intercanvi de Recursos entre Orígens (CORS)

Mitjançant la capçalera CORS es controla quins dominis poden realitzar peticions cap al servidor web des d'altres orígens. Configurat de la manera correcta, pot limitar l'accés a recursos sensibles des de llocs maliciosos (incloent combinacions de XSS amb SSRF, etc.)

Access-Control-Allow-Origin: http://example.com

Control de memòria cau

Si s'empra una mala configuració de l'emmagatzematge en caché, es podria donar peu a l'emmagatzematge de contingut maliciós o sensible de manera insegura. D'aquesta manera, mitjançant la configuració adequada d'aquest capçalera es podrà prevenir que determinat contingut dinàmic que s'executi amb la resposta a determinats formularis, no s'emmagatzemi en caché.

Cache-Control: no emmagatzemar, no emmagatzemar en memòria cau, cal tornar a validar

Referent-Política

Encara que aquest capçalera tampoc està directament relacionada amb XSS, si el navegador enviés, com a part del capçalera Referrer, certa informació, un atacant podria aprofitar-se d'aquesta informació per explotar determinats dades sensibles de les URLs mostrades com a part d'aquest capçalera, que de vegades inclouen paràmetres injectables, per explotar un XSS, per exemple.

Tornar al bloc