Hallo,

bitte schlagt mich nicht gleich, aber ich habe keine andere Idee, woran
es liegen könnte:

Ich möchte per input-Textfeld folgenden String in eine MySQL-DB
speichern:

Test\String

Die $_POST Variable behandle ich lediglich mit strip_tags() um keinen

$name = strip_tags($_POST['name']);

anderen Code mit zu übernehmen

Die HTML-Seite mit dem Formular ist UTF-8 codiert:

Gespeichert wird per:
$result = mysql_query("UPDATE $tbl SET name = '$name' ... ");

zum Testen gebe ich per echo() aus:

echo "UPDATE $tbl SET name = '$name'";

Lokal bekomme ich dabei:
UPDATE tabelle SET name = 'Test\\String'
und der String wird mit Backslash an die DB weitergereicht.

Auf dem Webspace wird ausgegeben:
UPDATE tabelle SET name = 'Test\String'
und der String wird ohne Backslash in die DB geschrieben.

Wieso erreiche ich auf diesen beiden
Umgebungen hier zwei verschiedene Ergebnisse?

Günter

Günter Baier schrieb:

>Die $_POST Variable behandle ich lediglich mit strip_tags()

Unnötig, hat aber nichts mit deinem Problem zu tun.

>Wieso erreiche ich auf diesen beiden
>Umgebungen hier zwei verschiedene Ergebnisse?

Stichwort http://php.net/magic_quotes, und nein, du willst es auch lokal
ausschalten und stattdessen mysql_real_escape_string anwenden.

--
Wolfgang Fellger

Wolfgang Fellger wrote:
> Günter Baier schrieb:
>
>
>>Die $_POST Variable behandle ich lediglich mit strip_tags()
>
>
> Unnötig, hat aber nichts mit deinem Problem zu tun.

Richtig. Aber warum unnötig?
Wenn ein User nun in das Formular

<b>Test\String</b>

dann wird das so in die DB geschrieben - ist dann aber eher unschön.
Abgesehen davon, dass das auch unschöne JS-Befehle mitschleifen kann.
Bisher war ich davon ausgegangen, dass das strip_tags zumindest
einen Teil zur sicheren Programmierung beigetragen hat - ist dem nicht so?


>
>>Wieso erreiche ich auf diesen beiden
>>Umgebungen hier zwei verschiedene Ergebnisse?
>
>
> Stichwort http://php.net/magic_quotes, und nein, du willst es auch lokal
> ausschalten und stattdessen mysql_real_escape_string anwenden.
>

Ist eine Behandlung der $_POST-Variablen mit:

$name = mysql_real_escape_string($_POST['name']);

eine dumme Art, die Variablen zu behandeln bzw. ist das im
Manual vorgeschrieben Beispiel dem vorzuziehen?

Günter

..oO(Günter Baier)

>Richtig. Aber warum unnötig?
>Wenn ein User nun in das Formular
>
><b>Test\String</b>
>
>dann wird das so in die DB geschrieben - ist dann aber eher unschön.
>Abgesehen davon, dass das auch unschöne JS-Befehle mitschleifen kann.
>Bisher war ich davon ausgegangen, dass das strip_tags zumindest
>einen Teil zur sicheren Programmierung beigetragen hat - ist dem nicht so?

Jein. Bei der Ausgabe von Daten in ein HTML-Dokument ist i.d.R. ohnehin
ein Aufruf von htmlspecialchars() erforderlich, welches auch gleich
evtl. vom Benutzer eingegebenen HTML-Code entschärft - der Code wird
dann einfach so ausgegeben, wie er ist, ohne vom Browser als HTML
interpretiert zu werden. Ein strip_tags() erhöht also nicht unbedingt
die Sicherheit, sondern dient höchstens der Aufhübschung. Ich verzichte
darauf aber. Wenn ein Benutzer Mist eingibt, dann bekommt er diesen Mist
eben auch wieder angezeigt. Fertig.

>Ist eine Behandlung der $_POST-Variablen mit:
>
>$name = mysql_real_escape_string($_POST['name']);
>
>eine dumme Art, die Variablen zu behandeln

