Phenquestions
In diesem Artikel erhalten Sie die erforderlichen Informationen von der Anwendung, um zu wissen, was die angreifende Site tun sollte, um gültige Anfragen an den anfälligen Server zu senden. Anschließend erstellen Sie eine Seite, die die legitimen Anfragen simuliert und den Benutzer dazu verleitet, diese Seite zu besuchen, während er authentifiziert ist. Sie werden auch einige Iterationen am grundlegenden Proof of Concept durchführen, damit es eher wie ein realer Angriff aussieht, bei dem das Opfer es nicht bemerkt. Beachten Sie, dass die Codedatei für diesen Artikel auf dem Github des Autors zu finden ist.
Fertig werden
Für diesen Artikel benötigen Sie ein gültiges Nutzerkonto in BodgeIt. Dieser Artikel verwendet [E-Mail geschützt] als Opfer:
Wie es geht…
Zuerst müssen Sie die Anfrage analysieren, zu der Sie das Opfer zwingen möchten. Dazu benötigen Sie die Burp Suite oder einen anderen im Browser konfigurierten Proxy:
- Melden Sie sich als beliebiger Nutzer bei BodgeIt an und klicken Sie auf den Nutzernamen, um zum Profil zu gelangen.
- Nehmen Sie eine Passwortänderung vor. Sehen Sie, wie die Anfrage im Proxy aussieht:
Es ist also ein
POSTAnfrage zuhttp://192.168.56.11/Bodgeit/Passwort.jsp,und hat nur das Passwort und seine Bestätigung im Körper. - Versuchen Sie, eine sehr einfache HTML-Seite zu erstellen, die diese Anfrage repliziert. Erstellen Sie eine Datei (benennen Sie es
csrf-passwort ändern.html) mit folgendem Inhalt:
- Laden Sie nun diese Datei im gleichen Browser wie Ihre eingeloggte Sitzung:
- Klicken Sie auf Senden und Sie werden zur Profilseite des Benutzers weitergeleitet. Es wird Ihnen mitteilen, dass das Passwort erfolgreich aktualisiert wurde.
- Obwohl dies den Punkt beweist, kann eine externe Site (oder eine lokale HTML-Seite wie in diesem Fall) eine Anfrage zur Passwortänderung in der Anwendung ausführen. Es ist immer noch unwahrscheinlich, dass ein Benutzer auf das klickt einreichen Sie können es automatisieren und die Eingabefelder ausblenden, damit der schädliche Inhalt ausgeblendet wird. Erstellen Sie nun eine neue Seite basierend auf der vorherigen. nennen
csrf-change-password-scripted.html:Eine völlig harmlose Seite
Sie können dieser Seite vertrauen.
Ihnen oder Ihrem BodgeIt-Konto wird nichts Schlimmes passieren.
Diesmal hat das Formular einen ID-Parameter und es gibt ein Skript auf der Seite, das seinen Inhalt sendet, wenn die Seite vollständig geladen ist.
- Wenn Sie diese Seite in demselben Browser laden, in dem Sie eine BodgeIt-Sitzung initiiert haben, wird die Anfrage automatisch gesendet und die Profilseite des Benutzers wird danach angezeigt. Im folgenden Screenshot ist der Browser DebuggerSetzen Sie einen Breakpoint kurz bevor die Anfrage gestellt wurde:
- Dieser letzte Versuch sieht aus der Sicht eines Angreifers besser aus. Sie brauchen das Opfer nur, um die Seite zu laden und die Anfrage wird automatisch gesendet, aber dann sieht das Opfer die Ihr Passwort wurde geändertNachricht, und das wird sicherlich eine Warnung auslösen.
- Sie können die angreifende Seite weiter verbessern, indem Sie die Antwort in einem unsichtbaren Frame innerhalb derselben Seite laden. Es gibt viele Möglichkeiten, dies zu tun; eine schnelle und schmutzige ist, eine Größe 0 für den Rahmen festzulegen set. Ihre Datei würde so aussehen:
Eine völlig harmlose Seite
Sie können dieser Seite vertrauen.
Ihnen oder Ihrem BodgeIt-Konto wird nichts Schlimmes passieren.
Beachten Sie, dass die Zieleigenschaft des Formulars der direkt darunter definierte Iframe ist und dass dieser Frame 0 % Höhe und Breite hat.
- Laden Sie die neue Seite in den Browser, in dem die Sitzung gestartet wurde. Dieser Screenshot zeigt, wie die Seite aussieht, wenn sie mit dem Browser überprüft wird Entwicklerwerkzeuge:
Beachten Sie, dass das Iframe-Objekt nur eine schwarze Linie auf der Seite ist und Sie im Inspektor sehen können, dass es die Profilseite des BodgeIt-Nutzers enthält. - Wenn Sie die von Ihrer CSRF-Seite durchgeführte Netzwerkkommunikation analysieren, können Sie sehen, dass tatsächlich Anfragen zur Änderung des BodgeIt-Passworts gestellt werden:
Wie es funktioniert…
Wenn Sie eine Anfrage von einem Browser senden und bereits ein Cookie der Zieldomäne gespeichert ist, hängt der Browser das Cookie an die Anfrage an, bevor diese gesendet wird. Dies macht Cookies als Sitzungskennungen so praktisch, aber diese Eigenschaft der Funktionsweise von HTTP macht es auch anfällig für einen Angriff wie den, den Sie in diesem Artikel gesehen haben.
Wenn Sie eine Seite im selben Browser laden, auf der Sie eine aktive Sitzung in einer Anwendung haben, hängt der Browser automatisch das Sitzungs-Cookie an diese Anfrage an. Dies geschieht auch dann, wenn es sich um eine andere Registerkarte oder ein anderes Fenster handelt und diese Seite eine Anfrage an die Domäne sendet, in der die Sitzung initiiert wird.
Wenn der Server nicht überprüft, ob die empfangenen Anfragen tatsächlich von der Anwendung stammen, ermöglicht er einer bösartigen Site, Anrufe im Namen legitimer, aktiver Benutzer zu tätigen, die diese bösartige Site besuchen, während sie bei der Zieldomäne authentifiziert sind.
In einem Penetrationstest für Webanwendungen den ersten von Ihnen verwendeten Code, den mit den beiden Textfeldern und den einreichen Taste, kann ausreichen, um das Vorhandensein einer Sicherheitslücke zu demonstrieren. Der Penetrationstest der Anwendung kann jedoch Teil eines anderen Engagements sein, z. B. einer Social Engineering- oder Red-Team-Übung. In diesem Fall sind einige zusätzliche Anstrengungen erforderlich, um zu verhindern, dass der Benutzer des Opfers den Verdacht hat, dass etwas passiert.
In diesem Artikel haben Sie JavaScript verwendet, um das Senden der Anfrage zu automatisieren, indem Sie das onload-Ereignis auf der Seite festgelegt und die Sendemethode des Formulars in der Ereignishandlerfunktion ausgeführt haben. Sie haben auch einen versteckten iframe verwendet, um die Antwort auf die Passwortänderung zu laden, sodass das Opfer nie die Nachricht sieht, dass sich sein Passwort geändert hat.
Wenn Sie diesen Artikel interessant fanden, können Sie ihn erkunden Kali Linux Web Penetration Testing Kochbuch - Zweite Ausgabe um die häufigsten Web-Schwachstellen zu entdecken und zu verhindern, dass sie eine Bedrohung für die Sicherheit Ihrer Website darstellen. Kali Linux Web Penetration Testing Kochbuch - Zweite Ausgabe vermittelt Ihnen die Fähigkeiten, die Sie benötigen, um jede Phase eines Penetrationstests abzudecken – vom Sammeln von Informationen über das System und die Anwendung bis hin zur Identifizierung von Schwachstellen durch manuelle Tests manual.
