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

[Lynn]

Hallo Ihr Lieben Helfende,

ich habe ein Formular mit einem Inputfeld als textarea erstellt:

<textarea class="form-control" id="TextID" name="Text">' . $_SESSION['Text'] . '</textarea>

Nun habe ich das Phänomen, dass dort beim Speichern(Absenden) des Formulars automatisch ein \ integriert wird, wenn man ein Wort in " setzt:

"Wort" im Formularfeld, gespeichert wird dann in der Datenbank \"Wort"\

Woran könnte dies liegen ?

LG

Lynn

[MudGuard]

Hi,

ich habe ein Formular mit einem Inputfeld als textarea erstellt:

<textarea class="form-control" id="TextID" name="Text">' . $_SESSION['Text'] . '</textarea>

Nun habe ich das Phänomen, dass dort beim Speichern(Absenden) des Formulars automatisch ein \ integriert wird, wenn man ein Wort in " setzt: Woran könnte dies liegen ?

in uralten PHP-Versionen gab es mal das "Feature" MoronicMagic Quotes, das dafür gesorgt hat, daß automatisch Backslahes hinzugefügt wurden. Aber das wurde irgendwann abgeschafft.

Ansonsten: ruft Dein Script addSlashes auf?

cu,
Andreas a/k/a MudGuard

[Lynn]

Hallo Andreas,

wow, geht das schnell hier ;-)

Nein, addSlashes wird nicht aufgerufen, aber die PHP-Version dieser Schulseite ist nicht die Neuste, dies wird dann wohl der Grund sein :-(

Vielen Dank für diese superschnelle Antwort, echt Klasse.

LG Lynn

[Der Martin]

Hallo,

<textarea class="form-control" id="TextID" name="Text">' . $_SESSION['Text'] . '</textarea>

Nun habe ich das Phänomen, dass dort beim Speichern(Absenden) des Formulars automatisch ein \ integriert wird, wenn man ein Wort in " setzt:

tatsächlich schon beim Absenden? Das wäre nun wirklich seltsam und für mich nicht zu erklären. Solltest du aber eine sehr alte PHP-Version auf deinem Webspace haben, dann ist MudGuard vielleicht auf der richtigen Fährte (Betonung auf sehr alt, denn die Magic Quotes wurden mit PHP 5.4 abgeschafft).

Wenn es das nicht ist, müssen die Backslashes wohl im weiteren Ablauf deines Scriptes entstehen. Das solltest du dann aber nachvollziehen können. Eventuell eine falsche/unpassende oder mehrfach durchgeführte Maskierung.

Live long and pros healthy,
 Martin

[Lynn]

Hallo Martin,

ich habe mal per ECHO die Variable $_SESSION['Text'] ausgegeben, bevor das Update-SQL startet - bereits hier ist dieses \ automatisch vergeben.

Quelltext hier

if($pdoStmnt->rowCount() == 1)
        { 
        
        
         echo'fffffff '.$_SESSION['Text'];

             
            $pdoStmntU = $dbh->prepare( "UPDATE LehrerUpload SET Titel = :Titel, Text = :Text WHERE Klasse = :Klasse AND Datum = :Datum" ); 
            $pdoStmntU->bindParam( ':Klasse', $_SESSION['Klasse'], PDO::PARAM_STR ); 
            $pdoStmntU->bindParam( ':Datum', date('Y.m.d', strtotime($_SESSION['Datum'])), PDO::PARAM_STR ); 
            $pdoStmntU->bindParam( ':Titel', $_SESSION['Titel'], PDO::PARAM_STR );
            $pdoStmntU->bindParam( ':Text', $_SESSION['Text'], PDO::PARAM_STR );
            $pdoStmntU->execute();                                                                                          
        } 
        else
        {
            $pdoStmntU = $dbh->prepare( "INSERT LehrerUpload SET Klasse = :Klasse, Datum = :Datum, Titel = :Titel, Text = :Text" );   
            $pdoStmntU->bindParam( ':Klasse', $_SESSION['Klasse'], PDO::PARAM_STR ); 
            $pdoStmntU->bindParam( ':Datum', date('Y.m.d', strtotime($_SESSION['Datum'])), PDO::PARAM_STR );  
            $pdoStmntU->bindParam( ':Titel', $_SESSION['Titel'], PDO::PARAM_STR );
            $pdoStmntU->bindParam( ':Text', $_SESSION['Text'], PDO::PARAM_STR );
            $pdoStmntU->execute();         
        }  

Auch Dir vielen Dank für die superschnelle Antwort, echt Klasse.

LG Lynn

[Felix Riesterer]

Lieber Lynn,

ich habe mal per ECHO die Variable $_SESSION['Text'] ausgegeben, bevor das Update-SQL startet - bereits hier ist dieses \ automatisch vergeben.

und wie kommt der Wert in $_SESSION['Text'] überhaupt zustande? Das, mein Lieber, ist der springende Punkt! Dein Code-Beispiel verrät das leider nicht.

Liebe Grüße

Felix Riesterer

[Lynn]

Hallo Felix,

bin weiblich ;-)

