nicht angemeldet
echo $begrüßung;
Die Reihenfolge wäre zu ändern. Zuerst sollten die eventuellen Auswirkungen von Magic Quotes entfernt werden, da dies als letztes hinzugefügt wurde, bevor PHP die Daten an dein Script übergeben hat. Ich würde das mit der im Handbuch angeführten Funktion generell und für alle Eingabedaten einmalig am Scriptanfang durchführen. Das kann man dann leichter entfernen, wenn man später auf PHP6 umsteigt.
Das ist mir leider zu hoch, um es zu verstehen. :-( Mein bisheriges Wissen stammt unter anderem von der entsprechenden mysql_real_escape_string-Seite im php-Handbuch.
Vielleicht möchtest du mit den Formularwerten noch etwas anderes machen, als sie nur in der Datenbank abzulegen. Zum Beispiel auch noch anzeigen ("Folgende Daten wurden gespeichert: ...").
Es ist nicht immer günstig, alles auf einmal und so wie es gerade anfällt zu programmieren. Eine klare Strukturierung und Trennung/Abgrenzung der einzelnen Teilaufgaben erhöht die Wartbarkeit bei komplexer werdenden Scripten.
Die Magic Quotes haben mit der eigentlichen Aufgabe deines Script nichts weiter zu tun. Sie zu beseitigen ist nur notwendiges Übel. Deswegen empfahl ich, sie aus dem eigentlichen Scriptverlauf auszuklammern und unabhängig von allem anderen am Scriptanfang zu erledigen. Example 31-2 wirkt direkt auf $_POST, $_GET, $_COOKIE und $_REQUEST. Du kannst also im weiteren Verlauf wie gewohnt auf $_XXX['foo'] zugreifen.
Es ist ziemlich egal, ob du Zahlenwerte einfach so hinschreibst oder in Gänsefüße setzt
SELECT ... FROM foo WHERE zahl=42 oder
SELECT ... FROM foo WHERE zahl="42"
INSERT INTO foo SET zahl=42 oder
INSERT INTO foo SET zahl="42"
Du musst also nicht den Aufwand treiben, bei den Benutzereingaben zwischen Zahlenwerten und Strings zu unterscheiden und sie unterschiedlich zu quoten. Einfach alle Benutzerwerte gänsefüßen und mysql_real_escape_string() drauf anwenden. Dann beschränkt sich das Statement-Zusammenbauen (ohne Plausibilitätsprüfung) auf das erwähnte (diesmal mit INSERT)
$sql = sprintf('INSERT INTO foo SET feld1="%s", feld2="%s"',
mysql_real_escape_string($_POST['feld1']),
mysql_real_escape_string($_POST['feld2']));
Einfache Plausibilitätsprüfungen kann man auch direkt auf die $_POST-Werte ansetzen, ohne sie umzukopieren:
if (! valid($_POST['feld1']))
//...
Vermutlich möchtest du ja dann sowieso die Benutzereingaben ignorieren und einen anderen Verlauf im Script nehmen, z.B. anstatt die Daten der Datenbank zu übergeben eine Fehlermeldung ausgeben und/oder sie per Affenformular dem Anwender wieder vor die Füße werfen.
Das Anlegen einer extra-Variable ist immer noch ein unnötiger Zwischenschritt.
Das hab ich aber jetzt in der else-Anweisung wieder drin. :-( Für den Fall, daß die if-Bedingung _nicht_ erfüllt ist, _muß_ ich die Anweisung doch schreiben, oder?
Wenn eine neue Variable in einer bedingten Anweisung (if) angelegt wird ist es immer wichtig, alle Verzweigungen zu berücksichtigen. Oder man verwendet bei einfachen bedingten Deklarationen den ternary operator
$var = bedingung ? 'erfüllt' : ' nicht erfüllt';
Die Frage ist, ob es sich wirklich lohnt, eine neue Variable anzulegen. Bei meiner obigen Vereinfachung ist es nicht nötig.
Bei deinem ursprünglichen Beispiel
$beispielwert = $_POST['beispielwert'];
$beispielwert = strip_tags($beispielwert);
...
lassen sich beide Zeilen zu einer zusammenfassen.
$beispielwert = strip_tags($_POST['beispielwert']);
...
1.) KEINE html-Tags gespeichert und somit ausgegeben werden, aber zB eine Eingabe wie " 3>4 " oder " Beispiel -> " gespeichert und ausgegeben werden?
Warum sollen sie nicht gespeichert werden? Wenn sie jemand in einem HTML-Code-Beispiel verwendet oder Dinge schreibt, die zufällig wie Tags aussehen, müssen sie nicht unbedingt verloren gehen. Du musst nur bei der Ausgabe darauf achten, dass sie mit htmlspecialchars() HTML-gerecht umgeschrieben werden. < als <, > als > und " als " - erledigt der Fall. Es ist eine gute Idee, sich das htmlspecialchars() für die Ausgabe aller nicht direkt im Script notierten Daten anzugewöhnen.
In allen 3 Fällen soll die Speicherung der Daten halt gesichert sein gegen SQL-Injection und andere mögliche Bösartigkeiten.
Bei der Eingabe von Daten sollte im Vordergrund stehen, sie möglichst roh zu speichern, ohne irgendwelche Ausgabeformatierungen. Deswegen ist es ausreichend, die Benutzerangaben einfach mit mysql_real_escape_string() ins SQL-Statement einzubauen. Damit sind sie erstmal gegen SQL-Injection gesichert.
Was zur Sicherung der Ausgabe nötig ist, wird erst bei der Ausgabe und für das dann verwendete Ausgabemedium bewertet und angewendet.
Daten in einem Newsfeed müssen sicherlich anders aufbereitet werden als wenn sie auf der Webseite gezeigt werden sollen. Es wäre ungünstig, sich bereits beim Speichern auf ein bestimmtes Ausgabemedium festzulegen.
2.) KEINE html-Tags gespeichert werden, aber alles, wass mit www oder http:// anfängt, bei der Ausgabe als anklickbarer Link ausgegeben wird?
Dazu hab ich nebenan schon was gesagt. Diese Analyse und Umgestaltung der Daten soll direkt zum Ausgabezeitpunkt mit den aus der Datenbank geholten Rohdaten erfolgen. Ich denke, dass sich zu dem Thema schon mal jemand einen Kopf gemacht hat und sich im Web konkretere Vorschläge als meiner finden lassen.
3.) zusätzlich <b>, <i> und <u> erlaubt sind?
Das ist im Prinzip ähnlich handzuhaben wie die Suche nach dem www bzw. http://. Bedenke aber, das Benutzer doof sind und sich nicht unbedingt um eine korrekte Schachtelung der Tags kümmern. In dem Fall wäre sicherlich eine Analyse und Behandlung à la Christian Seilers BBCode-Parser notwendig und angebracht.
Für 2. und 3. kann htmlspecialchars() natürlich nicht auf den gesamten String angewendet werden, weder vorher, da du ihn ja z.B. zum Einbau des <a>-Tags zerstückeln musst, und auch nicht nachher, da sonst das <a href...> verlorenginge. Du musst das also auf die Teilstücke einzeln anwenden.
echo "$verabschiedung $name";