Cross Site Scripting abwehren
1 1 1 
dedlfix
1 
Der Martin
0 0 0 dedlfix
1
Cross Site Scripting abwehren
Hallo,
zu dem obigen Thema hätte ich folgende Frage:
Da Cross Site Scripting immer über das Einfügen von Programmier-Code funktioniert, und dieser, weil der Code ja in einem Formular einer HTML-Seite eingegeben wird, zum Erkennen vom entsprechenden Parsern immer mit den Zeichen "<" und ">" daher kommt, müsste es doch für den FormularMailer-"Normalfall", also Anfrage bezüglich Artikel oder Kritik oder Meinung äußern, vollkommen ausreichen, wenn ich einfach das Größerals- und das Kleinerals-Zeichen aus dem Text entferne und z.B. dem Nutzer einen Hinweis ausgeben, dass solche Zeichen nicht erlaubt sind.
Ist das richtig?
Und noch eine Frage zu diesem Thema:
Wenn ich per JavaScript garantieren kann, dass die $_POST Variable sozusagen sauber ist, muss (oder sollte) ich dann in PHP bei weiterer Verarbeitung der Daten und Ausgabe in HTML trotzdem noch zur Sicherheit htmlentities() verwenden?
Habe ich hier den Zusammenhang richtig verstanden?
Beste Grüße
Gerrit
-
Wenn ich per JavaScript garantieren kann, dass die $_POST Variable sozusagen sauber ist, muss (oder sollte) ich dann in PHP bei weiterer Verarbeitung der Daten und Ausgabe in HTML trotzdem noch zur Sicherheit htmlentities() verwenden?
Wenn du das per JavaScript garantieren kannst, ja. Aber du kannst nichts mit clientseitigem JavaScript garantieren. Jeder der etwas böses tun will und bemerkt, dass dein JS ihn daran hindert wird es einfach abschalten (oder entsprechende Teile des Codes deaktivieren/lokal entfernen).
Bei serverseitigem JS ist's natürlich was anderes.
Lass das JS einfach weg an der Stelle und prüf' nur serverseitig. Doppelt hilft auch nicht besser :)--
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:( -
... müsste es doch für den FormularMailer-"Normalfall", ... vollkommen ausreichen, wenn ich einfach das Größerals- und das Kleinerals-Zeichen aus dem Text entferne und z.B. dem Nutzer einen Hinweis ausgeben, dass solche Zeichen nicht erlaubt sind.
Nicht entfernen, sondern maskieren!
Wenn ich per JavaScript garantieren kann, dass die $_POST Variable sozusagen sauber ist,
Kannst du nicht, weil $_POST für javascript unsichtbar ist und bleibt...
muss (oder sollte) ich dann in PHP bei weiterer Verarbeitung der Daten und Ausgabe in HTML trotzdem noch zur Sicherheit htmlentities() verwenden?
Auf jeden Fall htmlspecialchars().
htmlentities() ist Fehl am Platz.Ich brauche dein Formular nicht um deine serverseitige API zu verwenden.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische -
Hi!
zu dem obigen Thema hätte ich folgende Frage:
Die hoffentlich mit dem Thema Kontextwechsel beantwortet wird.
Lo!
-
Hi,
Da Cross Site Scripting immer über das Einfügen von Programmier-Code funktioniert, und dieser, weil der Code ja in einem Formular einer HTML-Seite eingegeben wird, zum Erkennen vom entsprechenden Parsern immer mit den Zeichen "<" und ">" daher kommt, müsste es doch für den FormularMailer-"Normalfall", also Anfrage bezüglich Artikel oder Kritik oder Meinung äußern, vollkommen ausreichen, wenn ich einfach das Größerals- und das Kleinerals-Zeichen aus dem Text entferne und z.B. dem Nutzer einen Hinweis ausgeben, dass solche Zeichen nicht erlaubt sind.
nein, du brauchst diese Zeichen nicht zu entfernen, sondern nur korrekt zu maskieren, wenn du sie in einen Kontext bringst, in dem sie eine Sonderbedeutung haben. Bringst du einen Text in HTML-Kontext, solltest du bei der Ausgabe (und erst dann!) die Zeichen '<', '>' durch < und > ersetzen.
Wenn ich per JavaScript garantieren kann, ...
Kannst du nicht. Dein PHP-Script kann auch aufgerufen werden, ohne dass irgendein JS vorher für Ordnung sorgt - sogar ganz ohne Formular, oder mit einem ganz anderen Formular als deinem eigenen.
dass die $_POST Variable sozusagen sauber ist, muss (oder sollte) ich dann in PHP bei weiterer Verarbeitung der Daten und Ausgabe in HTML trotzdem noch zur Sicherheit htmlentities() verwenden?
Nein. Du solltest die Daten bei der Verarbeitung in PHP zunächst unverändert übernehmen, so wie sie im Request übergeben wurden. Erst bei der Übertragung z.B. in eine DB oder zurück in HTML solltest du sie in geeigneter Weise aufbereiten. Aber bitte nicht htmlentities(), denn htmlspecialchars() genügt völlig und verunstaltet keine Zeichen, ohne dass es nötig wäre.
So long,
Martin--
Wenn die Amerikaner eines Tages von jeder Tierart ein Pärchen nach Cape Canaveral treiben ...
ja, DANN sollte man endlich misstrauisch werden.
-
[latex]Mae govannen![/latex]
Wenn ich per JavaScript garantieren kann, ...
Kannst du nicht. Dein PHP-Script kann auch aufgerufen werden, ohne dass irgendein JS vorher für Ordnung sorgt - sogar ganz ohne Formular, oder mit einem ganz anderen Formular als deinem eigenen.
Oder sogar ganz ohne daß überhaupt ein Browser dahintersteckt (nur zur Vervollständigung).
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken in Richtung "Mess up the Web". (suit)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
-
Danke Euch beiden!
Gruß
Gerrit -
Äh, oha, danke an alle, natürlich :-)
All Eure Hinweise haben mir sehr geholfen! Und ich sterb jetzt weit weniger dumm...Ein hab ich noch:
Sollte man bei htmlspecialchars()ENT_QUOTES verwenden?Gruß
Gerrit-
Hi!
Ein hab ich noch:
Sollte man bei htmlspecialchars()ENT_QUOTES verwenden?Das kommt darauf an, wo du es anwendest. Im HTML-Kontext schadet ebensowenig wie generell die " durch " auszutauschen, aber zwingend notwendig ist es nur, wenn man sich in einem Attributwert befindet der mit '' eingefasst ist (respektive "" bei "). In einem <script>- und <style>-Bereich bilden allerdings eine Ausnahme.
Lo!
-
-
Hello,
Ist das richtig?
Es ist nicht richtig, dass Cross-Site-Scripting und Form-Hijacking immer über die Dialogelemente des Formulares eingeschluest werden. Diese können auch über die URL eingeschluest werden, wenn man z.B. bei PHP-Scripten ein $_SERVER['SELF_PHP'] ohne weitere Maßnahmen als Action-Attribut einsetzt.
Dann kann das Formular, auf das man einen eigenen manipulierenden Link setzt, entführt werden. Die Seite wird vom Originalserver des Originalanbieters geladen und ganz normal angezeigt (und ausgeführt...), aber beim nächsten Request per <form> landet dieser beim Manipulator.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