So kommt er zustande:

if(isset($_POST['Text'])) { $_SESSION['Text'] = $_POST['Text'];
}

So, lieber Punkt, nun spring mal ;-)

LG

Lynn

[Felix Riesterer]

Liebe Lynn,

bin weiblich ;-)

dann ist das ja geklärt. ;-)

if(isset($_POST['Text']))
  {
      $_SESSION['Text'] = $_POST['Text'];                            
  }   

Das hatte ich schon befürchtet. Das ist in zweierlei Hinsicht sehr unglücklich:

1. Die Inhalte einer Session-Variable (lies: Werte im $_SESSION-Array) kommen "irgendwie aus dem Script" dort hin. Ihr Ursprung ist völlig uneinsichtig, daher auch meine Frage.
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, 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". Dieses Verhalten scheint Dein Script auch zu zeigen, da Deine Session-Werte eben unverändert aus $_POST übernommen werden.

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!

Tut mir leid das so deutlich schreiben zu müssen, aber dass auf Deinem Webspace eine dermaßen veraltete PHP-Version tickt, ist eben ein wirklich gravierendes Sicherheitsrisiko!

Liebe Grüße

Felix Riesterer

[Lynnv]

Hallo Felix,

ja, die Hoster der Schulen wollen demnächst auf die neuste PHP-Version umstellen ;-)

Da hier nur die Lehrer Texte erfassen, gehe ich mal davon aus, dass die keine "miesen" Texte einschleussen werden ;-)

LG

Lynn

[Auge]

Hallo

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. …

Tut mir leid das so deutlich schreiben zu müssen, aber dass auf Deinem Webspace eine dermaßen veraltete PHP-Version tickt, ist eben ein wirklich gravierendes Sicherheitsrisiko!

Dein Hinweis, eine aktuelle PHP-Version zu betreiben, in allen Ehren, bezüglich des hier diskutierten Verhaltens triftt er allerdings ins Leere. Wie schon Martin schrieb, wurde magin_quotes mit PHP 5.4 abgeschafft und bei Lynn läuft PHP 5.6. Da muss also noch etwas anderes passieren.

Tschö, Auge

