Hin und zurück (htmlspecialchars-mysql_real_escape_string)

[Ricko]

Hallo,.

Wenn ich meine eingehenden Variablen mit

htmlspecialchars ( $Variable );
mysql_real_escape_string($Variable);

behandel, muss ich sie dann zwingend bei der Ausgabe mit irgendwas behandeln, damit mir nicht der maskierte Code angezeigt wird?

Danke für Antwort, Rick

[ChrisB]

Hi,

Wenn ich meine eingehenden Variablen mit

htmlspecialchars ( $Variable );
mysql_real_escape_string($Variable);

behandel,

Warum machst du das?

muss ich sie dann zwingend bei der Ausgabe mit irgendwas behandeln, damit mir nicht der maskierte Code angezeigt wird?

Wenn du HTML-Sonderzeichen nicht ihrer Sonderbedeutung berauben willst - dann behandle sie gar nicht erst mit der entsprechenden Funktion.

Vielleicht solltest du mal den Artikel Kontextwechsel erkennen und behandeln lesen - scheint, als ob du da noch Verständnisprobleme hättest.

MfG ChrisB

[Ricko]

Warum machst du das?

Warum fragst Du?

[ChrisB]

Hi,

Warum machst du das?

Warum fragst Du?

Weil ich annahm, dass du dir bei der Verwendung von Funktionen irgendetwas denkst. Liege ich damit falsch?

MfG ChrisB

[Ricko]

Weil ich annahm, dass du dir bei der Verwendung von Funktionen irgendetwas denkst. Liege ich damit falsch?

Stückwerk aus Internetseiten zur Verhinderung von Hackern. Nur passt jezt eine Ausgabe nicht so, wie ich gerne hätt.

[ChrisB]

Hi,

Weil ich annahm, dass du dir bei der Verwendung von Funktionen irgendetwas denkst. Liege ich damit falsch?

Stückwerk aus Internetseiten zur Verhinderung von Hackern.

"Verhinderung von Hackern" - ist das auch sprachliches Stückwerk von der erwähnten Internetseite?

Nur passt jezt eine Ausgabe nicht so, wie ich gerne hätt.

Dann überleg' dir *vorher*, was wann wie zu behandeln ist - und kopiere weniger Murks "zur Verhinderung von Hackern", denn du nicht verstehst, von Internetseiten.

MfG ChrisB

[Ricko]

"Verhinderung von Hackern" - ist das auch sprachliches Stückwerk von der erwähnten Internetseite?

Es kann nicht jeder so eine geschliffene Rethorik haben, wie Du. *g*

Zitat:

und kopiere weniger Murks "zur Verhinderung von Hackern", denn du nicht verstehst, von Internetseiten.

[Der Martin]

Hallo,

htmlspecialchars ( $Variable );
mysql_real_escape_string($Variable);
Warum machst du das?
Warum fragst Du?

weil das völlig sinnlos ist. Mit htmlspecialchars() kannst du einen Wert behandeln, wenn du ihn in den HTML-Kontext bringst; mit mysql_real_escape_string() dann, wenn du ihn in einen SQL-Kontext bringst. Einfach mal so aus Lust und Laune einen Eingabewert, der von außen kommt, mit einer dieser Funktionen aufzubereiten, ist Unsinn.

So long,
 Martin

[Auge]

Hallo

Warum machst du das?

Warum fragst Du?

Weil du das, deiner Beschreibung nach, pauschal machen willst. Das ist aber falsch. Die von dir genannten Funktionen (htmlspecialchars, mysql_real_escape_string) müssen dann, wenn du deine Daten im Kontext, für den diese Funktionen gedacht sind, benutzen willst.

htmlspecialchars ist für den Fall gedacht, dass Daten in ein HTML-Dokument eigebunden werden sollen. mysql_real_escape_string behandelt Daten, die mit einem MySQL-Query benutzt werden, wenn z.B. Daten in eine DB eingetragen werden oder diese, im Rahmen einer WHERE-Klausel, zur Abfrage von Daten dienen.

Dann *und nur dann* kommen diese Funktionen zum Einsatz. Näheres erklärt der schon von Chris verlinkte Artikel.

Tschö, Auge

[Ricko]

Weil du das, deiner Beschreibung nach, pauschal machen willst.

