nicht angemeldet
Tach!
Wenn ich Variablen auf einer Seite entgegennehme um diese in meinem SQL zu verwenden will ich natürlich SQL Injecten verhindern.
Das ist nicht der richtige Ort, um so etwas zu tun. Die Eingabedaten sollten lediglich auf fachliche Anforderungen überprüft werden. Natürlich ist es sinnlos, Statementbestandteile in der Datenbank vorzufinden, aber da gibt es noch genügend anderen Müll, den man filtern müsste. Solch ein Filter wäre dann aber ein generelles (nicht komplett lösbares) Problem und nicht nur auf Statementbestandteile einzuschränken.
Dazu habe ich z.B. folgende Funktion gefunden:
//injection Test
function SQLInjectionTest($checkstring){
$sqltest = array ("/SELECT.*FROM.*WHERE/i",
"/INSERT.*INTO/i",
"/DELETE.*FROM/i",
"/UPDATE.*WHERE/i",
"/ALTER.*TABLE/i",
"/DROP.TABLE/i",
"/CREATE.TABLE/i",
"/substr/i",
"/varchar/i",
"/or.\d=\d/i",
"/and.\d=\d/i");
foreach ($sqltest as $regex){
if (preg_match($regex, $checkstring)){
return TRUE;
}
}
return FALSE;
}
> Damit überprüfe ich zunächst die Get Variable auf Schadcode
Und du bist sicher, dass du auf diese Weise wirklich alles Gefährliche erwischst (für jetzt und in alle Ewigkeit)?
> und ecsape danach noch den String mit htmlspecialchars.
Ein SQL-Statement ist kein HTML. Eine Aufbereitung für HTML ist daher nicht sinnvoll. Das kommt erst dann ins Spiel, wenn du irgendwas nach HTML ausgeben möchtest - und auch erst dann und nicht x Verarbeitungsschritte vorher.
> Wäre das so schon ausreichend gesichert oder muss ich das anders machen?
Anders. Verwende nur die für Postgres vorgesehenen Maskierfunktion pg\_escape\_\*(), vor allem [pg_escape_string()](http://php.net/manual/en/function.pg-escape-string.php) und [pg_escape_literal()](http://php.net/manual/en/function.pg-escape-literal.php).
dedlfix.