Ja. mysql_real_escape_string() dient einzig und allein der sicheren
Übertragung von Strings in eine MySQL-Datenbank. Für alle anderen
Anwendungsfälle ist es sinnlos oder gar schädlich.

Du solltest innerhalb Deiner Applikation grundsätzlich mit Rohdaten
arbeiten, d.h. ohne irgendeine spezielle Codierung, ohne Magic Quotes
oder sonstiges Geraffel. Erst bei der Ausgabe bzw. der Weiterverarbei-
tung dieser Daten kommen die jeweils dazu nötigen Maskierungs- und
Escapingfunktionen zum Einsatz: mysql_real_escape_string() für das
Speichern von Strings in MySQL, htmlspecialchars() für die Ausgabe auf
einer HTML-Seite usw.

Jedes "Zielmedium" hat seine eigenen Maskierungsfunktionen - und nur
dann sollten diese auch benutzt werden.

Micha

Michael Fesser wrote:
> .oO(Günter Baier)
>
>
>>Richtig. Aber warum unnötig?
>>Wenn ein User nun in das Formular
>>
>><b>Test\String</b>
>>
>>dann wird das so in die DB geschrieben - ist dann aber eher unschön.
>>Abgesehen davon, dass das auch unschöne JS-Befehle mitschleifen kann.
>>Bisher war ich davon ausgegangen, dass das strip_tags zumindest
>>einen Teil zur sicheren Programmierung beigetragen hat - ist dem nicht so?
>
>
> Jein. Bei der Ausgabe von Daten in ein HTML-Dokument ist i.d.R. ohnehin
> ein Aufruf von htmlspecialchars() erforderlich, welches auch gleich
> evtl. vom Benutzer eingegebenen HTML-Code entschärft - der Code wird
> dann einfach so ausgegeben, wie er ist, ohne vom Browser als HTML
> interpretiert zu werden. Ein strip_tags() erhöht also nicht unbedingt
> die Sicherheit, sondern dient höchstens der Aufhübschung. Ich verzichte
> darauf aber. Wenn ein Benutzer Mist eingibt, dann bekommt er diesen Mist
> eben auch wieder angezeigt. Fertig.


Was allerdings schwierig wird, wenn viele User für alle lesbar etwas
eingeben können.


>
>
>>Ist eine Behandlung der $_POST-Variablen mit:
>>
>>$name = mysql_real_escape_string($_POST['name']);
>>
>>eine dumme Art, die Variablen zu behandeln

Auch wenn $name dann direkt an mysql_query übergeben wird?

>
> Ja. mysql_real_escape_string() dient einzig und allein der sicheren
> Übertragung von Strings in eine MySQL-Datenbank. Für alle anderen
> Anwendungsfälle ist es sinnlos oder gar schädlich.
>
> Du solltest innerhalb Deiner Applikation grundsätzlich mit Rohdaten
> arbeiten, d.h. ohne irgendeine spezielle Codierung, ohne Magic Quotes
> oder sonstiges Geraffel. Erst bei der Ausgabe bzw. der Weiterverarbei-
> tung dieser Daten kommen die jeweils dazu nötigen Maskierungs- und
> Escapingfunktionen zum Einsatz: mysql_real_escape_string() für das
> Speichern von Strings in MySQL, htmlspecialchars() für die Ausgabe auf
> einer HTML-Seite usw.
>
> Jedes "Zielmedium" hat seine eigenen Maskierungsfunktionen - und nur
> dann sollten diese auch benutzt werden.
>

OK. Verstanden.
Das wäre mal sinnvoll, wenn das von Anfang an bei allen PHP/MySQL -
Tutorials mit dabei stehen würde oder in den Büchern, und nicht erst
über den Umweg der "einfachen" Erläuterung, um dann mal später darauf zu
stossen.

G.

> OK. Verstanden.
> Das wäre mal sinnvoll, wenn das von Anfang an bei allen PHP/MySQL -
> Tutorials mit dabei stehen würde oder in den Büchern, und nicht erst
> über den Umweg der "einfachen" Erläuterung, um dann mal später darauf zu
> stossen.

Tja, die sind nicht unbedingt gut - meins hat damals (6 1/2 Jahre) noch
Superglobals gelehrt und leckeres Zeug wie
if($möglicherweiseuninitialisiertevariable) {...}. Dementsprechend sah
mein erstes Glomp auch aus...

