nicht angemeldet
Bei htmspecialchars immer ENT_QUOTES setzen?
Hallo allerseits,
überprüfe gerade ein älteres Projekt, in das Nutzer in Formulare Daten eingeben können. Diese können sie sich in einer Vorschau nochmal ansehen und editieren, bevor sie in einer Datenbank gespeichert werden.
Für die Speicherung in der Datenbank und die Ausgabe in der Vorschau existiert eine Funktion, die alle möglichen Fälle berücksichtigt und absichert.
Für die Übergabe der Daten über Formulare von einer Datei in die nächste wird neben magic_quotes/stripslashes jedoch nur htmspecialchars genutzt, damit der Nutzer seine Eingabe möglichst unverfälscht wieder sehen und bearbeiten kann.
Nun war ich mir unsicher, ob es besser wäre, dieses jeweils mit ENT_QUOTES zu ergänzen, oder ob einfache Anführungszeichen kein großartiges Problem für Angriffe sind.
Inzwischen frage ich mich jedoch, ob diese Übergabe der Daten durch noch mehr Befehle als nur die oben genannten abgesichert werden sollte.
Könnt ihr mir mit euren Erfahrungen helfen? Vielen Dank schonmal für etwaige Hinweise!
Erik
-
Hello,
Inzwischen frage ich mich jedoch, ob diese Übergabe der Daten durch noch mehr Befehle als nur die oben genannten abgesichert werden sollte.
Ich frage mich dabei immer, welchen Schaden die Verwendung der Option haben könnte. Hier sehe ich keinen. Also sollte man sie mMn für automatische Systeme verwenden, da man, speziell bei zusammengestöpselten Klassen oder Modulen sonst alles erst genau prüfen müsste. Dann könnte man die Klassen oder Module auch gleich selbst schreiben.
Zumindest sollte man mMn (danke Sven :-), lang ists her) nicht mehr in Entities codieren, als es für den HTML-Context in der jeweiligen Codierung notwendig ist.
Die Funktion htmlspecialchars() behandelt nur die sechs Fälle, die in HTML _Sonderbedeutung_ haben.
http://de.php.net/manual/en/function.htmlspecialchars.php* '&' (Ampersand/kaufmännisches Und) wird zu '&'.
* '"' (doppeltes Anführungszeichen) wird zu '"', wenn ENT_NOQUOTES nicht gesetzt ist.
* ''' (einfaches Anführungszeichen) wird nur zu ''', wenn ENT_QUOTES gesetzt ist.
* '<' (kleiner als) wird zu '<'
* '>' (größer als) wird zu '>'Sie behandelt nicht die Fälle, die in HTML ebenfalls zu Fehlern führen könnten, wie z.B NUL (Ascii 0).
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Inzwischen frage ich mich jedoch, ob diese Übergabe der Daten durch noch mehr Befehle als nur die oben genannten abgesichert werden sollte.
Bevor sich da jemand beschwert: das Nachfolgende bezog sich nur auf das '-Zeichen. Das habe ich aber irgendwie im OP-Text mit rausgeslöscht *tztz*
Ich frage mich dabei immer, welchen Schaden die Verwendung der Option haben könnte. Hier sehe ich keinen. Also sollte man sie mMn für automatische Systeme verwenden, da man, speziell bei zusammengestöpselten Klassen oder Modulen sonst alles erst genau prüfen müsste. Dann könnte man die Klassen oder Module auch gleich selbst schreiben.
Zumindest sollte man mMn (danke Sven :-), lang ists her) nicht mehr in Entities codieren, als es für den HTML-Context in der jeweiligen Codierung notwendig ist.
Die Funktion htmlspecialchars() behandelt nur die sechs Fälle, die in HTML _Sonderbedeutung_ haben.
http://de.php.net/manual/en/function.htmlspecialchars.php* '&' (Ampersand/kaufmännisches Und) wird zu '&'.
* '"' (doppeltes Anführungszeichen) wird zu '"', wenn ENT_NOQUOTES nicht gesetzt ist.
* ''' (einfaches Anführungszeichen) wird nur zu ''', wenn ENT_QUOTES gesetzt ist.
* '<' (kleiner als) wird zu '<'
* '>' (größer als) wird zu '>'Sie behandelt nicht die Fälle, die in HTML ebenfalls zu Fehlern führen könnten, wie z.B NUL (Ascii 0).
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Sie behandelt nicht die Fälle, die in HTML ebenfalls zu Fehlern führen könnten, wie z.B NUL (Ascii 0).
In der HTML-Spezifikation (4.01) konnte ich im Charset-Kapitel keine Erwähnung. Prinzipiell müssen die Browser auch mit NUL-Bytes im Datenstrom umgehen können, sonst könnten sie nicht UTF-16 als Kodierung annehmen. Wo also macht NUL Probleme?
Lo!
-
Moin Moin!
Sie behandelt nicht die Fälle, die in HTML ebenfalls zu Fehlern führen könnten, wie z.B NUL (Ascii 0).
In der HTML-Spezifikation (4.01) konnte ich im Charset-Kapitel keine Erwähnung. Prinzipiell müssen die Browser auch mit NUL-Bytes im Datenstrom umgehen können, sonst könnten sie nicht UTF-16 als Kodierung annehmen. Wo also macht NUL Probleme?
Ich denke, Du verwechselst Bytes und Zeichen. Das Zeichen mit dem Code 0 (NUL) ist wohl nicht erlaubt, jedenfalls nicht in XML. Dass bei UTF-16 und erst recht UTF-32 jede Menge 0x00-Bytes unterwegs sind, ist eine völlig andere Geschichte, eine Ebene unterhalb der Zeichen.
Dass man in XML das NUL-Zeichen nicht erlaubt, verstehe ich auch nicht so wirklich. Auf den ersten Blick stinkt das ganz fürchterlich danach, dass man Problemen mit NUL in XML-Parser-Libraries aus dem Weg gehen wollte. In C und einigen Derivate gilt NUL als Stringende und ist daher innerhalb eines Strings nicht abbildbar.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi!
Sie behandelt nicht die Fälle, die in HTML ebenfalls zu Fehlern führen könnten, wie z.B NUL (Ascii 0).
In der HTML-Spezifikation (4.01) konnte ich im Charset-Kapitel keine Erwähnung. Prinzipiell müssen die Browser auch mit NUL-Bytes im Datenstrom umgehen können, sonst könnten sie nicht UTF-16 als Kodierung annehmen. Wo also macht NUL Probleme?
Ich denke, Du verwechselst Bytes und Zeichen.Nein, ich weiß aber auch nicht, was Tom konkret gemeint hat. Mit ASCII-0 könnte er ein Byte gemeint haben. Für HTML gilt ansonsten Unicode und da wäre U+0000 eine passendere und eindeutige Bezeichnung.
Und warum soll man es behandeln? Dann käme auch nur � raus, was der Browser ja wieder in seine interne Darstellung von U+0000 umwandeln müsste ...
Dass man in XML das NUL-Zeichen nicht erlaubt, verstehe ich auch nicht so wirklich. Auf den ersten Blick stinkt das ganz fürchterlich danach, dass man Problemen mit NUL in XML-Parser-Libraries aus dem Weg gehen wollte. In C und einigen Derivate gilt NUL als Stringende und ist daher innerhalb eines Strings nicht abbildbar.
... und hätte das Problem nicht gelöst.
Lo!
-
-
-
-
Hi!
Für die Speicherung in der Datenbank und die Ausgabe in der Vorschau existiert eine Funktion, die alle möglichen Fälle berücksichtigt und absichert.
Diese ist vermutlich völlig überladen. Man braucht _jeweils_ nur _eine_ Funktion für das _konkrete_ Ausgabemedium, nicht eine für alle. Wenn du im DBMS bereits Maskierungen für beispielsweise HTML drin hast, kann sie unter anderem nicht mehr richtig sortieren, weil sie dabei immer die HTML-Zeichen berücksichtigt. Jedes Medium sollte mit Rohdaten gefüllt werden, die lediglich für den Transport über Textschnittstellen für exakt diese Schnittstelle maskiert werden müssen.
Für die Übergabe der Daten über Formulare von einer Datei in die nächste wird neben magic_quotes/stripslashes jedoch nur htmspecialchars genutzt, damit der Nutzer seine Eingabe möglichst unverfälscht wieder sehen und bearbeiten kann.
Nun war ich mir unsicher, ob es besser wäre, dieses jeweils mit ENT_QUOTES zu ergänzen, oder ob einfache Anführungszeichen kein großartiges Problem für Angriffe sind.Du scheinst noch nicht verstanden zu haben, was da konkret wogegen gesichert werden muss, sonst stellt sich diese Frage gar nicht mehr. Anführungszeichen ob doppelt oder einfach müssen nur für Werte in HTML-Attributen berücksichtigt werden. Wenn du diese immer in " einrahmst, brauchst du nur das " in den Daten zum " zu machen. Das ' muss nur bei Attributen in '' berücksichtigt werden. Wenn du aber weiterhin eine eierlegende Wollmilchsau schreiben willst, musst du auch den '-Fall berücksichtigen.
Inzwischen frage ich mich jedoch, ob diese Übergabe der Daten durch noch mehr Befehle als nur die oben genannten abgesichert werden sollte.
Könnt ihr mir mit euren Erfahrungen helfen?Die hab ich alle im Kontextwechsel-Artikel zusammengefasst.
Lo!