Hi!
// Maskierende Slashes aus POST Array entfernen
if (get_magic_quotes_gpc()) { $_POST = array_map( 'stripslashes', $_POST ); }
> Wofür soll das gut sein?
PHP versaut die Eingabedaten, wenn das Feature Magic Quotes eingeschaltet ist, indem es sie durch addslashes() schickt. Das braucht man nur, wenn man die Eingabedaten unbeachtet als String in ein SQL-Statement übergibt. Wenn du hingegen selbst maskieren willst oder einen Mechanismus verwendest, der keine Maskierung benötigt - Prepared Statements sind ein solcher - dann stören die Maskierungszeichen und müssen entfernt werden. Der gezeigte Einzeiler ist aber nur für "flache Eingabedaten" geeignet. Wenn mit [] im name-Attribut ein Array erzeugt wird, muss man das auch berücksichtigen. Im Handbuch-Kapitel [Disabling Magic Quotes](http://www.php.net/manual/en/security.magicquotes.disabling.php) ist ein Beispiel enthalten, das auch beliebig verschachtelte Werte behandelt.
> Wenn ich (wie auch in diesem Beispielskript auf der Seite) einen neunen Datensatz mit Prepared Statements, also objektorientiert, übermittle, dann brauche ich mich doch nicht um Magic Quotes oder Ähnliches kümmern.
Prepared Statements haben nichts mit objektorientiert zu tun. Um die Magic Quotes musst du dich wie gesagt kümmern, denn die stören. Ansonsten kannst du problemlos Rohdaten verwenden und solltest das auch tun.
> Meine einzige kontextbezogene "Behandlung" von Usereingaben ist, dass ich bei der Ausgabe - zB. bei einem Gästebuch - die Funktion [htmlentities](http://at2.php.net/manual/de/function.htmlentities.php) verwende.
Warum htmlentities() und nicht nur htmlspecialchars()? Arbeitest du intern mit einer anderen Zeichenkodierung als in Richtung Browser?
> Genau das \_ist\_ doch der Vorteil bei mysqli, wenn ich mit Prepared Statements Datensätze objektorientiert übermittle, dass ich dann \_keine\_ Angst vor SQL Injektions haben muß bzw. keine Gegenmaßnahmen treffen muß.
Angst muss man nie haben, wenn man das Prinzip verstanden hat, dass Daten stets kontextgerecht zu notieren sind.
Lo!