Sicherheit bei Ein- und Ausgaben mit SQL

[kshade]

Moin,

für eine Kommentarfunktion mit PHP und MySQL habe ich folgendes "Sicherheitskonzept" zusammengefrickelt:

Die Eingabe soll vor dem Schreiben in die Datenbank mit mysql_real_escape_string() (http://de3.php.net/manual/en/function.mysql-real-escape-string.php) von möglichen Steuerzeichen befreit werden.
Bei der Ausgabe werden Tags und Sonderzeichen mit htmlspecialchars($string, ENT_QUOTES) (http://de3.php.net/manual/en/function.htmlspecialchars.php) gefiltert.

Ist das genug um Datenbank und Betrachter zu schützen oder fehlt noch etwas?

[oracle2025]

Ja, sollte klappen, allerdings könntest du Alternative zu escape_string auch prepared Statements von PEAR:: DB verwenden:
http://pear.php.net/package/DB

[kshade]

Danke für den Tipp, aber im Moment will ich möglichst alles selbst erledigen, wegen des Lerneffektes.

Habe jetzt aber festgestellt, dass mysql_escape_string (mysql_real_escape_string gibts in der php-Version von Woody noch nicht) zu unschönen Ergebnissen führt. Folgendes passiert:

Über ein Formular wird die Eingabe vom Benutzer entgegengenommen und per post an ein php-skript weitergeleitet. Mal ein Beispiel was das Script mit den Daten macht:
// Variable vom Formular importieren
$var = mysql_escape_string($_REQUEST[var]);
// Variable in Datenbank eintragen
mysql_query ("insert into tabelle (wert) values ('$var')");
Dummerweise werden die Backslashe auf diesem Wege mit in die Datenbank eingetragen und auch wieder ausgegeben, ohne mysql_escape_string funktionierts genau so gut, Anfälligkeiten für Injections konnte ich auch nicht feststellen, es sieht fast so aus als würde MySQL oder PHP schon von alleine alles escapen. Könnte das an diesen Einträgen in der php.ini liegen?
; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = On

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off

[Gaert]

Hi kshade,

... ja, das hängt mit den magic_quotes_gpc zusammen.

Um dein Skript portabel zu halten solltest du dieses "Feature" besser nicht nutzen, bzw. wenn magic_quotes gesetzt sind diese am Anfang deines Skripts generell wieder unescapen.

Ein Beispiel um dies zu tun findest du hier: http://www.php.net/manual/de/security.magicquotes.disabling.php

Gruß,

Gaert

[nEox]

Hallo kshade,

ist "Magic quotes" auf on, werden wie du gesagt hast, alle GET-, POST- oder Cookie-Daten escapt.

Wenn du jetzt mit mysql_escape_string() oder addslashes() die Daten nochmals escapst, steht dann sowas im String der in die Datenbank eingetragen wird.

"It\\'s cool!"

Das beste was du machen kannst ist eine eigene Funktion zu schreiben zu verhindern das "doppelte escapes" erzeugt werden.



function myAddSlashes( $string ) {
if (get_magic_quotes_gpc() == 1) {
return $string;
} else {
return addslashes($string);
}
}

$myVar = myAddSlashes($_REQUEST['myvar']);


Die Funktion stellt fest ob magic_quotes_gpc aktiviert ist und gibt immer einen escapten String zurück.

Die "Magic quotes"-Funtion ist ansich ja nichts schlechtes, allerdings führt es zu viel mehr Verwirrung als das es helfen soll. Vor allem wenn man dann anfängt die Daten per stripslashes() wieder von den escapes zu befreien können viele Fehler entstehen und jede Variable muss gechekt werden. Also am Besten magic_quotes_gpc immer auf off stellen wenn du die Möglichkeit hast.

Hier noch ein Link zu einem ganz guten Artikel über Websecurity
http://php-mag.de/itr/online_artikel/psecom,id,396,nodeid,62.html

Gruß

nEox

[kshade]

So, magic quotes sind aus und alle vom User direkt manipulierbare Variablen werden gleich beim importieren mit mysql_escape_string() bearbeitet (waren zum Glück noch nicht viele).

Vielen Dank für die Hilfe, die beiden Links und den ganzen Rest :)