htmlentities vor/nach dem Speichern

[Klaus]

Tag,
also wie ihr das alle kennt, man hat diverse Eingaben von Benutzern, die man speichert und an anderer Stelle wieder ausgibt.

Damit der User jetzt keinen HTML Code ausgeben kann, behandelt man diese Daten ja mit htmlentities oder strips_tags.

Jetzt stellt sich die Frage für mich, ob ich diese "Behandlung", beim Speichern oder bei der Ausgabe durchführen soll.

Also beim Speichern hätte es folgende Vorteile:
Mit einem kleinen Script kann man jede Information die vom User kommt (POST, GET, COOKIE, SESSIOn etc.) per htmlentities behandeln.

function makeon($v) {
   return is_array($v) ? array_map('makeon', $v) : htmlentities($v);
}

function htmloff() {
   foreach (array('POST', 'GET', 'REQUEST', 'COOKIE', 'SESSION') as $gpc)
   $GLOBALS["_$gpc"] = array_map('makeon', $GLOBALS["_$gpc"]);
}
htmloff();

Dieser kleine Schnipsel in jede Datei eingebunden, und alle Eingaben von dem Benutzer werden "behandelt".

Somit würde man nicht vergessen irgendwo diese Ersetzung durchzuführen => keine Angriffsmöglichkeiten mehr für den Benutzer.

Jetzt wollte ich euch mal fragen, wie Ihr das Problem seht. Denn HTML Code soll ja normalerweise nicht ausgegeben werden, und wenn doch, dann bindet man in der Datei, die keinen PHP Code ausgeben soll, den Script nicht ein.
Oder gibt es sonst noch Einwände warum man es nicht so machen sollte?

Oder wie schützt ihr euch gegen HTML Code von einem Benutzer? Oder ist es doch besser, jede Ausgabe per htmlentities() zu behandeln?

Grüße Klaus

[Tom]

Hello,

1. in die Datgenbasis sollten nur abgesicherte und valide Rohdaten eingetragen werden
   Rohdaten enthalten keine Formatierungsangaben für das jeweilige Ausgabemedium

daraus ergibt sich

2. Vor dem Wegschreiben der Daten sollte man z.B. strip_slashes() durchführen,
   Daten validieren und richtigstellen...

3. Die Ausgabeformatierung findet erst statt, wenn das Ausgabemedium und dessen Regeln
   feststehen. htmlentities() werden damit also erst bei Bedarf zur Ausgabzeit fällig.

Ich hoffe, ich konnte den Knoten beseitigen helfen.

Ausnahmen gibt's natürlich trotzdem noch.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Klaus]

Hallo,
naja nen Script nachträlich zu überprüfen ist nicht so schön ^^.

Aber kennt jmd. evt. ein Tool, welches ein Script auf XSS Schwächen testet?

Grüße Klaus

[Tom]

Hello,

naja nen Script nachträlich zu überprüfen ist nicht so schön ^^.

Wie ist das jetzt gemeint?
Verstehe ich nicht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Klaus]

Moin,
also ich habe nen Script, und dort sind mir ein paar XSS Schwächen aufgefallen.
Naja fürher habe ich gedacht, wenn eine ID per URL übergeben wird, dann wird das schon keiner Ausnutzen...
Und XSS wäre ja nicht "soo" schlimm.

Naja und nachträglich suche ich in dem doch recht komplexen Script alle Schwachpunkte herraus um diese zu beheben.

Aber wie gesagt, wenn man bei der Abfrage aller vom User stammenden Daten diese behandelt, dann würde es ja keine XSS Schwächen mehr geben. Und dies zu realsieren, ist deutlich leicht, und auch sicherer, als jede Ausgabe in dem Script herrauszusuchen und zu behandeln.

Grüße Klaus

[Sven Rautenberg]

Moin!

Aber wie gesagt, wenn man bei der Abfrage aller vom User stammenden Daten diese behandelt, dann würde es ja keine XSS Schwächen mehr geben. Und dies zu realsieren, ist deutlich leicht, und auch sicherer, als jede Ausgabe in dem Script herrauszusuchen und zu behandeln.

Nein. Wenn es einen ganz simplen, einfachen Weg gäbe, sichere Programme zu schreiben, dann wäre der hier sicherlich schon bekannt geworden.

Einfaches Beispiel, warum dein Ansatz nicht gut funktioniert:
Angenommen, das allererste, was du tust, ist das Anwenden von htmlentities auf $_POST und $_GET.

1. Danach erst prüfst du beispielsweise, ob das vom Benutzer angegebene Passwort auch mindestens 8 Zeichen hat.
Angenommen, der Benutzer hat als Passwort "ää" gewählt - was wird deine Prüfung wohl ergeben?

2. Nehmen wir an, dein Passwort soll maximal 20 Zeichen lang sein (mehr kann sich ja auch kein Mensch merken), und damit die Datenbank nicht unnötig lange Felder enthält, hast du das Passwortfeld eben genau 20 Zeichen lang gemacht.
Der Benutzer wählt sich jetzt "äöüßÄÖÜß" als Passwort - Stringlänge nach htmlentities ist 50 Zeichen, über die Hälfte des Passwortes fehlt also plötzlich.

Da man solche Spezialanforderungen an die Datenbehandlung nicht allgemein voraussehen kann, ist folglich eine allgemeine Vorbehandlung der Daten auch nicht möglich, sondern muß immer individuell geschehen. Abgesehen davon sind eingeschmuggelte HTML- oder schlimmer Javascript-Codes nicht das einzige Problem, welches auftauchen kann.

Du kommst also nicht drum herum, deinen Code individuell nach Fehlermöglichkeiten durchzusehen. Das Forum würde dies aber natürlich auch übernehmen können - die eigene Betriebsblindheit ist ja schon sprichwörtlich.

• Sven Rautenberg

[Twilo]

Hallo,

2. Vor dem Wegschreiben der Daten sollte man z.B. strip_slashes() durchführen,
      Daten validieren und richtigstellen...

nur dass du dann auch zuviel wegschnippeln kannst :)

ich lasse den HTML Code so drin...
nachdem htmlentities bzw. htmlspecialchars drüber gelaufen sind...
wird es eh nicht nicht mehr als HTML Code interpretiert

mfg
Twilo

[Tom]

Hello,

ich lasse den HTML Code so drin...

und wo schneidet strip_slashes() den HTML-Code weg?

Und Sachen, die nicht valide sind (nach der Spezifikation für das Datenfeld) werden nicht angenommen und führen im Zweifel zum Affenformular.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Twilo]

Hallo,

ich lasse den HTML Code so drin...

und wo schneidet strip_slashes() den HTML-Code weg?

ich hab da vorhin an ein anderen Befehl gedacht :-/

mfg
Twilo