Andererseits will man dem Anfänger ja auch nicht gleich alles um die
Ohren hauen. Vielleicht wäre ein Vermerk in Richtung "Alles bis Kapitel
7 (Sicherheit) hat nur etwas auf Ihrer lokalen Testumgebung zu suchen"
hilfreich ;-)

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

..oO(Günter Baier)

>Michael Fesser wrote:
>>
>>>Ist eine Behandlung der $_POST-Variablen mit:
>>>
>>>$name = mysql_real_escape_string($_POST['name']);
>>>
>>>eine dumme Art, die Variablen zu behandeln
>
>Auch wenn $name dann direkt an mysql_query übergeben wird?

Auch dann würde ich mysql_real_escape_string() erst dann aufrufen, wenn
es wirklich daran geht, das Ding in die Datenbank zu schieben (wobei ich
mittlerweile PDO und prepared statements bevorzuge - solltest Du Dir
auch mal anschauen).

Vorher, um den Wert in mein Script zu kriegen, würde ich lediglich mit
get_magic_quotes_gpc() prüfen, ob dieser durch Magic Quotes "verseucht"
wurde und dann ggf. stripslashes() aufrufen (mit PHP 6 wird dieser MQ-
Unsinn endlich ein Ende haben). Das läßt sich relativ bequem in einer
Funktion kapseln. Wenn ich den Wert dann in "Rohform" in meinem Script
habe, kann ich damit alles machen, was ich will.

Möglicherweise will ich ja $_POST['name'] nicht nur in die Datenbank
schreiben, sondern auch in ein Logfile oder per E-Mail an mich senden.
Da wären dann die durch mysql_real_escape_string() hinzugefügten Escape-
Zeichen sehr hinderlich.

Micha

Michael Fesser wrote:
> .oO(Günter Baier)
>
>
>>Michael Fesser wrote:
>>
>>>>Ist eine Behandlung der $_POST-Variablen mit:
>>>>
>>>>$name = mysql_real_escape_string($_POST['name']);
>>>>
>>>>eine dumme Art, die Variablen zu behandeln
>>
>>Auch wenn $name dann direkt an mysql_query übergeben wird?
>
>
> Auch dann würde ich mysql_real_escape_string() erst dann aufrufen, wenn
> es wirklich daran geht, das Ding in die Datenbank zu schieben (wobei ich
> mittlerweile PDO und prepared statements bevorzuge - solltest Du Dir
> auch mal anschauen).


Mache ich: Ansonsten gilt das?:

$query = sprintf("INSERT INTO products (`name`, `description`,
`user_id`) VALUES ('%s', '%s', '%d')",
mysql_real_escape_string($product_name, $link),
mysql_real_escape_string($product_description, $link),
$_POST['user_id']);`


OK, aber lesbarer ist das dann nicht wirklich ... aber gut.

> Möglicherweise will ich ja $_POST['name'] nicht nur in die Datenbank
> schreiben, sondern auch in ein Logfile oder per E-Mail an mich senden.
> Da wären dann die durch mysql_real_escape_string() hinzugefügten Escape-
> Zeichen sehr hinderlich.

Stimm auch wieder.

G.

Günter Baier schrieb:

> Michael Fesser wrote:
>
>> .oO(Günter Baier)
>>
>>> Wenn ein User nun in das Formular
>>>
>>> <b>Test\String</b>
>>>
>>> dann wird das so in die DB geschrieben - ist dann aber eher unschön.

Unschön vielleicht, aber bei korrekter Behandlung nicht weiter gefährlich.

>> Wenn ein Benutzer Mist eingibt, dann bekommt er diesen Mist
>> eben auch wieder angezeigt. Fertig.
>
> Was allerdings schwierig wird, wenn viele User für alle lesbar etwas
> eingeben können.

Was soll daran "schwierig" sein?

Ich sehe das in diesem Fall eher als erzieherische Maßnahme: Wenn jeder
den Mist lesen kann, den dieser eine Benutzer eingibt, wird sich das
sicher recht schnell positiv auf dessen Schreibstil auswirken :-)

Merke: Alles, was in die DB kommt, wird mit mysql_real_escape_string()
vorbehandelt, alles, was auf den Bildschirm kommt, mit htmlspecialchars().

Mehr ist nicht nötig.

Gruß. Claus

Hadanite Marasek wrote:
>>OK. Verstanden.
>>Das wäre mal sinnvoll, wenn das von Anfang an bei allen PHP/MySQL -
>>Tutorials mit dabei stehen würde oder in den Büchern, und nicht erst
>>über den Umweg der "einfachen" Erläuterung, um dann mal später darauf zu
>>stossen.
>
>
> Tja, die sind nicht unbedingt gut - meins hat damals (6 1/2 Jahre) noch
> Superglobals gelehrt und leckeres Zeug wie
> if($möglicherweiseuninitialisiertevariable) {...}. Dementsprechend sah
> mein erstes Glomp auch aus...
>
> Andererseits will man dem Anfänger ja auch nicht gleich alles um die
> Ohren hauen. Vielleicht wäre ein Vermerk in Richtung "Alles bis Kapitel
> 7 (Sicherheit) hat nur etwas auf Ihrer lokalen Testumgebung zu suchen"
> hilfreich ;-)
>

Stimmt schon, nur dass es natürlich dann "todsicher" vorkommt, dass auch
ein Anfänger schon mehrere Projekte abgeliefert hat, diese auch
funktionieren, aber dann eben ohne die Feinheiten. Nicht zu ändern, aber
ärgerlich.

G.

Günter Baier schrieb:
> Michael Fesser wrote:
>> .oO(Günter Baier)
>>
>>
>>> Michael Fesser wrote:
>>>
>>>>> Ist eine Behandlung der $_POST-Variablen mit:
>>>>>
>>>>> $name =3D mysql_real_escape_string($_POST['name']);
>>>>>
>>>>> eine dumme Art, die Variablen zu behandeln
>>>
>>> Auch wenn $name dann direkt an mysql_query übergeben wird?
>>
>>
>> Auch dann würde ich mysql_real_escape_string() erst dann aufrufen, w=
enn
>> es wirklich daran geht, das Ding in die Datenbank zu schieben (wobei i=
ch
>> mittlerweile PDO und prepared statements bevorzuge - solltest Du Dir
>> auch mal anschauen).
>
>
> Mache ich: Ansonsten gilt das?:
>
> $query =3D sprintf("INSERT INTO products (`name`, `description`,
> `user_id`) VALUES ('%s', '%s', '%d')",
> mysql_real_escape_string($product_name, $link),
> mysql_real_escape_string($product_description, $link),
> $_POST['user_id']);`
>
>
> OK, aber lesbarer ist das dann nicht wirklich ... aber gut.

$query =3D sprintf("INSERT INTO products ('name', 'description',
'user_id') VALUES ('%s', '%s', '%d')",
mysql_real_escape_string($product_name, $link),
mysql_real_escape_string($product_description, $link),
$_POST['user_id']
);

Keiner sagt du sollst einen Einzeiler bzw. keine Einrueckungen machen
;). Kommt allerdings hier im MUA mit max. Zeilenlaenge von ~70 unter
Umstaenden nicht so gut rueber. Fakt ist das diese Schreibweise
übersichtlicher und leicher erweiterbar ist.

Zu mysql_real_escape_string() sei noch anzumerken das der 2. Parameter
zwar optional ist, allerdings bei Aufruf der Funktion dafuer gesorgt
sein muss das bereits eine Verbindung zur DB bestehen muss. Der Grund
liegt darin das die Funktions auch den Zeichensatz mit beachtet welcher
per Default oder über SET NAMES gesetzt wird nach dem Aufbau der Verbin=
dung.

Auf die Backticks wüerde ich verzichten und lieber Spaltennamen waehlen=

welche nicht in der Liste der reservierten Wörter vorkommen. Evt. nimmt=

man eine Abk. der Tabelle als Prefix und hat somit auch gleiche
eindeutige Spaltennamen für JOINS.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Joerg Behrens schrieb:
> $query = sprintf("INSERT INTO products ('name', 'description',
> 'user_id') VALUES ('%s', '%s', '%d')",
> mysql_real_escape_string($product_name, $link),
> mysql_real_escape_string($product_description, $link),
> $_POST['user_id']
> );

'%d' <--- sind da nicht die Hochkommas störend wenn es sich um eine Zahl
handelt?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Joerg Behrens schrieb:

>> $query =3D sprintf("INSERT INTO products ('name', 'description',
>> 'user_id') VALUES ('%s', '%s', '%d')",
>> mysql_real_escape_string($product_name, $link),
>> mysql_real_escape_string($product_description, $link)=
,
>> $_POST['user_id']
>> );

> '%d' <--- sind da nicht die Hochkommas störend wenn es sich um eine Z=
ahl
> handelt?

Sie sind überflüssig; MySQL stört sich daran jedoch nicht.

MfG
Niels



--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

> <b>Test\String</b>
>
> dann wird das so in die DB geschrieben - ist dann aber eher unschön.

Ist denn völlig ausgeschlossen, das ein Benutzer sowas schreiben _will_?
Z.B. im Satz
"Mit <b> kannst Du in HTML Text fett machen."?
Warum willst Du die Texte der Benutzer verstümmeln?

Christoph Herrmann schrieb:
> Joerg Behrens schrieb:
>> $query =3D sprintf("INSERT INTO products ('name', 'description',
>> 'user_id') VALUES ('%s', '%s', '%d')",
>> mysql_real_escape_string($product_name, $link),
>> mysql_real_escape_string($product_description, $link)=
,
>> $_POST['user_id']
>> );
>
> '%d' <--- sind da nicht die Hochkommas störend wenn es sich um eine Z=
ahl
> handelt?

Stoerend im Falle von MySQL nicht. Aber die waren im Beispiel des OPs
schon drin und sind mir nicht aufgefallen.
Aber du hast Recht das sie weggelassen gehoeren. Das ein oder an RDBMs
wuerde sich daran auch stoeren.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Joerg Behrens schrieb:
> Stoerend im Falle von MySQL nicht. Aber die waren im Beispiel des OPs
> schon drin und sind mir nicht aufgefallen.
> Aber du hast Recht das sie weggelassen gehoeren. Das ein oder an RDBMs
> wuerde sich daran auch stoeren.

War mir jetzt neu, dass MySQL so tolerant ist. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Jonas Werres schrieb:
>
>> <b>Test\String</b>
>>
>> dann wird das so in die DB geschrieben - ist dann aber eher unschön.
>
> Ist denn völlig ausgeschlossen, das ein Benutzer sowas schreiben _will_?

Man denke da nur an Seiten wie ebay, myspace, beepworld... und kann das
in solchen Fällen tatsächlich vollkommen ausschließen. Ein strip_tags()
wäre bei den genannten Beispielen zudem wirklich ein sinnvoller Beitrag
zur Netzkultur und Sicherheit gewesen ;)

Suat Özgür schrieb:

>Man denke da nur an Seiten wie ebay, myspace, beepworld... und kann das
>in solchen Fällen tatsächlich vollkommen ausschließen.

Du kannst bei Millionen von Nutzern ausschließen, dass irgendjemand Text
verwenden will, den man eventuell als HTML interpretieren könnte? Wow.

Die Kernfrage "Warum willst Du die Texte der Benutzer verstümmeln?" hast du
ja sicherheitshalber weggeschnitten.

--
Wolfgang Fellger

Hi!

Jonas Werres schrieb:
>> <b>Test\String</b>
>>
>> dann wird das so in die DB geschrieben - ist dann aber eher unschön.=

> Ist denn völlig ausgeschlossen, das ein Benutzer sowas schreiben _wil=
l_?
> Z.B. im Satz
> "Mit <b> kannst Du in HTML Text fett machen."?
> Warum willst Du die Texte der Benutzer verstümmeln?

Noch schlimmer ist es, wenn der String etwa so aussieht:

$string =3D 'Das kostet <5 Euro und ist ziemlich billig';

Natürlich ist das konstruiert, aber so etwas könnte jemand wirklich
schreiben. Und in diesem Fall schnippelt strip_tags alles weg und es
bleibt nur "Das kostet " übrig.

Grüße,

Nico