Es ist noch einfacher. Nur htmlspecialchars() (mit Anführungszeichen und Zeichensatz) für benutzergesteuerte Eingaben ist ausreichend. % Co_de% ist nur dann nützlich, wenn Sie bereits Daten vor der Verarbeitung / Speicherung in der Datenbank bereinigen möchten, die in der Praxis oft nicht verwendet wird. HTML-Code schadet nicht in der PHP-Quelle, aber PHP-Code kann dies tun, wenn Sie strip_tags() für nicht-bereinigte, benutzergesteuerte Eingaben oder diese Art von bösen Sachen verwenden.
Dies rettet Sie jedoch nicht vor SQL-Injektionen , aber das ist eine andere Geschichte.
Aktualisieren : Um saubere Benutzereingaben von der Anfrage zu erhalten, um Magie zu vermeiden Anführungszeichen in benutzergesteuerter Eingabe können Sie die folgende Funktion verwenden:
%Vor%kann wie folgt verwendet werden:
%Vor% (Sie können dies für eval() , get_number , get_boolean usw. tun)
Um die SQL-Abfrage so vorzubereiten, dass SQL-Injektionen vermieden werden, tun Sie Folgendes:
%Vor%Um vom Benutzer gesteuerte Eingaben anzuzeigen, um XSS zu vermeiden, tun Sie Folgendes:
%Vor%Es hängt davon ab, wo und wie Sie die Benutzerdaten verwenden möchten. Sie müssen den Kontext kennen, in den Sie Ihre Daten einfügen möchten, und die Metazeichen dieses Kontextes.
Wenn Sie dem Benutzer nur erlauben möchten, Text auf Ihrer Website zu platzieren, reicht htmlspecialchars aus, um den HTML-Metazeichen zu entkommen. Wenn Sie jedoch einen bestimmten HTML-Code zulassen oder Benutzerdaten in vorhandene HTML-Elemente einbetten möchten (z. B. eine URL in ein A / IMG -Element), reicht htmlspecialchars nicht aus, da Sie sich nicht mehr im HTML-Kontext befinden aber im URL-Kontext.
Wenn Sie also <script>alert("xss")</script> in ein Bild-URL-Feld eingeben, erhalten Sie:
Aber die Eingabe von javascript:alert("xss") wird erfolgreich sein:
Hier sollten Sie einen Blick auf das fabelhafte XSS (Cross Site Scripting) -Schatzblatt werfen, um zu sehen, welche Kontexte Ihr Benutzer hat Daten können injiziert werden.
strip_tags ist nicht notwendig. In den meisten Fällen ist strip_tags nur irritierend, weil einige Ihrer Benutzer < und > in ihren Texten verwenden möchten. Verwenden Sie einfach htmlspecialchars (oder htmlentities, wenn Sie bevorzugen), bevor Sie die Texte im Browser echo.
(Vergessen Sie nicht mysql_real_esacpe_string, bevor Sie etwas in Ihre Datenbank einfügen!)
Die allgemeine Regel lautet "Filter Input, Escape Output". Die Verwendung von strip_tags auf Ihrer Eingabe, um HTML zu entfernen, ist eine gute Idee für die Eingabefilterung, aber Sie sollten so streng wie möglich in der Eingabe sein, die Sie zulassen. Wenn zum Beispiel ein Eingabeparameter nur eine Ganzzahl sein soll, akzeptieren Sie nur numerische Eingaben und konvertieren sie immer in eine ganze Zahl, bevor Sie irgendetwas damit machen. Eine gut abgesicherte Eingabefilter-Bibliothek wird Ihnen hier sehr helfen; eine, die nicht für einen bestimmten Rahmen spezifisch ist, ist Inspekt (was ich geschrieben habe, also bin ich ein bisschen voreingenommen).
Für die Ausgabe, htmlspecialchars sollte in der Lage sein, XSS-Attacken zu entkommen, aber nur, wenn Sie die richtigen Parameter übergeben . Sie müssen den Anführungszeichen-Stil und an einen Zeichensatz übergeben.
Im Allgemeinen sollte XSS-Angriffe entfernen:
%Vor% Ohne Angabe von ENT_QUOTES als zweiten Parameter werden die einzelnen Anführungszeichen nicht codiert. Darüber hinaus wurden XSS-Angriffe demonstriert, wenn der korrekte Zeichensatz nicht übergeben wurde (normalerweise ist UTF-8 ausreichend). htmlspecialchars sollte immer mit ENT_QUOTES und einem Zeichensatzparameter aufgerufen werden.
Beachten Sie, dass PHP 5.2.12 einen Fix für einen Multibyte-XSS-Angriff enthält.
Sie können den OWASP ESAPI PHP-Port interessant und nützlich finden, obwohl die PHP-Version nicht vollständig ist AFAIK.
Ja, PDO Prepared Statements schützen vor SQL-Injection. Der SQL-Injection-Angriff basiert auf der Tatsache, dass die vom Angreifer übermittelten Daten als Teil der Abfrage behandelt werden. Beispielsweise übermittelt der Angreifer die Zeichenfolge "a" oder "a"="a" als sein Kennwort. Anstatt die gesamte Zeichenfolge mit den Kennwörtern in der Datenbank zu vergleichen, wird sie in die Abfrage eingeschlossen. Daher lautet die Abfrage "SELECT * FROM Benutzer WHERE login = 'joe' AND password = 'a' oder 'a' = 'a' ". Der Teil der Angreifereingabe wird als Teil der Abfrage interpretiert. Bei vorbereiteten Anweisungen teilen Sie der SQL-Engine jedoch ausdrücklich mit, welcher Teil die Abfrage ist und welcher Teil Daten sind (durch Festlegen der Parameter), sodass eine solche Verwirrung nicht möglich ist.
Nein, die Verwendung von strip_tags schützt Sie nicht immer vor Cross-Site-Scripting. Betrachten Sie das folgende Beispiel. Angenommen, Ihre Seite enthält:
%Vor%Der Angreifer übermittelt die Anfrage mit "Sprache" auf "'; somethingingvil ();". strip_tags () gibt diese Daten unverändert zurück (es sind keine Tags vorhanden). Der erzeugte Seitencode wird zu:
%Vor%somethingingevil () wird ausgeführt. Ersetzen Sie somethingingvil () durch den tatsächlichen XSS-Exploit-Code.
Ihr letztes Beispiel mit htmlspecialchars () wird davor schützen, weil es einfache Anführungszeichen vermeidet. Ich habe jedoch noch merkwürdigere Fälle von benutzerdefinierten Daten innerhalb von JavaScript-Code gesehen, wo es nicht einmal in einer Zeichenfolge in Anführungszeichen steht. Ich denke, es war in der Variablen oder Funktionsname. In diesem letzten Fall wird wahrscheinlich kein Austreten mehr helfen. Ich glaube, es ist am besten zu vermeiden, Benutzereingaben zu verwenden, um JavaScript-Code zu generieren.
Einfache Antwort: Nein
Längere Antwort: Es gibt Möglichkeiten, XSS zu injizieren, die PHP strip_stags nicht vermeiden kann.
Zum besseren Schutz sollten Sie HTML purifier
ausprobierenTags und Links html php xss sql-injection