HTML Injektion

[swag91]

Hallo,

ist eine gute Möglichkeit sowas wie HTML-Injektion in Webformularen abzuwehren, einfach immer jede Zeichenkette zu löschen die mit "<" beginnt?

"<a" wird gelöscht/verworfen
"<ffsafafafsafa" wird gelöscht
"< a" wird nicht gelöscht.


Das ist doch sicher keine optimale Möglichkeit, da kann man doch sicher trotzdem irgendwelche Wege finden?

Grüße

 

[SaxnPaule]

Nutzt du keinerlei Framework?

https://benhoyt.com/writings/dont-sanitize-do-escape/

https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

 

[mr_andersson]

Das ist absolut korrekt. Man kann die Zeichen z.B. einfach als HTML Entity codieren.

 

[Haggis]

Man kann das "<" in &lt; umwandeln.
In jedem Framework sollte es dafür geeignete Methoden geben, die alle Strings "sicher" machen.

 

[Enigma]

Schön zu sehen, dass "Probleme" von vor 2000 heute immer noch existieren

Google mal nach HTML Entities

 

[Piktogramm]

Nutzt du keinerlei Framework?

Selbst wer Frameworks nutzt, sollte die Grundlagen kennen. Wird sonst haarig bei der ersten Zeile selbst geschriebenen Codes

Man kann das "<" in &lt; umwandeln.
In jedem Framework sollte es dafür geeignete Methoden geben, die alle Strings "sicher" machen.

Das Manuelle umwandeln ist meist ungünstig. Ganz ohne Framework bringen die meisten Sprachen entsprechende Funktionen mit ihren Standardbibliotheken mit. Mit dem großem Vorteil, dass wenn da mal was schief geht, man davon ausgehen kann, dass das Problem fix gepatcht wird. Man spart also Wartung beim eigenem Code (muss aber seinen eigenen Zoo an Abhängigkeiten im Griff haben).

@swag91
Wie schon angemerkt wurde, es ist schlauer die Nutzereingaben zu Escapen und zu Validieren. Zum Escapen gibt es in der regel fertige Funktionen in Standardbibliotheken und zum Validieren ist eigener Code fällig, denn nur du weißt, welche Eingaben halbwegs sinnvoll sein könnten.
ABER, jede Technologie hat da ihre eigenen Probleme. Du kannst einen Webserver mit PHP davor bewahren fröhlich HTML und Javascript entgegenzunehmen. Im Zweifelsfall bleibt bei der Escapefunktion von PHP eine SQL-Injection unberührt. Also immer schon die Probleme aller technischen Komponenten beachten!

 

[andy_m4]

Gibt kein potentielles Sicherheitsproblem, welches man nicht durch ein beherztes eval() drastisch vergrößern kann. :-)

 

[xeon.inc]

Falscher Thread, sorry.

 

[Marco01_809]

Sauber gelöst: Framework/Templating Engine benutzen
Wenn man unbedingt Strings konkatenieren/interpolaten will: jede eingefügte Variable mit html entities encoden, so dass alle syntaktisch relevanten zeichen wie <, >, ', " & Co. escaped werden.

Letzteres mache ich auch schon mal von Hand wenn ich ein kleines script bastele wo es nur eine Seite gibt. Bei allem größeren verliert man den Überblick, weil man i.d.R. anfängt Abkürzungen zu gehen ala "diese variable ist eh ein int, da muss ich nichts escapen" und später ist sie's dann doch nicht mehr.

Irgendwas rauslöschen oder filtern ist natürlich offensichtlich Schrott, weil dann Nutzer plötzlich irgendwelche Texte nicht mehr eingeben können, wie z.B. Ist a<b oder a>b? weil das dann fälscherlicherweise als html tag "erkannt" wird

 

[Joachim87]

Ich hab das Thema mal durch Zufall entdeckt:

Meine Eltern haben einen Bauernhof und verkaufen darüber Erzeugnisse aus der Urproduktion, jetzt haben die sich auch einen Webseite bei einem Dienstleister "bauen" lassen -_-

Ich kann in deren Kontaktformular auch sowas wie "&lt;a href" machen. Wenn ich das Formular abschicke bekommen wir und der "Absender" eine Mail. Der "Absender" ist die Adresse die man eingibt.....

In der Mail ist dann "<a href" als lesbarer Text, im Quellcode der Mail dann aber weiterhin "&lt;a href". Man kann von Außen die Mail schon mal nicht "selbst gestalten", zumindest mit den "Trick" nicht. Hat der Dienstleister hier irgendein Framework benutzt?

Edit: Bzw. das < wird in &lt; umgewandelt damit es keinen Schaden anrichtet, so ist es gemeint?

Grüße

 

[Marco01_809]

Wenn du <a href ins Formular eingibst sollte auch <a href genau so in der Mail zu lesen sein, ansonsten wird das Escaping nicht richtig gemacht. (Im Quelltext als <a href encodet)
Wenn du <a href ins Formular eingibst sollte in der Mail auch <a href zu lesen sein. (Im Quelltext als <a href encoded).

Ganz einfach: Das was du eingibst sollte auch 1:1 zu lesen sein. Es darf keine Zeichen geben die irgendeine besondere Bedeutung haben, das ist alles einfach Text der für menschliche Augen bestimmt ist, in dem Sinne in dem du ihn eingegeben hast.

Wie das im Hintergrund encodiert ist darf dem Leser egal sein, der muss alles eingeben können wie er will. Der Programmierer muss aber dafür sorgen dass er HTML-Code und Freitext nicht durcheinanderbringt, in dem in Freitexten syntaktisch relevante Sonderzeichen eben als neutrale Entities encodet werden.

 

[Piktogramm]

@Joachim87
Was der Dienstleister konkret nutzt kann dir Niemand verraten. Hoffentlich läuft es jedoch auf sowas hinaus: https://www.php.net/manual/en/function.htmlspecialchars.php
oder ja nach technischer Grundlage/Sprache einer Entsprechung davon anstatt irgend ner selbstgebauten oder Lösung aus einem Framework.

Sauber gelöst: Framework/Templating Engine benutzen
[...]
Bei allem größeren verliert man den Überblick, weil man i.d.R. anfängt Abkürzungen zu gehen ala "diese variable ist eh ein int, da muss ich nichts escapen" und später ist sie's dann doch nicht mehr.

Bei Frameworks sollte man schauen, wie das umgesetzt wird, wenn man sicher gehen will. Es ist nicht so selten, dass Frameworks solche Funktionen selber implementiere. Dabei aber nicht sonderlich sauber arbeiten und oftmals von der Zeit überlebt wurden, weil die Basistechnologie das mittlerweile besser, schneller, effizienter selber kann (bei Javascript/NodeJS und UraltPHP sehr verbreitet).

Und bei größeren Projekten, die man selber schreibt sollte man eine Funktion haben, die Escaped und normalsiert und durch die alle Eingaben durchmüssen. Ansonsten kommt man echt in des Teufels Küche.