Die Beschreibung von Sicherheitslücken ist eine Sache, aber der Versuch, eine Sicherheitslücke zu finden und damit zu arbeiten, ist eine ganz andere Sache. Zu diesem Zweck werden spezielle Anwendungen erstellt und entwickelt, bei denen Schwachstellen bewusst zurückgelassen werden. Wenn Sie in die Suchmaschine die Abfrage "Zweckmäßig anfällige App" eingeben, finden Sie nicht ein Dutzend Links.
In dieser Reihe werden wir beginnen, Schwachstellen aus den OWASP Top 10 zu analysieren, und ich werde eine solche absichtlich anfällige Anwendung als Testgelände verwenden. In meinem Fall ist es OWASP Mutillidae II. Dies ist nicht die beste Option, aber die darin enthaltenen Sicherheitslücken sind genau so strukturiert, wie sie für Bildungszwecke benötigt werden.
Gib deine HandDie erste Sicherheitslücke sind also Injektionen. OWASP Mutillidae II bietet verschiedene Optionen, und wir beginnen mit den einfachsten "SQLi-Daten extrahieren"> "Benutzerinformationen (SQL)".
Vor uns liegt das übliche Authentifizierungsfenster - mit dem Sie täglich interagieren:
Wir haben keinen Benutzernamen oder Passwort - nichts. Dann registrieren wir uns auf dieser Seite. Ich werde einen Benutzer mit dem Namen unter Null273 und dem Passwort 123 erstellen:
Großartig! Wir haben ein Konto erstellt. Die feierliche Aufschrift „1 Zeilen eingefügt“ weist darauf hin, dass anscheinend eine Zeile zur Tabelle hinzugefügt wurde, da eine große Anzahl von Konten am einfachsten im DBMS zu speichern ist.
Melden Sie sich jetzt mit unserem neuen Konto im System an. Erfolgreich, großartig.
Wenn wir mit einer Webseite arbeiten, müssen wir immer daran denken, dass unsere Interaktion nicht auf den Inhalt der Seite beschränkt ist. Es gibt zum Beispiel auch eine Adressleiste. In denen wir viele interessante Dinge bemerken können:
http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details
Zum Beispiel sehen wir, dass das Passwort im Klartext übertragen wird. Dies ist schlecht, da der Verkehr abgefangen werden kann. Aber vielleicht keine solche Katastrophe - der Verkehr wird in TLS verpackt.
Versuchen wir, das Passwort direkt in der Zeile zu ersetzen, zum Beispiel dieses Stück:
username=belowzero273&password=123
auf
username=belowzero273&password=12345
Das Passwort ist jetzt natürlich falsch und wir haben den entsprechenden Fehler erhalten: und das ist schlecht. Es ist schlecht, denn mit Hilfe von THC-Hydra, über das ich hier gesprochen
habe , können wir dieses Passwort abrufen, indem wir es ohne jegliche Form in diese Zeile einfügen. Dies kann jedoch nicht immer in einem akzeptablen Zeitraum zu einem positiven Ergebnis führen.
Wir haben nicht so viel Zeit, also probieren wir etwas anderes aus. Fügen Sie unserem falschen Passwort ein Apostrophzeichen hinzu:
username=belowzero273&password=123
auf
username=belowzero273&password=12345'
Jetzt haben wir einen vollständigen Fehler erhalten:
An Fehlern ist nichts auszusetzen. Wie kann man eine Fehlfunktion sonst diagnostizieren, wenn wir kein Feedback von der Anwendung sehen? Solche Fehler sollten jedoch für Benutzer und Angreifer nicht sichtbar sein.
Jetzt sehen wir, dass tatsächlich, wenn wir im Hintergrund auf die Schaltfläche "Senden" klicken, die folgende Anforderung ausgeführt wird:
SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'
Apostrophe zeichnen Zeichenfolgenvariablen aus. Unsere Webanwendung filtert nicht die Daten, die der Benutzer eingibt, und mit unserem zusätzlichen Apostroph haben wir die Anforderung verletzt. Nachdem wir nun wissen, wie diese Abfrage im Hintergrund aussieht, müssen wir herausfinden, wie sie geändert werden kann, um die benötigten Informationen aus der Datenbank abzurufen.
Bitte beachten Sie, dass die Anfrage die Funktion und enthält, dh beide Variablen müssen korrekt sein, da dies eine Kombination aus Login und Passwort ist. Ist logisch.
Werfen wir einen kurzen Blick auf diese Abfrage:
SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1
Wir haben eine Bedingung hinzugefügt, die immer erfüllt ist: 1 = 1. Die Anfrage wird in zwei Fällen ausgeführt: Entweder haben wir die Kombination aus Benutzername und Passwort erraten, oder 1 = 1. Das heißt, es wird immer ausgeführt.
Es stellt sich heraus, dass Folgendes als Passwort angegeben werden kann:
' or 1='1
Der Apostroph am Ende der Zeile wird nicht mehr benötigt, die Logik der Webanwendung wird ihn für uns bereitstellen. Boom! Und wir haben eine Auswahl aus der Datenbank mit allen Konten:
Cool, jetzt haben wir Logins und Passwörter von allen, die in dieser Anwendung registriert sind. Und noch schlimmer, die Passwörter hier sind klar.
Was ist daran falsch? Und die Tatsache, dass die meisten Menschen für alle Websites dieselben Benutzernamen und Passwörter verwenden. Wenn sie sich auf diese Weise auf einer anfälligen Site registriert haben, verlieren sie möglicherweise den Zugriff auf alle ihre Sites.
Sie können auch mit dieser Sicherheitsanfälligkeit experimentieren, indem Sie beispielsweise nach einem Administratorkennwort suchen. Ersetzen Sie dazu den Login:
admin' or 1='1
Das heißt, wir suchen nach einem Eintrag in der Datenbank, in dem der Benutzername admin und das Kennwort beliebig ist.
!
Passwörter werden nicht immer im Klartext gespeichert, dies bedeutet jedoch nicht, dass die Authentifizierung sicher erfolgt. Schauen wir uns das zweite Beispiel in OWASP Mutillidae II „SQLi-Bypass-Authentifizierung“> „Anmelden“ an.
Die Authentifizierung kann umgangen werden, indem eine entsprechende Anforderung generiert wird. Zuletzt haben wir ein Konto unter Null273 erstellt und geben nun als Login Folgendes an:
' or ('a' = 'a' and username='belowzero273')
Hier überprüfen wir die offensichtlich korrekte Bedingung - a = a und das Login - unter Null273 und schneiden auch den Anforderungsteil mit Hilfe von "-" ab.
Drücken Sie die Eingabetaste und melden Sie sich erfolgreich beim System an, obwohl wir Ihr Passwort nirgendwo angegeben haben.
So einfach?Manchmal fragen Kunden, ob es wirklich so einfach ist, die Authentifizierung auf unserer Website zu umgehen. Normalerweise beantworte ich die Frage mit der Frage: "Sind Sie sicher, dass dies noch nicht geschehen ist?" Injektionen stehen nicht versehentlich ganz oben auf der OWASP-Bewertung, da diese Sicherheitsanfälligkeiten in der Regel katastrophale Folgen haben, wenn sie implementiert werden.
In der Praxis ist natürlich alles etwas komplizierter als in diesen Beispielen. An solchen grundlegenden Beispielen nimmt jedoch das Verständnis tieferer Probleme Gestalt an. Wir werden das nächste Mal weitermachen.
Lesen Sie den Blog des Autors
unter diesem Link .