[Erledigt] Sicherheit: Escaping von HTML-Entities notwendig?

[monolith]

Hallo,

es ist nicht ganz so trivial, wie man aufgrund des Titels glauben könnte:
Ist es notwendig, Model-Attribute wie den Titel bei der Ausgabe mit htmlentities o. ä. zu bearbeiten, wenn folgendes gilt:

- Das Model wurde von einem registriertem und eingeloggtem User erstellt
- der die Berechtigung hat, das Admin-Interface aufrufen zu können (und damit als Admin klassifiziert werden kann)
- sowie auf das spezifische Modul, zu dem das Model gehört, zugreifen zu können
- und zwar nicht nur lesend, sondern auch schreibend, also Content (Models) erstellen kann.

Kann ich einem User mit diesen Privilegien so weit trauen, dass ich ihm implizit erlaube, HTML-Code in seinen Eingaben zu verwenden? (Also nur bei Text-Eingaben, natürlich - bei Integer/Bool etc. geht's aufgrund der Validierung sowieso nicht.)

Als Pro-Argument kann man geltend machen, dass man dem User offensichtlich ein gewisses Vertrauen entgegenbringt. Als Contra-Argument, dass er aber dennoch nur eingeschränkte Rechte besitzt, die er aber theoretisch durch eingeschleusten JS-Code erweitern kann (den Client eines Admins mit mehr Berechtigungen dazu bringen ihm weitere Berechtigungen zu geben)

Gruß

[rkr]

Du solltest dir im Klaren sein, dass der User theoretisch Aktionen im Kontext eines anderen Users ausführen kann. Beispielsweise mit einer onclick- oder onfocus-aktion.
Das ScriptTag ist ja offensichtlich.

[VPh]

Ich denke, das ist stark abhängig von der Situation und sollte unbedingt mit Projektverantwortlichen geklärt werden.

Though, in 90% der Fälle würde ich wohl sagen, dass jeder Content escaped werden sollte.
In den anderen 10% würde ich wohl über folgende Möglichkeiten nachdenken:
- WhiteList pflegen mit erlaubtem Markup (hab mich nicht so sehr damit beschäftigt wie ich eigentlich wollte, aber der Link taucht bei Recherchen immer wieder auf http://htmlpurifier.org)
- Klar definierte Stellen, an denen diese "besonderen" Eingaben möglich sind

Ich würde jedoch nachdrücklich auf die Sicherheitsrisiken hinweisen.

[rkr]

Vielleicht markdown als Alternative?

[tr0y]

Ich würde sagen situationsbezogenes Sanitizing ist sturem Escaping / Nicht-Escaping vorzuziehen.

[monolith]

Du solltest dir im Klaren sein, dass der User theoretisch Aktionen im Kontext eines anderen Users ausführen kann. Beispielsweise mit einer onclick- oder onfocus-aktion.
Das ScriptTag ist ja offensichtlich.

Ja, darüber bin ich absolut im Klaren - siehe Contra-Argument.

Vielleicht markdown als Alternative?

Ja und nein. Notwendig ist es nicht, dass HTML - und sie es nach Kompilierung von Markdown - verwendet wird. Es geht auch kaum darum, HTML als Feature zu nutzen sondern darum ob der Aufwand notwendig ist, alles zu escapen.

[lottikarotti]

Hallöchen,

im Prinzip wurden die wichtigsten Knackpunkte bereits aufgeführt. Auch ein User dem du theoretisch trauen kannst, kann kriminelle Handlungen durchführen oder dies zumindest versuchen. Ich persönlich jage grundsätzlich alle Text-Eingaben, die vom Nutzer kommen, bei der Ausgabe durch einen Filter um das Einschleusen von ungültigem Code zu vermeiden. Durch den Nutzer formatierbare Texte, wie bspw. eine E-Mail Signatur, lasse ich nur für definierte Felder zu und validiere diese mit einer Whitelist. Da numerische Werte usw. sowieso nicht als Zeichenketten in der Datenbank landen, braucht's da auch kein Escaping, aber das hattest du ja auch schon angedeutet.

Man kennt ja das alte Sprichwort: Vertrauen ist gut, Kontrolle ist besser.

Viele Grüße,
lotti

[lstegelitz]

Mal anders ausgedrückt: HTML-spezifisches Escaping hat keinen Einfluss auf "normalen" Text. Es schadet also nicht...

Solange deine Modelle sich aus den den Standardzeichen [a-zA-Z0-9] zusammensetzen, macht HTML Escaping genau "nix".

[monolith]

Stimmt. Die Attribute der Models sind aber meistens einfach Strings die alles enthalten können.

Nun gut, ich werde in den sauren Apfel beißen und alles escapen.

[tr0y]

*wiederhol* Sanitizing statt blindes escapen.

[rkr]

Nimm (oder bau) dir eine Templateengine, die das automatisch macht.

[monolith]

@tr0y: Schon verstanden.

@rkr: Findet außerhalb einer TE statt.

Ich markier das Thema mal als erledigt, denn für mich ist es das nun. Danke an alle!

[rkr]

@rkr: Findet außerhalb einer TE statt.

Warum? Wer hat denn sonst (bzw. űberhaupt) die nōtige Qualifikation dafűr?

[lstegelitz]

*wiederhol* Sanitizing statt blindes escapen.

tr0y hat wie so oft Recht... der Spielraum ist viel größer, du kannst ja "ein bischen HTML" zulassen und nur die bösen Sachen filtern

[monolith]

Kann ich, muss ich aber nicht. Es ist nicht als "Feature" gedacht, dass HTML benutzt wird. Wäre nur halt praktischer gewesen es zu erlauben.

Warum? Wer hat denn sonst (bzw. űberhaupt) die nōtige Qualifikation dafűr?

Weil vorher eine Aufbereitung verschiedener Model-Attribute stattfindet und das Ergebnis wird dann in ein Template übergeben und dort ausgegeben. Okay, vielleicht wäre es besser das im Template selber zu tun statt vorher. Aber für meinen Geschmack war dafür wiederum zu viel Logik im Spiel. Oder man müsste es aufteilen und zunächst die Attribute außerhalb des Templates manipulieren und dann innerhalb sich darum kümmern, dass die einzelnen Attributwerte korrekt angezeigt werden.

Obwohl, bezüglich deines Vorschlags eine Templateengine zu nutzen, die automatisch escaped: Das Prinzip anzuwenden wäre hier eigentlich möglich. Alles was als String zurückgeliefert wird, wird automatisch escaped. Möchte man das verhindern (weil HTML angezeigt werden soll), muss man den String in ein Objekt a la 'Raw' verpacken, das dann nicht escaped wird. Die Idee gefällt mir.