[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.

[dedlfix]

Tach!

Nachtrag: Wenn tatsächlich bereits PHP 5.6 im Einsatz ist, dann hilft die Vorgehensweise gegen Magic Quotes nicht mehr.

Wenn die Daten bereits im System sind, müssen sie repariert werden. Wenn neue Daten verunstaltet werden, muss stattdessen die dafür ursächliche Stelle im Script gefunden und beseitigt werden. Wo und was das sein kann, ist für Außenstehende nicht bestimmbar. Da muss man gegebenenfalls mit Debugging den Weg der Daten verfolgen.

dedlfix.

[Felix Riesterer]

Lieber dedlfix,

So einfach ist es nicht. Es gibt keine bösen Daten.

wenn man einem Neuling erklären soll, warum die Backslashes einst hinzugefügt wurden, muss man diese Sichtweise vermitteln. Sonst wäre das Feature nur als Programmierer-Ärgern zu erklären.

$_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.

Das ist eine Frage der Sichtweise. Deine ist eine sehr fortgeschrittene. Einem Anfänger oder Amateur muss das jetzt nicht sofort einleuchten.

Wenn ich im Code einen Wert fest eintrage, weil meine Geschäftslogik gegen diesen prüfen will, dann ist der in diesem Kontext "richtig" oder "sauber". Da muss ich nicht an Kontextwechsel denken, denn da gibt es nicht wirklich einen. Um aber nun die Idee hinter dem Konzept eines Kontextwechsels zu verstehen, muss ich wissen, dass es Fälle gibt, in denen eine gewisse in Code gegossene Gutgläubigkeit sehr fatal sein kann. Und wenn ich den Kontextwechsel wirklich verstanden und verinnerlicht habe, dann kann ich eine generelle Haltung dazu annehmen, wie Du sie gerade beschreibst. Man könnte über einen Programmierkurs diese handwerkliche Vorgehensweise auch direkt lernen, wenn man Webdevelopment von der Pike auf lernt, aber oft kommen die Macher "von der Seite her" und benötigen diesen Lernweg.

[magic_quotes]

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.

Ja, die Flegeljahre von PHP, das sich von personal home page tools zu einer echten Programmiersprache mausern möchte.

Das hat sicher in einigen Situationen einge von unbedarften Programmierern hergestellte Systeme gerettet. Aber es hat auch unnötigen Schaden angerichtet.

Das ist uns "Eingeweihten" sicher allen klar. Aber dem OP...?

Liebe Grüße

Felix Riesterer

[dedlfix]

Tach!

Wenn ich im Code einen Wert fest eintrage, weil meine Geschäftslogik gegen diesen prüfen will, dann ist der in diesem Kontext "richtig" oder "sauber". Da muss ich nicht an Kontextwechsel denken, denn da gibt es nicht wirklich einen.

Doch, auch dann, denn auch da bringst du Daten in Code und musst mindestens die Begrenzungszeichen maskieren, wenn sie darin vorkommen. Konstante Daten bilden keine Ausnahme. Dasselbe gilt auch, wenn du beispielsweise unter PHP mit echo einen konstanten Wert in die Ausgabe gibst, die ein HTML-Dokument mit eingebettetem Javascript ergibt.

Um aber nun die Idee hinter dem Konzept eines Kontextwechsels zu verstehen, muss ich wissen, dass es Fälle gibt, in denen eine gewisse in Code gegossene Gutgläubigkeit sehr fatal sein kann.

Ja, aber dazu spielt die Herkunft der Daten keine Rolle.

Und wenn ich den Kontextwechsel wirklich verstanden und verinnerlicht habe, dann kann ich eine generelle Haltung dazu annehmen, wie Du sie gerade beschreibst.

Mit dem Kontextwechsel kommt man bereits in Berührung, wenn das Tutorial beschreibt, dass bei Stringliteralen Anführungszeichen mit Backslash davor zu notieren sind, etc. Im Grunde genommen fehlt dann nur noch die Erkenntnis, dass das Prinzip auch anzuwenden ist, wenn man es nicht so offensichtlich sieht wie bei Stringliteralen.

Man könnte über einen Programmierkurs diese handwerkliche Vorgehensweise auch direkt lernen, wenn man Webdevelopment von der Pike auf lernt, aber oft kommen die Macher "von der Seite her" und benötigen diesen Lernweg.

Das ist gut möglich, aber hilft denn erstmal die Geschichte von den bösen Daten, wenn es tatsächlich keinen Unterschied gibt? Bringt man so nicht unnötigerweise bei, zwischen den Daten zu unterscheiden?

Dass man mit einem Beispiel (wie dem xkcd) die Auswirkungen zeigt, die bei gezieltem Ausnutzen entstehen können, ist ja ok. Aber das Augenmerk sollte nicht eingeschränkt werden, wenn man bereits die Aufmerksamkeit des Lernenden hat. Kaputt ist das Program auch, wenn die "guten" Daten unbehandelt bleiben.

dedlfix.

[Felix Riesterer]

Lieber dedlfix,

aber hilft denn erstmal die Geschichte von den bösen Daten, wenn es tatsächlich keinen Unterschied gibt? Bringt man so nicht unnötigerweise bei, zwischen den Daten zu unterscheiden?

Menschen haben schon immer durch Geschichten gelernt. Das siehst Du mindestens in der Bibel mit all den Gleichnissen. Wenn Du einen erfahrenen oder fortgeschrittenen Programmierer hast, dann ist das für den "alles eins", also alle Daten eben nur das: Daten. Aber für den Anfänger braucht es eine Geschichte, mit der er etwas erleben darf, damit er eine Lehre daraus ziehen kann.

Dass man mit einem Beispiel (wie dem xkcd) die Auswirkungen zeigt, die bei gezieltem Ausnutzen entstehen können, ist ja ok.

Nicht nur OK, sondern idealtypisch, was das Lernen angeht.

Aber das Augenmerk sollte nicht eingeschränkt werden, wenn man bereits die Aufmerksamkeit des Lernenden hat. Kaputt ist das Program auch, wenn die "guten" Daten unbehandelt bleiben.

Wer hier zum ersten Mal im Forum mit Fragen aufschlägt, lässt sich sehr schwer einschätzen. Vor allem hinsichtlich der Lernbereitschaft und Aufmerksamkeit. Da hat es einen Sinn, einen kleinsten gemeinsamen Nenner zu finden. Und das sind Narrative. Damit sind wir schon als Kinder aufgewachsen. Damit haben wir das Lernen gelernt. Zumindest hoffentlich...

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Wer hier zum ersten Mal im Forum mit Fragen aufschlägt, lässt sich sehr schwer einschätzen. Vor allem hinsichtlich der Lernbereitschaft und Aufmerksamkeit. Da hat es einen Sinn, einen kleinsten gemeinsamen Nenner zu finden. Und das sind Narrative. Damit sind wir schon als Kinder aufgewachsen. Damit haben wir das Lernen gelernt. Zumindest hoffentlich...

ob Gleichnisse aus der Bibel, ob Fabeln, ob andere Analogien: Ich habe mich dabei als Kind immer veräppelt gefühlt, habe mich gefragt, warum die nicht einfach auf den Punkt bringen, was sie sagen wollen, anstatt so um den Brei herumzureden.

Ja, heute versuche ich auch vorzugsweise, Vergleiche aus dem wirklichen Leben heranzuziehen, weil ich den Eindruck habe, dass das bei vielen ankommt. Aber meine Lernmethode ist das nicht. Damals nicht und heute noch viel weniger. Lieber straight to the point.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Felix Riesterer

Menschen haben schon immer durch Geschichten gelernt. Das siehst Du mindestens in der Bibel mit all den Gleichnissen. Wenn Du einen erfahrenen oder fortgeschrittenen Programmierer hast, dann ist das für den "alles eins", also alle Daten eben nur das: Daten. Aber für den Anfänger braucht es eine Geschichte, mit der er etwas erleben darf, damit er eine Lehre daraus ziehen kann.

Ja. Und die Lehre daraus ist: Es gibt keine guten Daten; alle Daten sind prinzipiell böse Daten. Oder kurz: Alle Daten sind Daten.

😷 LLAP

[Felix Riesterer]

Lieber Gunnar,

Es gibt keine guten Daten; alle Daten sind prinzipiell böse Daten.

ich habe Durst, lass uns jetzt ein Fass aufmachen: Nur freie Daten sind gute Daten!

Liebe Grüße

Felix Riesterer

[Tabellenkalk]

Hallo,

Nur freie Daten sind gute Daten!

Du willst damit sagen, die bösen Daten sind in einem Fass eingesperrt?

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Du willst damit sagen, die bösen Daten sind in einem Fass eingesperrt?

Das Fass der Pandora.

😷 LLAP

[Gunnar Bittersmann]

@@dedlfix

Mit dem Kontextwechsel kommt man bereits in Berührung, wenn das Tutorial beschreibt, dass bei Stringliteralen Anführungszeichen mit Backslash davor zu notieren sind

Das sind sie nicht, wenn man im Text (bei Codebeispielen ist das freilich anders) richtige Anführungszeichen verwendet:

echo "„Null problemo“, wie ALF immer sagt.";
echo 'Hab ich’s mir doch gedacht!';

😷 LLAP

[Matthias Apsel]

Hallo Gunnar Bittersmann,

leider ist eine Programmierumgebung keine Textverarbeitung. Deshalb wäre dein Vorschlag ein wertvoller Hinweis für das Tutorial.

Bis demnächst
Matthias

[Der Martin]

Hallo Felix,

Lieber Lynn,

Vornamen sind nicht immer eindeutig - vor allem solche, die bei uns nicht so verbreitet sind. Ich kenne Lynn aber eigentlich als Frauennamen. Kommt AFAIK aus dem skandinavischen Raum, ist aber im englischsprachigen Raum sehr beliebt.

ich habe mal per ECHO die Variable $_SESSION['Text'] ausgegeben, bevor das Update-SQL startet - bereits hier ist dieses \ automatisch vergeben.

und wie kommt der Wert in $_SESSION['Text'] überhaupt zustande? Das, mein Lieber, ist der springende Punkt! Dein Code-Beispiel verrät das leider nicht.

Stimmt. Deswegen hatte ich ja auch pauschal die gesamte Verarbeitung im Script in Frage gestellt.

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

Ich kenne Lynn aber eigentlich als Frauennamen.

dachte ich bisher auch

Kommt AFAIK aus dem skandinavischen Raum,

Wikipedia sieht beide Punkte etwas anders…

Gruß
Kalk

[Lynn]

Hallo Martin,

die aktuell verwendete PHP-Version ist 5.6, somit ist dies wohl nicht der Grund.

Falsche/unpassende oder mehrfach durchgeführte Maskierung kann es auch nicht sein, da nicht vorhanden.

LG

Lynn

[Matthias Apsel]

Hallo Lynn,

die aktuell verwendete PHP-Version ist 5.6, somit ist dies wohl nicht der Grund.

5.6 ist genau wie 5.4 gerundet 5 😉 und sollte als PHP-Version nicht mehr verwendet werden.

Falsche/unpassende oder mehrfach durchgeführte Maskierung kann es auch nicht sein, da nicht vorhanden.

Wie kannst du dir dabei so sicher sein? Vielleicht passiert doch irgendetwas auf dem Weg von $_POST nach $_SESSION?

Bis demnächst
Matthias

[Lynn]

Hallo,

ich habe jetzt nach langem Suchen aufgegeben und einfach ein REPLACE vor dem UPDATE-SQL eingefügt.

LG

Lynn