Nur htmlspecialchars verwende ich pauschal. Ich such mal nach dem link wo das stand. Übersetz so nach dem Motto, alle POST Daten so behandeln, dann kein Javascriptcode durch Hacker möglich.

mysql_real_escape_string behandelt Daten, die mit einem MySQL-Query benutzt werden, wenn z.B. Daten in eine DB eingetragen werden oder diese, im Rahmen einer WHERE-Klausel, zur Abfrage von Daten dienen.

Ja, das benutz ich so. Bei Strings. Oder settype bei Integer, Float und Bolean.

Dann *und nur dann* kommen diese Funktionen zum Einsatz. Näheres erklärt der schon von Chris verlinkte Artikel.

Interessant. Aber für Nichtprofis schwer.

[Auge]

Hallo

Weil du das, deiner Beschreibung nach, pauschal machen willst.

Nur htmlspecialchars verwende ich pauschal. Ich such mal nach dem link wo das stand. Übersetz so nach dem Motto, alle POST Daten so behandeln, dann kein Javascriptcode durch Hacker möglich.

Tu es *nur dann*, wenn du die Daten (hier Strings) im HTML-Kontext ausgeben willst.

Beispiel: Die Eingaben eines Besuchers in einem Gästebuch müssen zum Abspeichern in einer MySQL-DB im Query mit mysql_real_escape_string maskiert werden. Wenn die Seite mit den Einträgen zur Ansicht aufgerufen wird, musst du *nun* die aus der Datenbank geholten Strings der Einträge mit htmlspecialchars behandeln, um etwaig vorhandene, unerwünschte Stringteile, z.B. JavaScript-Code, in der HTML-Ausgabe zu maskieren.

Tschö, Auge

[Ricko]

Tu es *nur dann*, wenn du die Daten (hier Strings) im HTML-Kontext ausgeben willst.

Beispiel: Die Eingaben eines Besuchers in einem Gästebuch müssen zum Abspeichern in einer MySQL-DB im Query mit mysql_real_escape_string maskiert werden. Wenn die Seite mit den Einträgen zur Ansicht aufgerufen wird, musst du *nun* die aus der Datenbank geholten Strings der Einträge mit htmlspecialchars behandeln, um etwaig vorhandene, unerwünschte Stringteile, z.B. JavaScript-Code, in der HTML-Ausgabe zu maskieren.

Tschö, Auge

Hi Auge, ja genau so stands auch auf der Site.

Also ist htmlchars eine Art Gegenstück zu mysql_real_escape_string?

[ChrisB]

Hi,

ja genau so stands auch auf der Site.

Und warum machst du's dann anders?

Also ist htmlchars eine Art Gegenstück zu mysql_real_escape_string?

Nein, absolut überhaupt nicht.

MfG ChrisB

[Ricko]

Nein, absolut überhaupt nicht.

MfG ChrisB

Anders ausgedrückt. Bei Eingang mysql_real_escape_string und bei Ausgabe htmlspecialchars. Das eine gegen Injections und das andere gegen Javascripte?
Und mysql_real_escape_string nimmt tatsächlich Kontakt zur DB auf??

[ChrisB]

Hi,

Anders ausgedrückt. Bei Eingang mysql_real_escape_string und bei Ausgabe htmlspecialchars.

Hör' auf, in "Richtungen" wie Ein- und Ausgang zu denken.

Verinnerliche stattdessen, dass du bei jedem Wechsel des *Kontextes* die Daten entsprechend den Regeln des Kontextes, in den sie überführt werden sollen, zu behandeln hast.

Und mysql_real_escape_string nimmt tatsächlich Kontakt zur DB auf??

Beschreibt das Manual nicht recht eindeutig, was die Funktion in der Hinsicht macht?

MfG ChrisB

[Ricko]

Hi,

Anders ausgedrückt. Bei Eingang mysql_real_escape_string und bei Ausgabe htmlspecialchars.

Hör' auf, in "Richtungen" wie Ein- und Ausgang zu denken.

Eingang in die db.
Ausgabe auf den Bildschirm.
Von Ausgang schrieb ich nie etwas.

[ChrisB]

Hi,

Eingang in die db.
Ausgabe auf den Bildschirm.
Von Ausgang schrieb ich nie etwas.

Schietegal, ob nun ein oder aus, Gang oder Gabe.

Kontextwechsel ist das einzig relevante Stichwort.

MfG ChrisB

[Ricko]

Hi,

Eingang in die db.
Ausgabe auf den Bildschirm.
Von Ausgang schrieb ich nie etwas.

Schietegal, ob nun ein oder aus, Gang oder Gabe.

Kontextwechsel ist das einzig relevante Stichwort.

Zitat:

Denn die Ausgabedaten des einen Systems sind nicht selten die Eingabedaten eines anderen Systems.

Quelle

Und nun nerv nicht weiter mit Bevormundungen. Hilf oder lass es. Aber nerv nicht!

[ChrisB]

Hi,

Zitat:

Denn die Ausgabedaten des einen Systems sind nicht selten die Eingabedaten eines anderen Systems.

Na gut, dann ist also die "Ausgabe" aus deiner DB die *Eingabe* für das Dokument, welches letztendlich auf deinem Bildschirm dargestellt werden soll.

Und nu, wie passt das zu deiner "htmlspecialchars für die Ausgabe"-Theorie?
(Rhetorische Frage)

Wie gesagt, das Denken in irgendwelchen "Richtungen" ist hier vollkommen überflüssig - Kontextwechsel ist das einzig relevante Stichwort.

Und nun nerv nicht weiter mit Bevormundungen.

Und du mach dir bitte eigenen Gedanken zur Thematik, anstatt nur mit Zitaten um dich zu werfen, von denen bezweifelt werden darf, ob du ihren Hintergrund bereits verstanden hast.

MfG ChrisB

[Ricko]

Na gut, dann ist also die "Ausgabe" aus deiner DB die *Eingabe* für das Dokument, welches letztendlich auf deinem Bildschirm dargestellt werden soll.

Und nu, wie passt das zu deiner "htmlspecialchars für die Ausgabe"-Theorie?
(Rhetorische Frage)

Bei Ausgabe eines Strings auf den Bildschirm wende ich htmlspecialchars an.
Mach Dich doch mal locker. Ich kenne die Fachbegriffe nicht, aber ich wende es doch richtig an.
Oder im ChrisB-Kontext (Du siehst, ich lerne): htmlspecialchars im machmichaufbildschirm-Kontext und mysql_real_escape_string im tumichindb-Kontext.

[ChrisB]

Hi,

Bei Ausgabe eines Strings auf den Bildschirm wende ich htmlspecialchars an.
Mach Dich doch mal locker. Ich kenne die Fachbegriffe nicht, aber ich wende es doch richtig an.

Gut - und dein Problem war noch gleich ...?

Oder im ChrisB-Kontext (Du siehst, ich lerne)

Hey, geht doch :-)

htmlspecialchars im machmichaufbildschirm-Kontext und mysql_real_escape_string im tumichindb-Kontext.

Dunkel glaube ich mich zu errinnern :-), dass ersteres dein ursprüngliches Problem verursachte - weil du "Daten" hast, die du bei der Ausgabe nach wie vor als HTML interpretiert, und nicht als reinen Text angesehen haben willst ...?
Dann dürfen diese natürlich nicht mit htmlspecialchars behandelt werden - und um das hinzukriegen, sollten sie dann auch von den restlichen Daten "getrennt aufbewahrt" werden.

MfG ChrisB

[Ricko]

Dunkel glaube ich mich zu errinnern :-), dass ersteres dein ursprüngliches Problem verursachte - weil du "Daten" hast, die du bei der Ausgabe nach wie vor als HTML interpretiert, und nicht als reinen Text angesehen haben willst ...?

Du solltest Dich langsam mal daran gewöhnen, dass es _ausschließlich_ um Kontextgerechte Behandlung geht. Ich weiß nicht, was Du immer mit "Ausgabe" meinst!

Dann dürfen diese natürlich nicht mit htmlspecialchars behandelt werden - und um das hinzukriegen, sollten sie dann auch von den restlichen Daten "getrennt aufbewahrt" werden.

Ich schau mal nach, ob ich noch nen alten Schuhkarton habe. Dann tu ich sie da rein.

[ChrisB]

Ich lass' dich jetzt einfach mal in dem Glauben schlafen gehen, es mir "richtig gegeben" zu haben, OK?

(Wenn ich das mit dir jetzt hier weiterführe und dir auch noch beispielhaft vormache, wie *richtiger* Sarkasmus in meinen Augen aussieht [im Gegensatz zu deinen platten Versuchen] - dann wird's ja letztendlich doch wieder nur gelöscht werden ...)

[Ricko]

Ich lass' dich jetzt einfach mal in dem Glauben schlafen gehen, es mir "richtig gegeben" zu haben, OK?

Das ist mir ziemlich latte. Hauptsache, _Du_ gehst mal so langsam schlafen. *g*

[Bademeister]

Hi Ricko,
ich möchte mal gerade versuchen, noch etwas zum Grundverstaendnis beizutragen:

Funktionen wie hmtlspecialchars und mysql_real_escape_string haben nicht den Zweck, einen String (nachhaltig) zu veraendern!

Wenn ich (in PHP) einen String der Form "Peter O'Donnel" habe und diesen in eine MySQL-Datenbank speichern will, dann habe ich das Problem, dass in SQL das String-Literal "Peter O'Donnel" diesen String nicht repraesentiert, weil es (nun, ım SQL-Kontext) ein Sonderzeıchen enthaelt.

mysql_real_escape_string darauf angewandt, liefert etwa den (PHP-)String "Peter O'Donnel", und dieser, als String-Literal in SQL angwandt, produziert wieder exakt den gewünschten String "Peter O'Donnel", der in der Datenbank gespeichert wird.

Fazit: Der String in der Datanbank ist exakt derselbe, den wir anfangs auch in PHP hatten (und das ist gut so, denn genau den wollten wir ja speichern), und daher gibt es *nichts*, was beim Auslesen wieder rueckgaengig gemacht werden koennte oder muesste. Wenn Du Dich nach dem Auslesen dafuer entscheiden solltest, den String in einem HTML-Dokument auszugeben, dann musst Du wiederum fuer den HTML-Quelltext ein Literal produzieren, das in HTML den String "Peter O'Donnel" repraesentıert. Dafuer gibts htmlspecialchars (auch wenn in dem Fall keine Sonderzeichen im String sind).

Also: Da wird ueberhaupt nichts rueckgaengig gemacht, mysql_real_escape_string und html_specialchars haben nicht die Bohne miteinander zu tun.

Und jetzt kannste Dich weıter mit ChrısB streiten gehen ;-)

Viele Gruesse,
der Bademeister

[Ricko]

Hi Ricko,
ich möchte mal gerade versuchen, noch etwas zum Grundverstaendnis beizutragen:

Hallo Bademeister,

erstmal danke für Deine Mühe um m ein Grundverständnis.

Funktionen wie hmtlspecialchars und mysql_real_escape_string haben nicht den Zweck, einen String (nachhaltig) zu veraendern!

Oh.

Fazit: Der String in der Datanbank ist exakt derselbe, den wir anfangs auch in PHP hatten (und das ist gut so, denn genau den wollten wir ja speichern), und daher gibt es *nichts*, was beim Auslesen wieder rueckgaengig gemacht werden koennte oder muesste. Wenn Du Dich nach dem Auslesen dafuer entscheiden solltest, den String in einem HTML-Dokument auszugeben, dann musst Du wiederum fuer den HTML-Quelltext ein Literal produzieren, das in HTML den String "Peter O'Donnel" repraesentıert. Dafuer gibts htmlspecialchars (auch wenn in dem Fall keine Sonderzeichen im String sind).

Ich glaube, jetzt verstehe ich das. Also liefern die beiden Funktionen völlig unabhängig voneinander denselben String ab, nur für unterschiedliche Empfänger und eben in deren Interpretationsweise. Aber der String bleibt immer derselbe und wird nur zur Übergabe kodiert, um, einmal angekommen, wieder er selbst und unverändert zu sein?
Vielleicht sollte ein Forum auch so funktionieren. Bliebe die Frage, wer stellt sich auf wen ein? :-))

Danke jedenfalls für Deine Erklärung, ganz in der Hoffnung, es verstanden zu haben :-)

Und jetzt kannste Dich weıter mit ChrısB streiten gehen ;-)

Wer ist ChrisB? ;-)

Viele Gruesse,
der Bademeister

Und Grüße zurück

Ricko

[Malcolm Beck´s]

hi,

Ricko

Über Lothar zu Thomas hin zu Ricko -- nur die Qualität deiner Postings, die lässt mit allen Namen zu wünschen übrig -- hat aber einen unverkennbaren wiedererkennungswert.

mfg

[Bademeister]

