Das ist im Grunde dasselbe wie beim Escaping syntaktisch relevanter Zeichen in SQL-Queries. Du hast in einer PHP-Variablen $x den Inhalt Hallo"Welt stehen. Den willst du in eine Query einfügen:

Das ergibt dann diese SQL-Query:

Die ist syntaktisch falsch, weil das Datenbanksystem bereits nach "Hallo" den String für beendet hält. Mit dem folgenden Welt" weiß es dann nichts mehr anzufangen. In diesem Fall führt das nur zu einem Fehler, aber statt Welt" könnten da eben auch Dinge stehen, die syntaktisch für das Datenbanksystem Sinn ergeben und somit die Logik deiner Query unerwünscht verändern. Das ist eben die klassische SQL-Injection, mit der ein Angreifer Dinge auslösen kann, die er nicht auslösen können sollte.

Allgemein bezeichnet man so was als Kontextwechsel. Der Inhalt einer PHP-Variablen wird in einen Kontext (hier den SQL-Query-String) eingefügt, der über eigene syntaktische Regeln verfügt.

Das ist auch bei unter anderem HTML der Fall, denn auch in HTML existieren syntaktisch relevante Zeichen (konkret <, >, ", ' und &). Wenn du den Inhalt einer PHP-Variablen in HTML-Code einfügst, musst du sicherstellen, dass diese Zeichen passend behandelt (escapet) werden. Ansonsten können dir Leute beispielsweise JavaScript-Code in deine Seite reinbasteln:

Damit lässt sich ein Haufen Unsinn anstellen. Es ist beispielsweise möglich, Sessions zu übernehmen:

- Session hijacking - Wikipedia, the free encyclopedia

Der wesentliche Aspekt sollte aber sein, dass es zu korrekter Programmierung gehört, Kontextwechsel richtig durchzuführen. Beim Wechsel von PHP nach HTML dient etwa die Funktion htmlspecialchars dazu.

Die syntaktisch relevanten Zeichen für HTML sind nun passend escapet und der Client betrachtet sie als reinen Inhalt.

sorry ich sehe jetzt das problem nicht? ich habe doch den kontext beachtet. ich habe halt nur nicht mit \ escaped. ich verfahre eher so statt mit \ zu escapen unterbreche ich den string und führe ihn nach der variablen fort.

das dein erstes beispiel in deinem letzten post syntaktisch falsch ist weil natürlich bei anführungszeichen der string als beendet gilt, wenn nicht excaped oder irgendwie unterbrochen und verknüpft wurde, aber das habe ich doch auch nirgends so gemacht? wenn doch, dann ist das ein tippfehler.

usereingaben, die in die datenbank gehen filter ich mit htmlspecialchar und mysql_real_escape_string.

wenn ich aber intern werte übergebe, also die nicht vom user kommen, dann brauche ich nicht mit htmlspecialchars und mysql_real_escape_string filtern.

dann muss ich lediglich entweder mit \ escapen oder string unterbrechen, dann vari, und dann string fortsetzen. wie mans macht is ja egal, kann man sich aussuchen und ich arbeite halt mit string unterbrechungen.

vielleicht habe ich dich nicht richtig verstanden, aber ich weiß jetzt nicht wo das problem dabei ist?

gruß
knuff

Habe ich eigentlich in #9 geschrieben. Ich sehe in #6 keine Behandlung von Kontextwechseln.

Für HTML bringt Backslash-Escaping auch nichts. Das existiert in HTML nicht.

Das sollte lediglich ein Beispiel sein, was ein Kontextwechsel ist und warum es wichtig ist, Kontextwechsel passend zu behandeln.

Das ist grundsätzlich schon mal gut, weil dir bewusst zu sein scheint, dass du Daten escapen musst, wenn du sie in HTML einsetzt. Das war in #6 nicht zu erkennen.

Andererseits setzt du htmlspecialchars an der falschen Stelle ein. In der Datenbank sollten die Originaldaten landen und nicht Daten, die für die Ausgabe in HTML-Code aufbereitet sind. Ansonsten müsstest du zum Beispiel das HTML-Escaping rückgängig machen, wenn du die Daten in einem Nicht-HTML-Kontext nutzen willst.

Mir ist unklar, was du mit dem Backslash an der Stelle erreichen willst, aber um die String-Konkatenation geht es mir nicht. Das kann man so machen.

in der datenbank landen die originaldaten, aber natürlich gefiltert oder soll ich mir schadcode in die db holen?

die daten die ich an das form übergebe kommen vom register.php script, dort werden die daten eingelesen und für die db gefiltert und eben bei erneuten aufruf des reg forms, falls falsche daten eingegeben wurden, wieder an das form übergeben, also natürlich nur die daten die korrekt eingegeben wurden, werden wieder ans form zurückgegeben, daher brauche ich bei der übergabe ans form nicht mehr filtern, weil dies alles schon in der register.php passiert ist.

und die daten werden nicht für die ausgabe in html code aufbereitet. die daten werden einfach von der register.php für den eintrag in die db gefiltert und wiederum wenn nötig an das formular zurückgegeben.

woher weißt du ob ich htmlspecialchars an der falschen stellen einsetze? das taucht in den code teilen die ich gepostet habe gar nicht auf?

und sorry aber ich versteh beim besten willen nicht was dich an meinen kontextwechseln stört.

gruß
knuff

In #6 steht zum Beispiel:

Dort ist keine korrekte Behandlung des Kontextwechsels von PHP nach HTML zu erkennen. Die sähe beispielsweise so aus:

Das meinte ich. Da haben wir uns wohl missverstanden.

Du musst lediglich den entsprechenden Kontextwechsel (wenn die Daten in HTML oder PDF oder TXT oder CSV oder eine Mail oder ein Bild oder… eingesetzt werden) an der Stelle passend behandeln, an der er stattfindet. Und eben nicht schon vorher, wenn du noch gar nicht weißt, auf welche Weise du die Daten ausgeben wirst.

Wenn du htmlspecialchars anwendest, bevor du die Daten in die Datenbank schreibst, bereitest du sie für die Ausgabe im HTML-Kontext vor.

Also… Ich habe gepostet, weil es nicht auftauchte. Dann hast du mir gesagt, wann du htmlspecialchars aufrufst (vor dem Eintragen der Daten in die Datenbank). Das habe ich dann als die falsche Stelle bezeichnet, weil die passende Behandlung von Kontextwechseln Sache der Ausgabe ist, da erst dort bekannt ist, in welchem Format die Daten ausgegeben werden sollen.

also bei diesem punkt verstehen wir uns wohl grad gar nicht. ich bereite die daten mit htmlspecialchars nicht für die ausgabe in html vor. ganz im gegenteil! ich bereite die daten mit htmlspecialchars für die datenbank vor, weil ich ja auf keinen fall html in meiner datenbank haben will. oder willst du html in deiner datenbank?

die praktischerweise schon gefilterten daten nutze ich für rückgabe an das html form, sofern nötig.

gruß
knuff

Ja, eigentlich schon, was spricht dagegen?
Du musst deinen Text ja auch formatieren und wenn du ihn im Kontext einer Internetseite darstellen willst, müssen die HTML Tags auch in die Datenbank. Das ist so usus.

Nachtrag: Das gilt natürlich nicht für Daten (im gegensatz zu Texten), da kommt es auf den Kontext an. Üblicherweise enthalten Daten kein HTML, aber um Daten zu validieren ist htmlspecialchars die falsche Funktion. HTML Entities will man nicht in der Datenbank.

jetzt weiß ich warum wir uns mißverstanden haben. ich habe es die ganze zeit so verstanden, das du dich auf das formular beziehst in dem user daten eingelesen werden und es war für mich ein rätsel dass du es nicht für nötig hielst diese daten zu filtern. aber du hast du hast dich auf content in der db bezogen. oh man haben wir lange aneinander vorbei geredet.

jetzt verstehe ich dich. aber nun musst du mir noch sagen warum htmlspecialchars die falsche funktion ist und welche denn die richtige ist?

gruß
knuff

1 &lt; 2 ist viel mehr HTML als 1 < 2. Das &lt; wird nämlich nur bei Ausgabe als HTML passend als < dargestellt. Also: Doch, du speicherst die Daten gezielt auf eine Weise, die nur bei Ausgabe als HTML Sinn ergibt.

Hm?
Ich habe mich auf beides bezogen. Je nachdem was du gesagt hast.

Du bist hier im Thread mehrmals hin und her geswitched. Anfänglich ging es um PHP in der Datenbank, das gehört da nicht hin. Auch ein HTML Forumlar gehört da nicht hin. Daten gehören natürlich in eine Datenbank und müssen je nach Kontext entsprechend gefiltert werden. Da wir bisher nur deine Ausgabe gesehen haben, hat mermshaus dich darauf hingewiesen, dass du den Kontextwechsel nicht beachtest. Daher hat auch niemand gesagt, dass du Daten nicht filtern sollst. Im gegenteil, du musst je nach Kontext deine Daten filtern. Dazu gab es auch schon Links.

htmlspecialchars ist die falsche Funktion um Daten für die Datenbank zu validieren, sie ist für die Ausgabe zuständig, wenn du kein HTML "ausführen" möchtest. z.b. in Formulafeldern oder HTML Attribute.
Manche verwenden sie als HTML Filter bei Usereingaben von aussen. Das hat aber Nachteile, weil dadurch auch Sonderzeichen und evtl. Umlaute unnötig umgewandelt werden und macht die Sache schwierig, wenn du dem User HTML teilweise erlauben möchtest.

Daher gibt es keine allgemeingültige Eingabevalidierung, was du aber in einer Datenbank immer machen musst, den Kontextwechsel beachten und schädliche Zeichen maskieren. Das steht aber alles genau in dem bereits verlinkten Artikel.