Ein Slash \ wird im Formular automatisch gesetzt, wenn ein Wort in "" geschrieben wird

[dedlfix]

Tach!

2. Die Werte in $_GET, $_POST und $_REQUEST sind Daten, die von einer anderen Quelle zum Webserver übertragen wurden. Sie sind grundsätzlich als böse weil manipulativ und Programmfehler ausnutzend einzustufen sind. Man tut sich wirklich keinen Gefallen, wenn man diese "Benutzereingaben" in andere Variablen umkopiert und so ihre Herkunft vor sich selbst verschleiert.

So einfach ist es nicht. Es gibt keine bösen Daten. Denn selbst wenn Eingaben nicht mit dem Ziel erzeugt wurden, Schaden anzurichten, kann man sie nicht einfach so unbeachtet weiterverarbeiten. Daten sind Daten, egal woher sie kommen. Es ist auch nicht möglich, den Daten die ganze Zeit, die sie in einem System verbringen, ein Merkmal mitzugeben, anhand dessen sie als "böse" gekennzeichnet werden könnten. $_GET etc. eine besondere Aufmerksamkeit zu schenken, ist nicht sinnvoll. Andere Variablen als Verschleierung der Herkunft zu betrachten, ist es auch nicht. Daten bleiben Daten, unabhängig von Herkunft und der Variable, in der sie daherkommen.

Vielmehr ist es wichtig, die Stellen zu beachten, an denen Daten und Code miteinander verbunden werden, sei es Programmcode oder Syntax von Protokollen und Dateiformaten. Hier muss sichergestellt sein, dass beim Empfänger zweifelsfrei Syntaxelemente und Daten wieder getrennt werden können. Und das völlig unabhängig davon, wo die Daten ursprünglich einmal hergekommen sind. Damit das möglich ist, gibt es diverse Vorgehensweisen je nach Kontext, also zum Beispiel je nach Programmiersprache, Protokoll oder Dateiformat. Ein generelles Rezept, Daten von "böse" zu "gut" zu bekommen, gibt es nicht.

So, lieber Punkt, nun spring mal ;-)

Ein seit über zehn Jahren veralteter Schutzmechanismus in PHP wollte unsicher geschriebene PHP-Programme davor schützen, dass doppelte (oder auch einfache) Anführungszeichen aufgrund eines nicht beachteten Kontextwechsels Schaden verursachen oder gar Einfallstore für Eindringlinge bieten. Dazu wurden von PHP beim Empfang der Daten diese Anführungszeichen mit einem vorangestellten Backslash "entschärft".

Und dieses Vorgehen setzt an der falschen Stelle an, nämlich bei der Betrachtungsweise, Eingabedaten seien böse. Das "Entschärfen" fand am Eingang statt. Dabei wurde nicht betrachtet, für welches Medium eine Behandlung der Daten in diesem Script tatsächlich benötigt wird. Stattdessen hat man SQL als Kontext angenommen. Das hat sicher in einigen Situationen einge von unbedarften Programmierern hergestellte Systeme gerettet. Aber es hat auch unnötigen Schaden angerichtet. Zum Beispiel auch den im Falle des OPs. Bei der Ausgabe in HTML sind die Maskierungen für SQL falsch, und es fehlt die Behandlung für HTML. Man müsste nun anfangen, zu klären, wo die Daten herkamen, für welches System sie vorbereitet wurden, um diese Vorbereitung zu entfernen, bevor man mit der eigentlich benötigten Behandlung fortfahren kann. Und diese Betrachtung müsste man für sämtliche Wege vornehmen, die die Daten durch das System gegangen sein können. Und so wird aus einer gut gemeinten Handlung gegen "böse Daten" am Ende ein unnötig komplexes System.

Stattdessen sollte man die Daten neutral betrachten und als Rohdaten verarbeiten. Beim Eintritt in ein System oder Verarbeitungsschritt muss man sie gegebenenfalls in ihre Rohform bringen. Und erst wenn sie anderenorts hingegeben werden, bringt man sie in die für das jeweilige Medium benötigte Form.

Zwei Dinge solltest Du im Idealfall tun:

1. eine wirklich aktuelle PHP-Version einsetzen (mindestens 7.4)
2. Dein sehr unsicheres Script entsorgen, denn wenn Du nicht weißt, was Du da tust, ist patchen/reparieren keine echte Option!

Beides scheint zunächst keine Option zu sein. Da wir das System nicht in seiner Gesamtheit kennen, können wir auch keine umfangreichen Vorschläge geben, was zu tun ist. Stattdessen können wir nur auf Literatur verweisen, die generelle Vorgehensweisen aufzeigen - zum Beispiel der verlinkte Kontextwechselartikel.

Gegen das konkrete Problem der verunstalteten Daten gibt es zudem folgende Vorgehensweise. Es wird sicherlich nicht möglich sein, den Magic-Quotes-Mechanismus generell abzuschalten, denn er läuft bereits bevor die Steuerung an das Script übergeben wird. Nur jemand mit administrativen Rechten kann eine entsprechende Konfigurationsänderung vornehmen. Ob das eine gute Idee ist, kann man als Außenstehender nicht sagen, denn vielleicht macht man mit dem Abschalten andere Stellen kaputt, die sich auf den Mechanismus verlassen. Stattdessen bleiben nur Reparaturmaßnahmen. Zum Beispiel das Codestück im zweiten Beispiel von Disabling Magic Quotes. Somit bekommt man die Daten wieder in Rohform. Diese Behandlung sollte am Scriptanfang stattfinden. Der Code im Beispiel prüft zunächst, ob das Feature "Magic Quotes" aktiviert ist, und nimmt die Behandlung nur in dem Fall vor. Wenn der Magic-Quotes-Mechanismus eines Tages abgeschaltet wird, kann das Codestück problemlos im Script verbleiben. Ab PHP 5.4 kann es aber auch gelöscht werden, denn dann gibt es keine Magic Quotes mehr.

Zu beachten ist, dass insbesondere beim Weitergeben an ein SQL-Datenbanksystem, die im Kontextwechselartikel genannten Dinge beachtet werden müssen, wenn man sich zuvor darauf verlassen hat, dass der Magic-Quotes-Mechanismus seine Arbeit tut.

dedlfix.