Définition du cross-site scripting et comment le prévenir

Le XSS est une vulnérabilité pour la sécurité du web. On utilise souvent l’abréviation XSS pour y faire référence. 

Sur les sites et les applis vulnérables, les interactions des utilisateurs avec l’application peuvent être compromises par un acteur de menace, généralement appelé attaquant. Le XSS est une technique que les acteurs malveillants utilisent pour échapper aux contrôles tels que la politique de même origine, sur laquelle les navigateurs modernes s’appuient pour limiter l’accès aux données entre des applications ou des sites web.

Lors d’une attaque par XSS, un attaquant pourra se faire passer pour un utilisateur, ce qui lui permettra d’effectuer toute action qu’un utilisateur légitime réaliserait. L’attaquant pourra aussi accéder aux informations personnelles de l’utilisateur. 

Si un attaquant obtient l’accès d’un utilisateur avec un accès privilégié à un site web ou une appli, l’attaquant pourrait causer encore plus de dégâts en modifiant son fonctionnement et en volant ses données.

Une attaque par cross-site scripting, c’est quoi ?

Une attaque par XSS s’appuie sur un script malveillant injecté par un attaquant pour être exécuté du côté du client par le navigateur d’un utilisateur, parfois appelé payload. 

Avec l’XSS, un attaquant peut s’appuyer sur un site web vulnérable ou une appli dans une zone de transit pour déposer un code malveillant (ou payload) dans le navigateur de l’utilisateur. Lorsque l’utilisateur consulte le site web ou l’application infecté, un script est exécuté, qui permet à l’attaquant de dévaster cette interaction.

Types d’attaques par cross-site scripting

Il existe trois principales catégories d’attaques par XSS : XSS réfléchi (ou non permanent), XSS stocké (ou permanent) et XSS basé sur le DOM (ou local).

• XSS réfléchi - C’est là que le payload est « réfléchi » depuis une application web sur le navigateur de l’utilisateur. Le code est généralement activé par le biais d’un lien figurant dans un email de phishing ou envoyé par message privé sur les réseaux sociaux. Ce lien conduit à un site vulnérable qui autorise l’exécution du script.

   

• XSS stocké - Dans une attaque par XSS stocké, le payload de script malveillant est généralement stocké sur la base de données du serveur web du site web affecté et injecté dans une appli web lorsqu’un utilisateur charge une page depuis ce serveur web.

   

• XSS basé sur le DOM - Ici, le problème réside du côté du code du client (par opposition au code du côté du serveur). L’attaque est activée en modifiant le DOM (Document Object Model) dans le navigateur de l’utilisateur, ce qui fait que le script côté client fonctionne différemment de ce qu’il devrait.

Il est également important de mentionner les tests d’intrusion dans les applications ou simplement les pentesters. Les pentesters simulent des cyberattaques sur les systèmes ou les réseaux des ordinateurs d’une organisation. Il s’agit de tests légitimes, autorisés, qui aident à identifier les vulnérabilités de la cybersécurité pour les résoudre avant que des attaquants malveillants ne les trouvent et les exploitent.

Was kann ein Angreifer mit einem Cross-Site Scripting-Angriff tun?

Ein erfolgreicher XSS-Angriff ermöglicht es einem Bedrohungsakteur in der Regel, sich als echter Benutzer auszugeben. Dies ist gefährlich, da es dem Angreifer im Falle eines hochrangigen Benutzers mit eingeschränktem Zugriff in der Lage wäre:

• Alle Änderungen an der Anwendung oder der Website als dieser Benutzer vorzunehmen

• Alle Daten, auf die der identifizierte Benutzer Zugriffsrechte hat, zu lesen

• Logindaten und Passwort des Benutzers stehlen

• Manipulation, Vandalismus oder Verunstaltung der Website oder App durchzuführen

• Die Website oder Anwendung mit einem Trojaner infizieren

Wie Cross-Site Scripting funktioniert

Ein XXS-Angriff besteht in der Regel aus zwei Schritten. Damit der erste Schritt erfolgen kann, muss die vom Angreifer als Angriffsziel identifizierte Website eine sein, die Benutzereingaben zulässt (z. B. ein Online-Nachrichtenbrett). Die vom Angreifer eingefügte bösartige Codefolge wird vom Browser des Opfers als legitimer Quellcode behandelt.

1. Der Angreifer findet einen Weg, die Nutzlast über eine vom Opfer besuchte Webseite in den Browser des betroffenen Benutzers zu injizieren. 

    

2. Sobald die Nutzlast in die Webseite injiziert wurde, muss der Benutzer diese Seite besuchen. In Fällen, in denen der XSS-Angriff auf ein bestimmtes Opfer oder bestimmte Opfer abzielt, kann der Angreifer ein Phishing-Schema oder Social Engineering verwenden, um die bösartige URL zu übermitteln, die sie besuchen sollen. Diese Schemata spielen eine Schlüsselrolle bei Kontoübernahmebetrug (ATO, Account Takeover Fraud) und führen zu weiteren Problemen für die geschädigten Nutzer.

    

Wer ist am anfälligsten für einen Cross-Site Scripting-Angriff?

Zu den Websites oder Anwendungen, die besonders anfällig für XSS-Angriffe sind, gehören Messageboards, Diskussionsforen oder Websites, auf denen Benutzer Kommentare abgeben können. Diejenigen, die diese Seiten besitzen und betreiben, sollten besonders wachsam sein, was die Sicherheit angeht.

