Ich entwickle eine PHP-Webanwendung, ich möchte der Anwendung mehr Sicherheit geben, so dass niemand die Funktionalität leicht unterbrechen kann.
Kurze Erklärung zu meinem Problem: In einem Modul gibt es eine Phase, in der ich die Quelle der Anfrage (von wo diese Anfrage kommt) überprüfe
Momentan verwende ich HTTP_REFERRER variable (verfügbar in PHP). Ich überprüfe diesen Variablenwert mit einer bestimmten URL (z. B. Ссылка ). Wenn exakte Übereinstimmung existiert, rufe ich nur weitere Aktionen auf.
Ich bin etwas verwirrt mit obigem Ansatz, ob ich HTTP_REFERRER verwenden oder mit IP-Adresse überprüfen soll (gültige Anfrage, wenn sie von einer bestimmten IP-Adresse kommt)?
Ich möchte auch bessere Ansätze für die Bereitstellung von Sicherheit wissen.
Hat jemand Idee, dann bitte teilen?
Vielen Dank im Voraus
Lektion # 1 in der Websicherheit: Vertrauen Sie NIEMALS Benutzereingaben. Und wenn ich nie sage, meine ich niemals. ;) Einschließlich der HTTP_REFER-Variable in PHP, die leicht mit einem HTTP-Header kompromittiert werden kann (Quelle: Ссылка )
Eine mögliche Lösung beim Überprüfen der Quelle ist die Verwendung eines Formular-Tokens (csrf-Schutz): Ссылка ist aber auch nicht so sicher und ist nur mit deiner eigenen Quelle möglich.
Ein einfaches CSRF (Cross-Site Request Forgery) -Schutz-Beispiel: (Daher das Einfache. Für eine sicherere / robustere Lösung, siehe die Antwort von The Rook)
1) Erstellen Sie auf Ihrer Formularseite eine Art Token und fügen Sie Ihre Sitzung in ein verstecktes Formularfeld ein:
%Vor%2) Überprüfen Sie in Ihrem Formularhandler, ob das Token gültig ist.
%Vor% Das Überprüfen der HTTP_REFERRER für CSRF ist eine gültige Form des Schutzes. Obwohl es einfach ist, diesen HTTP-Header auf Ihrem EIGENEN BROWSER zu fälschen, ist es unmöglich, ihn zu fälschen in einem anderen Personen-Browser, der CSRF verwendet, weil die Regeln verletzt .
Nach Angaben des Department of Homeland Security habe ich festgestellt, dass die gefährlichste CSRF-Schwachstelle jemals gefunden wurde in den Top 1000 der gefährlichsten Schwachstellen aller Zeiten. Motorola hat diesen Fehler mit einer Referer-Prüfung behoben, und es ist üblich, diese Schutzmethode auf eingebetteter Netzwerkhardware zu sehen, da Speicher knapp ist.
Eine gebräuchlichere und sicherere Methode besteht darin, ein kryptografisches Nonce in einer Variable $_SESSION zu speichern und dies zu überprüfen jede sensible Anfrage. Ein einfacher Ansatz besteht darin, POST für alle sensiblen Anfragen zu verwenden (zB das Passwort zu ändern) und sicherzustellen, dass diese kryptografische Nonce für alle Posts in einer PHP-Headerdatei gültig ist, wenn sie nicht gültig ist, dann unset($_POST); . Diese Methode funktioniert, weil ein Angreifer zwar Ihren Browser dazu zwingen kann, SENDING GET / POST-Anfragen zu senden, er aber die Antwort nicht sehen kann, und da er dieses Token nicht lesen kann, um die Anfrage zu fälschen. Dieses Token kann mit XSS erhalten werden, also stellen Sie sicher, dass Sie Ihre Site auf xss testen .
Eine gute Methode zum Generieren eines csrf-Tokens ist md5(uniqid(mt_rand(),true)); Dies sollte genug Entropie sein, um CSRF zu stoppen. md5 () wird verwendet, um zu verschleiern, wie das Salz erzeugt wird. Denken Sie daran, dass die aktuelle Zeit nicht ein Geheimnis ist, der Angreifer weiß genau, zu welcher Zeit die CSRF-Anforderung erstellt wurde und kann eingrenzen, wann die Sitzung erstellt wurde. Sie müssen davon ausgehen, dass der Angreifer viele Vermutungen machen kann, und in der Praxis ist dies einfach zu bewerkstelligen, indem eine Reihe von Iframes auf die Seite geschrieben wird.
Treur hat es richtig gemacht, aber ich möchte noch ein paar Dinge klären und Ihnen Quellen für Referenzmaterial zur Verfügung stellen. Wie Treur sagte, vertraue NIEMALS Benutzereingabedaten, die alle vom Browser gesendeten Header enthalten.
Was Sie beschreiben, ist ein typischer Cross-Site Request Forgery-Angriff. Das Überprüfen des Referrer-Headers ist kein gültiger Schutz vor CSRF-Angriffen, da laut RFC2616 ( Hyper Text Transfer Protocol 1.1 ) ), ist der Referer Header optional und kann somit jederzeit vom Browser weggelassen werden. Wenn Sie SSL verwenden, wird der Referer Header von den Browsern immer weggelassen. Zweitens ist es ein benutzerdefinierter Wert und sollte daher nicht vertrauenswürdig sein.
Der empfohlene Schutz vor CSRF-Angriffen besteht darin, das synchronisierte Tokenmuster zu verwenden. Dies bedeutet, dass Sie ein geheimes Token erstellen sollten, das als verborgenes Feld in Ihrem Formular eingebettet ist. Wenn das Formular veröffentlicht wird, überprüfen Sie, ob das geheime Token vorhanden und gültig ist. Es gibt mehrere Strategien zum Erstellen von Sicherheitstoken. Ich werde einen Weg beschreiben, um die Token zu erstellen:
Erstellen Sie für jede Aktion in Ihrer Anwendung einen eindeutigen Aktionsnamen für sie. Zum Beispiel "delete_user", "add_user" oder "save_user_profile". Nehmen wir an, das von Ihnen beschriebene Formular hat den Aktionsnamen "foobar". Verketten Sie den Aktionsnamen mit der Sitzungs-ID des Benutzers und einem geheimen Wert.
$stringValue = "foobar" . "secret value" . session_id();
Um das Sicherheitstoken zu erstellen, erstellen Sie einen Hash der verketteten Zeichenfolge. Sie können sha1 verwenden, um den Hash zu erstellen. Um das Risiko von Brute-Force-Angriffen zu verringern, verwenden Sie einen größeren Schlüssel im Hash, z. B. sha 512.
$secretToken = hash("sha5125", $stringValue);
Setzen Sie dieses Token in das versteckte Feld Ihres Formulars. Erstellen Sie das Token neu und vergewissern Sie sich, dass es mit dem im Formular übermittelten Formular übereinstimmt, wenn das Formular übermittelt wird. Dieses Token ist für eine Benutzersitzung gültig. Man könnte argumentieren, dass es ein Zeitfenster gibt, in dem ein Angreifer das Token wiederverwenden kann, da es nicht bei jeder Anfrage neu generiert wird. Mit richtigen Session-Management-Strategien sollte dies jedoch kein Problem sein.
Wie ich schon sagte, ist eine ordnungsgemäße Sitzungsverwaltung notwendig. Dies bedeutet, dass Sie die Sitzungen nicht zu lange am Leben erhalten sollten. Vor allem Sicherheitslücken bei der Sitzungsfixierung werden jegliche CSRF-Schutzmaßnahmen rückgängig machen, da der Angreifer dann die Kontrolle über die Benutzersitzung hat und somit auch kann die geheimen Tokens "vorhersagen".
Hier sind ein paar Links, die ich Ihnen empfehlen zu lesen: