Sicherheitslücken von OWASP Top 10. A1: 2017 - Injektionen (Teil 1)

Published on August 06, 2018

Sicherheitslücken von OWASP Top 10. A1: 2017 - Injektionen (Teil 1)

    Die Beschreibung der Schwachstellen ist eine Sache, aber die Suche nach einer Schwachstelle und die Arbeit damit ist eine andere Sache. Zu diesem Zweck werden spezielle Anwendungen erstellt und entwickelt, bei denen Sicherheitslücken absichtlich bestehen bleiben. Wenn Sie in der Suchmaschinenanforderung "Zweckdienlich anfällige App" eingeben, finden Sie ein Dutzend Links.

    In diesem Zyklus werden wir beginnen, Schwachstellen von OWASP Top 10 abzubauen, und ich werde diese absichtlich anfällige Anwendung als Testgelände verwenden. In meinem Fall handelt es sich um OWASP Mutillidae II. Dies ist nicht die beste Option, aber darin werden Schwachstellen genau so strukturiert, wie dies für Bildungszwecke erforderlich ist.



    Gib deine Hand,

    also ist die erste Schwachstelle eine Injektion. In OWASP Mutillidae II werden verschiedene Optionen vorgestellt, und wir beginnen mit den einfachsten "SQLi-Extraktdaten"> "Benutzerinformationen (SQL)".
    Vor uns liegt das übliche Authentifizierungsfenster - mit dem Sie täglich interagieren:



    Wir haben kein Login oder Passwort - nichts. Nun, lass uns auf dieser Seite registrieren. 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“ scheint darauf hinzudeuten, dass eine bestimmte Zeile hinzugefügt wurde, anscheinend der Tabelle, da viele Konten am einfachsten im DBMS gespeichert werden können.

    Melden Sie sich jetzt mit unserem neuen Konto beim System an. Erfolgreich, großartig.
    Wenn Sie mit einer Webseite arbeiten, sollten Sie immer daran denken, dass unsere Interaktion nicht auf den Inhalt der Seite beschränkt ist. Es gibt beispielsweise auch eine Adresszeichenfolge. In dem wir viel Interessantes feststellen 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


    Beispielsweise sehen wir, dass das Passwort im Klartext übermittelt 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 natürlich jetzt falsch und wir haben den entsprechenden Fehler erhalten: und das ist schlecht. Das ist schlecht, denn mit der Hilfe von THC-Hydra, über die ich hier gesprochen habe , können wir dieses Passwort abrufen und es ohne jegliche Form in diese Zeile einfügen. Es ist jedoch lang und kann nicht immer in einer angemessenen Zeit zu einem positiven Ergebnis führen.

    Wir haben nicht so viel Zeit, also probieren Sie etwas anderes. Fügen Sie das Apostrophzeichen zu unserem falschen Passwort hinzu:

    username=belowzero273&password=123


    auf

    username=belowzero273&password=12345'


    Jetzt haben wir einen vollständigen Fehler erhalten:



    Es ist nichts falsch mit Fehlern. Wie kann ein Fehler sonst diagnostiziert werden, wenn keine Rückmeldung von der Anwendung angezeigt wird? Solche Fehler sollten jedoch für Benutzer und Eindringlinge nicht sichtbar sein.

    Wenn wir nun auf die Schaltfläche "Senden" im Hintergrund klicken, wird folgende Abfrage ausgeführt:

    SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'


    String-Variablen werden durch Apostrophe unterschieden. Unsere Webanwendung filtert nicht die Daten, die der Benutzer eingibt, und mit unserem zusätzlichen Apostroph haben wir die Anforderung verletzt. Nun, da wir 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 zu erhalten.

    Bitte beachten Sie, dass es sich bei der Abfrage um eine Funktion handelt. Beide Variablen müssen also true sein, da sie eine Kombination aus Benutzername und Kennwort sind. Ist logisch.

    Lassen Sie uns mit dieser Abfrage etwas mehr tun:

    SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1=’1


    Wir haben eine Bedingung hinzugefügt, die immer gilt: 1 = 1. Die Anfrage wird in zwei Fällen ausgeführt: Entweder haben wir die Kombination aus Login und Passwort erraten oder 1 = 1. Das heißt, es wird immer ausgeführt.

    Es stellt sich heraus, dass Sie Folgendes als Passwort angeben können:

    ' or 1='1


    Der Apostroph am Ende der Zeile wird nicht mehr benötigt, die Logik der Webanwendung legt es für uns fest. Boom! Und wir haben ein Beispiel mit allen Konten aus der Datenbank erhalten:



    Cool, jetzt haben wir Logins und Passwörter von allen, die in dieser Anwendung registriert sind. Und noch schlimmer, die Passwörter sind hier klar.

    Was ist daran falsch? Und die Tatsache, dass die meisten Benutzer für alle Websites dieselben Anmeldungen und Kennwörter verwenden. Wenn Sie sich auf einer anfälligen Site auf diese Weise registrieren, verlieren Sie möglicherweise den Zugriff auf alle Websites.

    Sie können weiterhin mit dieser Sicherheitsanfälligkeit experimentieren, beispielsweise nach dem Administratorkennwort suchen. Um dies zu tun, verwenden Sie als Login-Vertreter:

    admin' or 1='1


    Das heißt, wir suchen nach einem Datensatz in der Datenbank, bei dem der Login admin ist und das Passwort beliebig ist.

    Пароль не найден!


    Kennwörter werden nicht immer in Klartext gespeichert. Dies bedeutet jedoch nicht, dass die Authentifizierung sicher erfolgt. Sehen wir uns das zweite Beispiel in OWASP Mutillidae II „SQLi Bypass Authentication“> „Login“ an.

    Die Authentifizierung kann umgangen werden, wenn Sie eine entsprechende Anfrage erstellen. Vor kurzem haben wir das Konto unterhalb von null273 erstellt, und nun geben wir als Login an:

    ' or ('a' = 'a' and username='belowzero273') -- 


    Hier überprüfen wir die offensichtlich korrekte Bedingung - a = a und login - unter null273, und wir schneiden einen Teil der Anfrage mit der Hilfe "-" ab.

    Wir drücken die Eingabetaste und melden uns erfolgreich an, obwohl wir unser Passwort nirgendwo angegeben haben.

    So einfach?

    Manchmal fragen Kunden, ist es wirklich so einfach, die Authentifizierung auf unserer Website zu umgehen? Normalerweise beantworte ich eine Frage mit einer Frage: "Sind Sie sicher, dass dies noch nicht geschehen ist?" Die Injektionen stehen nicht zufällig im OWASP-Rating, da diese Schwachstellen bei ihrer Implementierung katastrophale Folgen haben.

    In der Praxis ist natürlich alles etwas komplizierter als in diesen Beispielen. Aber gerade an solchen grundlegenden Beispielen nimmt das Verständnis tieferer Probleme Gestalt an. Wir werden das nächste Mal fortsetzen.

    Sie können den Blog des Autors des Artikels lesenauf diesen Link .