Sicherheit ist ein interessantes Konzept und zieht viele Menschen an. Leider ist es ein komplexes Thema und selbst die Profis verstehen es falsch. Ich habe Sicherheitslücken in Google (CSRF), Facebook (mehr CSRF), mehreren großen Online-Händlern (hauptsächlich SQL-Injection / XSS) sowie Tausenden kleinerer Websites sowohl von Unternehmen als auch von Privatpersonen gefunden.
Dies sind meine Empfehlungen:
1) Verwenden Sie parametrisierte Abfragen
Parametrisierte Abfragen erzwingen, dass die an die Abfrage übergebenen Werte als separate Daten behandelt werden, sodass die Eingabewerte nicht vom DBMS als SQL-Code geparst werden können. Viele Leute werden empfehlen, dass Sie Ihre Strings mit mysql_real_escape_string() maskieren , aber entgegen der landläufigen Meinung ist es nicht eine Catch-All-Lösung für SQL-Injection. Nehmen Sie zum Beispiel diese Abfrage:
SELECT * FROM users WHERE userID = $_GET['userid']
Wenn $_GET['userid'] auf 1 OR 1=1 gesetzt ist , enthält keine Sonderzeichen und wird nicht gefiltert. Dadurch werden alle Zeilen zurückgegeben. Oder, noch schlimmer, was ist, wenn es auf 1 OR is_admin = 1 gesetzt ist ?
Parametrisierte Abfragen verhindern diese Art der Injektion.
2) Bestätigen Sie Ihre Eingaben
Parametrisierte Abfragen sind großartig, aber manchmal können unerwartete Werte Probleme mit Ihrem Code verursachen. Stellen Sie sicher, dass Sie bestätigen, dass sie sich in Reichweite befinden und dass sie dem aktuellen Benutzer nicht erlauben, etwas zu ändern, was er nicht können sollte.
Beispielsweise könnten Sie ein Kennwortänderungsformular haben, das eine POST-Anforderung an ein Skript sendet, das sein Kennwort ändert. Wenn Sie ihre Benutzer-ID als versteckte Variable in das Formular einfügen, könnten sie diese ändern. Senden von id=123 statt id=321 könnte bedeuten, dass sie das Passwort einer anderen Person ändern. Stellen Sie sicher, dass ALLES in Bezug auf Typ, Reichweite und Zugriff korrekt validiert ist.
3) Verwenden Sie htmlspecialchars, um angezeigte Benutzereingaben zu maskieren
Nehmen wir an, Ihr Benutzer gibt seine "Über mich"-Adresse wie folgt ein:</div><script>document.alert('hello!');</script><div>
Das Problem dabei ist, dass Ihre Ausgabe Markups enthält, die der Benutzer eingegeben hat. Der Versuch, dies selbst mit Blacklists zu filtern, ist nur eine schlechte Idee. Verwenden Sie htmlspecialchars um die Zeichenfolgen herauszufiltern, sodass HTML-Tags in HTML-Einheiten umgewandelt werden.
4) Verwenden Sie nicht $_REQUEST
Cross-Site Request Forgery (CSRF)-Angriffe funktionieren, indem der Benutzer dazu gebracht wird, auf einen Link zu klicken oder eine URL zu besuchen, die ein Skript darstellt, das eine Aktion auf einer Website ausführt, für die er angemeldet ist. Der $_REQUEST Variable ist eine Kombination aus $_GET , $_POST und $_COOKIE , was bedeutet, dass Sie den Unterschied zwischen einer Variable, die in einer POST-Anfrage gesendet wurde (d. h. durch eine input -Tag in Ihrem Formular) oder eine Variable, die in Ihrer URL als Teil eines GET gesetzt wurde (z. B. page.php?id=1). ).
Angenommen, der Benutzer möchte jemandem eine private Nachricht senden. Sie könnten eine POST-Anforderung an sendmessage.php senden , mit to , subject und message als Parameter. Stellen wir uns nun vor, jemand sendet stattdessen eine GET-Anfrage:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Wenn Sie $_POST verwenden , werden Sie keinen dieser Parameter sehen, da sie in $_GET gesetzt sind stattdessen. Ihr Code wird $_POST['to'] nicht sehen oder eine der anderen Variablen, sodass die Nachricht nicht gesendet wird. Wenn Sie jedoch $_REQUEST verwenden , der $_GET und $_POST zusammenkleben, sodass ein Angreifer diese Parameter als Teil der URL festlegen kann. Wenn der Benutzer diese URL besucht, sendet er versehentlich die Nachricht. Der wirklich besorgniserregende Teil ist, dass der Benutzer nichts tun muss. Wenn der Angreifer eine schädliche Seite erstellt, könnte diese einen iframe enthalten das zeigt auf die URL. Beispiel:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Dies führt dazu, dass der Benutzer Nachrichten an Personen sendet, ohne jemals zu bemerken, dass sie etwas getan haben. Aus diesem Grund sollten Sie $_REQUEST vermeiden und verwenden Sie $_POST und $_GET stattdessen.
5) Behandeln Sie alles, was Sie erhalten, als verdächtig (oder sogar bösartig)
Sie haben keine Ahnung, was der Benutzer Ihnen sendet. Es könnte legitim sein. Es könnte ein Angriff sein. Vertrauen Sie niemals etwas, das Ihnen ein Benutzer geschickt hat. Konvertieren Sie in korrekte Typen, validieren Sie die Eingaben, verwenden Sie bei Bedarf Whitelists zum Filtern (vermeiden Sie Blacklists). Dazu gehört alles, was über $_GET gesendet wird , $_POST , $_COOKIE und $_FILES .
Wenn Sie diese Richtlinien befolgen, haben Sie in Bezug auf die Sicherheit einen angemessenen Stand.