Ich glaube, jetzt verstehe ich das. Also liefern die beiden Funktionen völlig unabhängig voneinander denselben String ab, nur für unterschiedliche Empfänger und eben in deren Interpretationsweise.

An dieser Stelle kommt man nicht drumrum, zwischen dem String und seinen Literalen zu unterscheiden. Die beiden Funktionen geben (im PHP-Kontext) natürlich verschieden Strings zurück. Und zwar Strings, die in der jeweiligen Sprache das Literal desselben Strings "Peter O'Donnel" sind.

Die Zeichenkette, die uns interessiert (in meinem obigen Beispiel), ist und bleibt immer die Zeichenkette "Peter O'Donnel".
Wenn wir diesen Namen in der Datenbank speichern, dann wollen wir in der Datenbank - klar - exakt "Peter O'Donnel" stehen haben.
Wenn wir den Namen in einem HTML-Dokument ausgeben wollen, dann soll in dem Dokument (nicht im HTML-Quellcode, sondern im Dokument!) auch exakt die Zeichenkette "Peter O'Donnel" stehen.
Wenn wir ihn in ein PDF-Dokument schreiben wollen, dann soll.... genau. Und so weiter.

Also gehen wir her und generieren *zu dem Zeitpunkt*, zu dem wir den String "Peter O'Donnel" in einer bestimmten Sprache (SQL, HTML,...) beschreiben müssen, das entsprechende Literal dieses Strings. In der Datenbank aber hat nichts anderes als exakt der originäre String "Peter O'Donnel" etwas zu suchen. Denn die Datenbank hat nicht zu entscheiden, ob wir den String später in ein HTML-Dokument oder ein PDF-Dokument oder ein Word-Dokument schreiben oder vielleicht auch nur mit einer User-Eingabe vergleichen oder sonst was damit machen wollen.

Aber der String bleibt immer derselbe und wird nur zur Übergabe kodiert, um, einmal angekommen, wieder er selbst und unverändert zu sein?

Ganz genau.

Viele Grüße,
der Bademeister

[Ricko]

Viele Grüße,
der Bademeister

Hi (wie immer Du heißt!) Bademeister,

kannst Du nicht demnächst öfter mal antowrten? ;-)

Endlich einer, der "kontextgerecht" etwas erklärt!!!!!!! (ne wat bin ich lernfähig *g*)

Aber im Ernst: Klasse, wie Du ein für Nichtprofis wirklich schwieriges Thema kontextgerecht auf die Sprache desselben gebracht hast. Das ist ein Talent, was wahrhaftig nicht jeder hat. Danke!

Und Grüße, Ricko

[Ricko]

Beispiel: Die Eingaben eines Besuchers in einem Gästebuch müssen zum Abspeichern in einer MySQL-DB im Query mit mysql_real_escape_string maskiert werden.

Aber auch, wenn ich irgendwo eine Zahl erwarte und den Input des Users mit settype in einen Integer gewandelt habe? Danach sollte mysql_real_escape_string doch unnötig sein??

[Auge]

Hallo

Beispiel: Die Eingaben eines Besuchers in einem Gästebuch müssen zum Abspeichern in einer MySQL-DB im Query mit mysql_real_escape_string maskiert werden.

Aber auch, wenn ich irgendwo eine Zahl erwarte und den Input des Users mit settype in einen Integer gewandelt habe? Danach sollte mysql_real_escape_string doch unnötig sein??

Ja, dann ist es unnötig. Mit $zahl = (int) $bla; wird der Inhalt von $bla zu einer Integerzahl, im Zweifelsfall 0. Das geht bei Inetegerzahlen auch mit intval (analog auch mit anderen Typen (siehe "siehe auch" ebenda)).

In der Datenbank stünde jedenfalls immer eine Integerzahl und solche sind bei der Übertragung per Query ungefährlich, wenn sie dort stehen, wo sie hingehören.

Tschö, Auge

[dedlfix]

Hi!

Näheres erklärt der schon von Chris verlinkte Artikel.
Interessant. Aber für Nichtprofis schwer.

Dann wäre es sehr schön, wenn du das, was dir nicht verständlich erscheint, genauer auf den Punkt bringen könntest, damit man das eventuell ändern kann. Mit einer solch pauschalen, kurzen Aussage kann ich als Autor nicht viel anfangen.

Lo!