Amirreza Nasiri
2017-01-04 08:44:27 UTC
Ich arbeite an Webanwendungen und wie Sie wissen, ist ein Administratorfenster in den meisten Fällen ein Muss. Wir können sehen, dass viele Webanwendungen eine spezielle Anmeldeseite für Administratoren haben, auf der es ein Formular gibt (normalerweise POST -Methode), mit dem Administratoren ihr Panel anmelden können.
Da die Feldnamen bekannt sind, kann ein Hacker versuchen, die Kennwörter zu knacken, selbst wenn einige Sicherheitsmethoden implementiert sind.
Was ist also das Problem mit einem einfachen GET -Schlüssel (as)? Benutzername) und sein Wert (als Passwort)? Warum es nicht oft verwendet wird oder zumindest in vielen Artikeln nicht empfohlen wird?
Für Administratoren werden benutzerfreundliche Anmeldeseiten nicht wirklich benötigt! In beiden Fällen werden Daten protokolliert ( GET / POST ), wenn ein MiTM-Angreifer vorhanden ist.
Bei Verwendung dieser Methode werden Felder jedoch nicht erwartet für Admins selbst. Hier ist ein Beispiel für einen PHP-Code:
"category.php": (Ein bedeutungsloser Seitenname)
<? Phpif (isset ($ _ GET ['Meaningless_user']) && $ _GET ['bedeutungsloses_Wort'] == "etwas") {session_start (); $ _SESSION ["user"] = "test"; Header ('Ort: category.php'); // Auf dieselbe oder eine andere Seite umleiten, damit die GET-Parameter aus der URL verschwinden} else {die (); // Es wird also wie eine leere Seite sein}? >
Sie sollten HTTPS verwenden, dann müssen Sie sich keine Sorgen um MITM machen.Wenn Sie sich nicht um Benutzerfreundlichkeit kümmern, können Sie außerdem die HTTP Basic- oder Clientzertifikatauthentifizierung implementieren. Dann müssen Sie die Authentifizierung nicht in der Webanwendung selbst implementieren.
Webserver-Protokolle und Proxy-Protokolle, Zeitraum, Hauptgründe, um diese Informationen zu veröffentlichen und nicht abzurufen.Alles, was jdow und tlng05 sagen, ist auch wahr, aber Protokolle sind die wichtigsten "oops there it is" mit HTTP (S) GET.
Ihr Administrator in einem Forum: "Hey, ich habe dieses Problem mit dem Administratorfenster meiner Site. Sie können es hier sehen: http://example.com/category.php?catID=admin&pageNumber=hunter2
"* Felder werden für Administratoren selbst unbekannt sein *" - Ich bin mir nicht sicher, was Sie damit meinen.Werden sie dynamisch generiert?Oder schlagen Sie `? Myusername = mypassword` vor?Warum konnten Sie mit POST nicht dasselbe tun?
"POST" gegen "GET" ist kein großer Stolperstein für Hacker, aber es hilft.Jedes bisschen ... hilft
Ihr größeres Problem ist, dass Sie HTTPS oder HTTP verwenden.Wenn Sie nur HTTP verwenden;POST oder GET stehen MITM gleichermaßen offen.Wenn Sie den Kanal sichern (was Sie sein sollten), ist [GET etwas weniger sicher.] (Http://stackoverflow.com/questions/4143196/is-get-data-also-encrypted-in-https)
_Aber da Feldnamen bekannt sind, kann ein Hacker versuchen, die Passwörter zu knacken, selbst wenn einige Sicherheitsmethoden implementiert sind_ - Gleiches gilt für eine herkömmliche GET-Anforderung.Aber kein Grund, warum Sie keine dynamisch generierten Feldnamen verwenden können.Speichern einer Suche, von der welche auf dem Server ist.Hilft nicht massiv der Sicherheit, erschwert aber den Hackern das Leben.
GET-Anfragen werden auch im Webbrowser in HISTORY gespeichert - das ist ein einfaches Ziel für fast jeden, der es schafft, auch nur 15 bis 20 Sekunden lang auf Ihren Computer zu gelangen.
Wenn Sie Benutzername und Kennwort in eine GET-Anfrage einfügen, werden diese möglicherweise in der Adressleiste Ihres Browsers angezeigt, abhängig von der URL-Länge. Dies kann ein Problem sein, wenn jemand nahe genug ist, um Ihren Bildschirm zu sehen.
Warum nicht die Autorisierungsmethode verwenden, die wir bereits in URLs haben?https: // user: pass@example.com / `.Auf diese Weise können Sie eine Verknüpfung zu etwas herstellen, für das eine Authentifizierung erforderlich ist. Der eigentliche Authentifizierungsprozess erfolgt jedoch über Anforderungsheader und wird normalerweise nicht in einem Protokoll angezeigt.
`Feldnamen sind bekannt`: Es spielt keine Rolle, es sei denn, Sie verwenden schwache Passwörter."Administratoren benötigen keine benutzerfreundliche Anmeldung": Legen Sie dann einfach die Authentifizierung über Ihren Webserver (z. B. Apache) fest.Sie können entweder die Basisauthentifizierung verwenden und Kennwörter im Browser speichern (mithilfe des Hauptschlüssels) oder Clientzertifikate in Browsern installieren (keine Kennwörter erforderlich).In jedem Fall ist es viel sicherer als die Verwendung von GET.
Wenn Sie sich für Spezifikationen interessieren, empfiehlt die http-Spezifikation dringend, dass GET-Variablen nur zum Abrufen verwendet werden sollten, um den Status Ihrer Anwendung nicht zu ändern.Abgesehen von den Sicherheitsaspekten, die dahinter stehen, kann es ein Faktor sein, wenn Ihr Code für eine ISO-Zertifizierung oder ähnliches zertifiziert werden muss, die die Einhaltung von Standards erfordert.
GET ist sehr anfällig für [Fälschung von Cross-Site-Anfragen] (https://en.wikipedia.org/wiki/Cross-site_request_forgery), z.über Bilder.Obwohl mir nicht klar ist, wie jemand dies nutzen könnte, ist es am besten, jede Aktion zu vermeiden, die über ein GET zu einem Ergebnis auf dem Server führt (in diesem Fall beim Anmelden).Nicht zu wissen, wie etwas ein Angriffsvektor sein könnte, bedeutet nicht, dass es keiner ist.Vermeiden Sie problematische Ansätze, die gegen den RFC verstoßen.