sprach-features gegen SQL-hacks
-
hi folks!
der titel ist leider etwas schlecht gewählt, aber was besseres fiel mir nicht ein. sorry.
meine frage ist: welche sprache (PHP/JSP/Perl/etc.) bietet mir einfache features, um ein web-interface möglichst sicher gegen hacks wie SQL-Injection etc zu machen?
gibt es da sprachen, die deutliche vorteile bieten?
danke im voraus,
---loki
-
Ich kenne mich nur in PHP in Perl etwas aus:
Bei PHP ist es so, dass du in den Konfigurationsdateien einstellen kannst, dass z.b. alle Daten die von aussen ins Script kommen (sprich per GET, POST uebertragene Daten) oder auch intern ankommende Daten (aus Datenbanken z.b.) escaped werden. D.h., dass also Zeichen, die eine besondere Funktion haben (wie z.b. das single-quote) mit einem Backslash unwirksam gemacht werden.
Dabei sind 2 dinge zu beachten:
1. Die Einstellungen sind auf jedem Server etwas anders. Du musst also in jedem Fall diese Einstellungen abfragen und ggfls doch per Hand die Daten escapen bzw unescapen je nach Anwendung.
2. Je nachdem, was du mit den Daten vorhast, musst du evtl weitere Zeichen escapen.
dazu gibt es meist eine eigene Funktion:
- preg_quote fuer regulaere Ausdruecke
- escapeshellarg fuer Kommando-Parameter
- htmlspecialchars...
- etcBei Perl gibt es den Taint-Modus. Ist dieser aktiviert, kannst du eine Benutzereingabe im Script erst verwenden, wenn sie vorher durch einen matching ausdruck gelaufen ist. Damit ist zumindest sichergestellt, dass du nicht versehentlich ungepruefte Daten ins Script laesst.
Als (zynisches) Fazit koennte man ziehen, dass der PHP Ansatz zwar gut gemeint ist, einen jedoch entweder in falscher Sicherheit wiegt, oder im Endeffekt mehr Arbeit macht.
-
Dabei sei aber zu beachten, dass die von "sad as it is" angesprochenen MagicQuotes als deprecated gelten und in kommenden PHP-Versionen (momentaner Stand: PHP >= 6) restlos entfernt werden!
-
Stored Procedures mit Parametern! Da kann schon fast nichts schiefgehen was z.b. SQL Injection angeht.
-
Talla schrieb:
Da kann schon fast nichts schiefgehen was z.b. SQL Injection angeht.
Dafür wird es bei den meisten Hostern umso mehr schief laufen, weil du für eigene StoredProcedures spezielle Rechte benötigst und die meisten noch MySQL 3/4 laufen haben ... Leider ...
Außerdem haben Stored Procedures damit imho nichts zu tun, weil die SQL-Injection an dem Punkt entsteht, wo der Befehl vom PHP-Skript an den MySQL-Daemon geschickt wird.
-
SQL ist ja die Sprache an sich, loki1985 hat ja nicht gesagt was für ein Server er verwendet. Und nein, mit Stored Procedures (SP) bist du da auf der sicheren Seite, bzw. schon allgemein wenn man die Queries mit Parametern füllt statt sich den String an sich jedes mal zusammenzubauen. SP sind halt nur noch nen bissle besser.
Bei solch einem Query(wobei "@..." jeweils nen Parameter ist) :
"INSERT INTO Employees (LastName,FirstName,Title,HireDate,ReportsTo,Photo)VALUES(@LastName,@FirstName,@Title,@HireDate,@ReportsTo,@Photo)"hast du praktisch keine Möglichkeit ne SQL Injection durchzuführen! Würdest du aber sowas schreiben(aus Variablen zusammengesetzter Query)
"INSERT INTO Employees (LastName,FirstName,Title,HireDate,ReportsTo,Photo)VALUES(" + LastName +"," +FirstName+","+Title+","+HireDate+","+ReportsTo+","+Photo+")"dann wäre es möglich das eigentliche Insert Statement schon in LastName zu beenden und hab noch genug andere Variablen wo ich eigene evtl. schadhafte Queries absetzen kann. Das ist beim oberen Code nicht möglich!
-
Aber irgendwie musst du deine Parameter mit Werten füllen, und da entsteht die Verbindungsschicht zwischen der Variableninterpolation von PHP, die -wenn man unvorsichtig ist- zur Injection benutzt werden kann, und dem SQL-Server!
-
Reyx schrieb:
Aber irgendwie musst du deine Parameter mit Werten füllen, und da entsteht die Verbindungsschicht zwischen der Variableninterpolation von PHP, die -wenn man unvorsichtig ist- zur Injection benutzt werden kann, und dem SQL-Server!
Da die Variablen aber im Prinzip die feste Spalte einer Reihe in der Tabelle beschreiben., kanns sein dass da unsinnige Werte stehen, aber s kann nicht zur SQL Injection kommen. Hier findet man nen paar Beispiele. Das ist mit Parametern einfach nicht möglich!
-