Sichere XSS-Reinigungs-Funktion (regelmäßig aktualisiert)
Ich habe auf der Jagd gewesen um das Netz jetzt ein paar Tage versucht, dies herauszufinden, aber immer widersprüchliche Antworten.
Gibt es eine Bibliothek, die Klasse oder die Funktion für PHP, die sicher bereinigt/kodiert einen string gegen XSS? Es muss regelmäßig aktualisiert werden, um gegen neue Angriffe.
Habe ich ein paar Anwendungsfälle:
Use case 1) ich habe eine plain-text-Feld, sagen wir für einen vor-oder Nachnamen
- Benutzer text in das Feld ein und sendet das Formular
- Bevor diese in der Datenbank gespeichert werden will ich a) trim alle Leerzeichen aus der Vorder-und
Ende der Zeichenfolge, und b) Streifen alle HTML-tags aus der Eingabe. Es ist ein name-text-Feld, sollten Sie keine HTML. - Dann Speichere ich diese in die Datenbank mit PDO prepared statements.
Dachte ich, ich könnte einfach tun trim()
und strip_tags()
dann mit einem Sanitize Filter oder RegEx mit einer whitelist von Zeichen. Tun Sie wirklich brauchen Zeichen wie ! und ? oder <
>
in Ihrem Namen, nicht wirklich.
Use case 2)Wenn er den Inhalt aus einer zuvor gespeicherten Datenbank-Datensatz (oder von einem zuvor eingereichten Formular), um die Ansicht/HTML-ich will, um gründlich zu reinigen Sie es für XSS. NB: Es kann oder kann nicht haben gegangen durch die Filterung Schritt im use case 1, wie es sein könnte eine andere Art von input, also übernehmen keine Desinfektion durchgeführt wurde.
Zunächst dachte ich HTMLPurifier würde die Arbeit machen, aber wie es scheint, ist es nichtwas ich brauche, wenn Ich stellte die Frage an Ihren support:
Hier ist der Lackmus-test: wenn ein Nutzer
<b>foo</b>
sollte es zeigen, wie<b>foo</b>
oder foo? Wenn der ehemalige, brauchen Sie kein HTML Purifier.
Also ich würde eher es zeigte sich als <b>foo</b>
weil ich nicht will, beliebigen HTML angezeigt, ein einfaches Textfeld oder ein JavaScript ausführen.
Also ich habe auf der Jagd gewesen herum für eine Funktion, die tun alles für mich. Ich stolperte über die xss_clean Methode, die von Kohana 3.0die ich vermute, funktioniert aber nur, wenn Sie möchten, um den HTML-Code. Es ist jetzt als veraltet markiert von Kohana 3.1 wie haben Sie ersetzt es mit HTMLPurifier. Also ich vermute Sie tun sollen HTML::chars()
statt, die nur tut,dieser code:
public static function chars($value, $double_encode = TRUE)
{
return htmlspecialchars( (string) $value, ENT_QUOTES, Kohana::$charset, $double_encode);
}
Nun scheinbar bist du ja verwenden sollte htmlentitiesanstatt, wie erwähnt in ganz wenigen Orte in der Stack-Überlaufweil es sicherer ist als htmlspecialchars.
- So wie ich benutze htmlentities
richtig? - Ist, dass alles, was ich brauche?
- Wie funktioniert es Schutz gegen hex -, dezimal-und base64-codierte Werte gesendet wird, die Angriffe aufgeführt hier?
Nun sehe ich, dass der 3. parameter für die htmlentities-Methode ist den verwendeten Zeichensatz bei der Konvertierung. Jetzt meine Website/db ist in UTF-8, aber vielleicht ist die form übermittelten Daten nicht UTF-8 codiert ist, wird Sie vielleicht eingereicht ASCII-oder HEX-also vielleicht muss ich es konvertieren zu UTF-8 in der ersten? Das würde bedeuten, dass einige code wie:
$encoding = mb_detect_encoding($input);
$input = mb_convert_encoding($input, 'UTF-8', $encoding);
$input = htmlentities($input, ENT_QUOTES, 'UTF-8');
Ja oder Nein? Dann bin ich mir noch nicht sicher, wie Sie Sie schützen gegen die hex, dezimal und base64 mögliche XSS-Eingänge...
Wenn es einige Bibliotheken oder open-source-PHP-framework, das tun kann, XSS-Schutz richtig ich wäre daran interessiert zu sehen, wie Sie es in den code.
Jede Hilfe viel geschätzt, sorry für den langen post!
InformationsquelleAutor der Frage zuallauz | 2011-06-17
Du musst angemeldet sein, um einen Kommentar abzugeben.
Antwort auf die mutige Frage: ja, gibt es. Es heißt
htmlspecialchars
.Den richtigen Weg zur Verhinderung von XSS-Angriffen ist nicht die Abwehr bestimmter Angriffe, filtern/bereinigen von Daten, aber richtige Verschlüsselungüberall.
htmlspecialchars
(oderhtmlentities
) in Verbindung mit einer angemessenen Entscheidung der Zeichen-Codierung (d.h.UTF-8
) und die explizite Angabe der Zeichen-Codierung ausreichend ist, um zu verhindern, dass gegen alle XSS-Angriffe. Glücklicherweise, nanntehtmlspecialchars
ohne explizite Codierung(es übernimmt dann ISO-8859-1) passiert, für UTF-8, auch. Wenn Sie wollen, dass explizite, erstellen eine Hilfsfunktion:Oh, und die form sorgen: versuchen Sie nicht zu erkennen, Codierungen, es ist zum scheitern verurteilt. Stattdessen geben Sie das Formular in der UTF-8. Jeder browser schickt der Benutzer Eingaben in UTF-8 dann.
Die besonderen Belange:
UTF-7 XSS-exploit kann nur angewendet werden, wenn der browser denkt, dass ein Dokument kodiert in UTF-7. Die Angabe der Kodierung als UTF-8 (in den HTTP-header/meta-tag direkt nach
<head>
) wird dies verhindert.Diesem Angriffsszenario ist unnötig Komplex. Der Angreifer Handwerk eine UTF-7 string, keine Notwendigkeit, etwas herunterzuladen.
Wenn Sie annehmen, die Angreifer in die POST (d.h. Sie akzeptieren anonyme Benutzer public input), wird Ihr server einfach zu interpretieren, die UTF-7-string, wie eine seltsame UTF-8. Das ist kein problem, die Angreifer in die post einfach nur zeigen, verstümmelt. Der Angreifer könnte den gleichen Effekt erzielen (der Versand seltsamen text) durch das Absenden "grfnlk" hundert mal.
Nein, es nicht. Codierungen sind nicht magisch. Eine Codierung ist nur eine Weise zu interpretieren, ein Binär-string. Zum Beispiel der string "ö" wird codiert als (hexadezimal)
2B 41 50 59
in UTF-7 (undC3 B6
im UTF-8). Dekodierung2B 41 50 59
als UTF-8 ergibt "+APY" - Harmlose, scheinbar zufällig Zeichen.Hexadezimal-Daten ausgegeben werden als nur das. Ein Angreifer senden "3C" wird eine Nachricht "3C". "3C" kann nur geworden
<
wenn Sie aktiv versuchen, Sie zu interpretieren hexadezimale Eingaben anders, zum Beispiel aktiv anzeigen in unicode-Codepunkte und dann ausgegeben werden. Das bedeutet nur, wenn Sie die Annahme von Daten in etwas, aber nur UTF-8 (z.B. base32-kodierten UTF-8), müssen Sie zunächst entpacken Sie Ihre Codierung und dann Verwendunghtmlspecialchars
bevor es zwischen HTML-code.InformationsquelleAutor der Antwort phihag
Viele Sicherheits-Ingenieure sind zu empfehlen, um diese Bibliothek verwenden, die für dieses spezielle problem :
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
InformationsquelleAutor der Antwort Olivier