Was sind die Best Practices zur Vermeidung von xss-Angriffen auf einer PHP-Site [closed]

Ich habe PHP so konfiguriert, dass magische Anführungszeichen aktiviert und Register Globals deaktiviert sind.

Ich tue mein Bestes, immer htmlentities() für alles aufzurufen, was ich ausgebe und das von Benutzereingaben abgeleitet ist.

Gelegentlich durchsuche ich meine Datenbank auch nach häufigen Dingen, die in xss-Anhängen verwendet werden, wie zum Beispiel …

<script

Was sollte ich sonst noch tun und wie kann ich sicherstellen, dass die Dinge, die ich zu tun versuche, auch so sind immer fertig.

Eingaben zu umgehen ist nicht das Beste, was Sie für eine erfolgreiche XSS-Prävention tun können. Auch die Ausgabe muss maskiert werden. Wenn Sie die Smarty-Vorlagen-Engine verwenden, können Sie verwenden |escape:'htmlall' Modifikator zum Konvertieren aller sensiblen Zeichen in HTML-Entitäten (ich verwende eigene |e Modifikator, der ein Alias ​​für den obigen ist).

Mein Ansatz zur Ein-/Ausgabesicherheit ist:

• Benutzereingaben nicht geändert speichern (kein HTML-Escape bei der Eingabe, nur DB-bewusstes Escaping über vorbereitete PDO-Anweisungen)
• Escape bei der Ausgabe, je nachdem, welches Ausgabeformat Sie verwenden (z. B. HTML und JSON benötigen unterschiedliche Escape-Regeln)

Ich bin der Meinung, dass man bei der Eingabe nichts maskieren sollte, sondern nur bei der Ausgabe. Da Sie (meistens) nicht davon ausgehen können, dass Sie wissen, wohin diese Daten gehen. Wenn Sie beispielsweise ein Formular haben, das Daten entgegennimmt, die später in einer von Ihnen versendeten E-Mail erscheinen, benötigen Sie ein anderes Escaping (andernfalls könnte ein böswilliger Benutzer Ihre E-Mail-Kopfzeilen umschreiben).

Mit anderen Worten, Sie können nur im allerletzten Moment entkommen, wenn die Daten Ihre Anwendung “verlassen”:

• Listenpunkt
• In XML-Datei schreiben, Escape für XML
• In DB schreiben, Escape (für dieses bestimmte DBMS)
• E-Mail schreiben, für E-Mails entkommen
• etc

Um es kurz zu machen:

1. Sie wissen nicht, wohin Ihre Daten gehen
2. Daten können tatsächlich an mehr als einem Ort landen und unterschiedliche Escape-Mechanismen benötigen, ABER NICHT BEIDE
3. Daten, die für das falsche Ziel entkommen sind, sind wirklich nicht schön. (z. B. eine E-Mail mit dem Betreff “Geh zu Tommy\’s Bar”.)

Esp Nr. 3 tritt auf, wenn Sie Daten auf der Eingabeebene maskieren (oder Sie müssen sie erneut demaskieren usw.).

PS: Ich schließe mich dem Rat an, magic_quotes nicht zu verwenden, das ist das pure Böse!

Es gibt viele Möglichkeiten, XSS durchzuführen (siehe http://ha.ckers.org/xss.html) und es ist sehr schwer zu fangen.

Ich delegiere dies persönlich an das aktuelle Framework, das ich verwende (z. B. Code Igniter). Obwohl es nicht perfekt ist, könnte es mehr einfangen als meine handgemachten Routinen es jemals tun.

Das ist eine großartige Frage.

Erstens sollten Sie Text bei der Eingabe nicht mit Escapezeichen versehen, außer um ihn für die Speicherung sicher zu machen (z. B. um ihn in eine Datenbank zu stellen). Der Grund dafür ist, dass Sie die Eingaben behalten möchten, damit Sie sie kontextuell auf verschiedene Arten und an verschiedenen Orten präsentieren können. Wenn Sie hier Änderungen vornehmen, kann dies Ihre spätere Präsentation beeinträchtigen.

Wenn Sie Ihre Daten präsentieren, filtern Sie heraus, was nicht vorhanden sein sollte. Wenn es beispielsweise keinen Grund für Javascript gibt, suchen Sie danach und entfernen Sie es. Eine einfache Möglichkeit, dies zu tun, ist die Verwendung von strip_tags funktionieren und nur die HTML-Tags präsentieren, die Sie zulassen.

Als nächstes nehmen Sie, was Sie haben, und übergeben Sie es mit den Gedanken htmlentities oder htmlspecialchars, um das, was da ist, in ASCII-Zeichen umzuwandeln. Tun Sie dies basierend auf dem Kontext und dem, was Sie herausbekommen möchten.

Ich würde auch vorschlagen, Magic Quotes auszuschalten. Es wurde aus PHP 6 entfernt und wird als schlechte Praxis angesehen, es zu verwenden. Einzelheiten unter http://us3.php.net/magic_quotes

Weitere Informationen finden Sie unter http://ha.ckers.org/xss.html

Dies ist keine vollständige Antwort, aber hoffentlich genug, um Ihnen den Einstieg zu erleichtern.

rich schreibt:

Ich tue mein Bestes, immer htmlentities() für alles aufzurufen, was ich ausgebe und das von Benutzereingaben abgeleitet ist.

Siehe Joels Essay auf Code falsch aussehen lassen um Hilfe dabei

Vorlagenbibliothek. Zumindest sollten Vorlagenbibliotheken das tun. Um XSS zu verhindern alle Ausgabe sollte verschlüsselt werden. Dies ist nicht die Aufgabe der Hauptanwendung / Steuerlogik, sondern sollte ausschließlich von den Ausgabemethoden erledigt werden.

Wenn Sie htmlentities() durch Ihren Code streuen, ist das Gesamtdesign falsch. Und wie Sie vorschlagen, könnten Sie ein oder zwei Stellen verpassen. Deshalb ist die einzige Lösung eine rigorose HTML-Kodierung -> wann Ausgabevariablen werden in einen HTML/XML-Stream geschrieben.

Leider fügen die meisten PHP-Template-Bibliotheken nur ihre eigene Template-Syntax hinzu, kümmern sich aber nicht um Ausgabecodierung, Lokalisierung oder HTML-Validierung oder irgendetwas Wichtiges. Vielleicht kennt jemand anderes eine richtige Template-Bibliothek für PHP?

Ich verlasse mich auf PHPTAL dafür.

Im Gegensatz zu Smarty und einfachem PHP maskiert es standardmäßig alle Ausgaben. Dies ist ein großer Gewinn für die Sicherheit, da Ihre Website nicht angreifbar wird, wenn Sie dies vergessen htmlspecialchars() oder |escape irgendwo.

XSS ist ein HTML-spezifischer Angriff, daher ist die HTML-Ausgabe der richtige Ort, um ihn zu verhindern. Sie sollten nicht versuchen, Daten in der Datenbank vorzufiltern, da Sie möglicherweise Daten auf ein anderes Medium ausgeben müssen, das kein HTML akzeptiert, aber seine eigenen Risiken birgt.