Jede Website oder Anwendung, die ungefilterte oder potenziell unbereinigte Benutzereingaben verwendet, um eine unsachgemäße Ausgabe zu erzeugen, könnte besonders anfällig für XSS-Angriffe sein. 

XSS-Angriffe finden am häufigsten in JavaScript statt, da diese Sprache die Codegrundlage der meisten Webanwendungen bildet. Sie können aber auch über älteres Flash oder ActiveX sowie über VBScript und CSS durchgeführt werden.

Häufige Schwachstellen, die von XSS-Angreifern ausgenutzt werden

Hier ist eine Liste von Vektoren, die ein XSS-Angreifer aus verschiedenen Gründen ausnutzen könnte. Dies ist keine erschöpfende Liste, sondern nur einige der häufigsten Ziele für das Einfügen von bösartigem Code.

• JavaScript-Ereignisse

• <script>-Tags 

• <embed>-Tags

• <img>-Tags 

• <body>-Tags 

• <iframe>-Tags

• <link>-Tags

• <input>-Tags

• <div>-Tags

• <table>-Tags

• <object>-Tags

Wie man einen Cross-Site Scripting-Angriff verhindert

Obwohl ein XSS-Angriff sehr gefährlich sein kann, gehören XSS-Schwachstellen zu den häufigsten in Webanwendungen. Für das Open Web Application Security Project (OWASP) stehen Injektionsangriffe, einschließlich XSS, auf Platz drei seiner Top Ten Web Application Security Risks.

Das Verhindern von XSS-Angriffen ist nicht einfach, aber durchaus möglich. Welche Vorbeugungstechniken Sie verwenden, hängt von Ihrem Programmiergerüst, der Art der Sicherheitslücke, die Sie betrifft, und der Art und Weise ab, wie Benutzereingaben über Ihre Anwendung verwendet werden. Es gibt jedoch einige grundlegende Schritte, die XSS-Angriffe universeller verhindern.

1. Sensibilisierung und Schulung der Mitarbeiter Stellen Sie sicher, dass alle Personen, die an der Erstellung und Wartung Ihrer Webanwendungen beteiligt sind, über die Gefahren von XSS-Schwachstellen informiert sind. Dazu gehören nicht nur Entwickler, sondern auch Systemadministratoren, DevOps und Qualitätssicherungspersonal. QA-Tests, auftragsunabhängige Pen-Tests und dynamische Anwendungstests sollten in Betracht gezogen werden. Häufige und gründliche Tests sind entscheidend.

    

2. Filterung aller Eingaben beim Empfang Vermeiden Sie nach Möglichkeit HTML-Eingaben. Jede Eingabe, die sich nicht vermeiden lässt, muss so gründlich wie möglich gereinigt werden. Man sollte den von einem Benutzer oder Browser empfangenen Daten nicht trauen, selbst wenn sie von einem authentifizierten Benutzer stammen. Gehen Sie davon aus, dass alle Daten öffentlich zugänglich sind und bösartige Codes enthalten können. Als Sicherheitsarchitekturmodell, das jeden einzelnen Benutzer und jedes Gerät verifiziert und authentifiziert, bevor er auf Anwendungen und andere Ressourcen zugreifen kann, ist ein Zero-Trust-Ansatz in der Lage, Ihre XSS-Anfälligkeit zu verringern. Stellen Sie sich vor, Sie bewegen sich weg von einem „vertraue, aber überprüfe“-Modell hin zu einem „vertraue nie, überprüfe immer“-Modell.

    

3. Encoding oder Escaping aller Daten in der Ausgabe Immer wenn Benutzereingaben Teil der HTML-Ausgabe sind, besteht ein erhöhtes XSS-Risiko. Sie können das Risiko verringern, indem Sie die Ausgabe so codieren, dass sie nicht als aktiver Inhalt verstanden werden kann. Je nach Kontext der Ausgabe kann dies eine kombinierte Codierung mit HTML, JavaScript, URL und CSS erfordern. Diese Technik wird auch als „Output Escaping“ bezeichnet.

    

4. Sicherstellung geeigneter Antwort-Header Durch die Verwendung von Content-Type- und X-Content-Type-Options-Headern können Sie verhindern, dass XSS in HTTP-Antworten eingeschleust wird, die kein JavaScript oder HTML enthalten sollten. Diese Header können den Browsern helfen, die von Ihnen beabsichtigte Antwort auszuführen.

    

5. Umsetzung der Content Security Policy Nachdem Sie alle oben genannten Maßnahmen ergriffen haben, können Sie die Content Security Policy (CSP) als letztes Sicherheitsnetz einsetzen. CSP ermöglicht es Website-Besitzern, die Herkunft von Inhalten, Skriptblöcken und Skriptdateien, die von Browsern auf ihre Website geladen werden dürfen, zu standardisieren und ausdrücklich zu deklarieren. Dies kann dazu beitragen, das Ausmaß der verbleibenden XSS-Schwachstellen zu verringern.

Da Sie nun wissen, wie gefährlich – und wie häufig – XSS ist, sollte klar sein, dass die Zugriffskontrolle allein nicht ausreicht, um XSS-Angriffe zu verhindern. 

DevOps- und IT-Sicherheitsteams sollten einen umfassenden Ansatz zum Schutz vor allen API-Bedrohungen verfolgen. Um mehr über die entscheidenden Schritte zu erfahren, die diese Teams unternehmen sollten, lesen Sie 12 Dinge, die DevOps und IT-Sicherheit zum Schutz von APIs tun müssen.