Sicherheitsfragen PHP und MYSQL
semteX 10.06.2004 - 13:08 503 9
semteX
begehrt die rostschaufel
|
ich hätt 2 sicherheitsfragen: 1. Sql injections welche Voraussetzungen müssn für eine sql injection erfüllt sein? würd es z.b. reichen wenn ich "SELECT * FROM bla WHERE id='".$GET["..."]."'"; stehen hätte? wie verhindert ich das? im phpbb2 forum werden imho slashes hinzugefügt: if( !get_magic_quotes_gpc() )
{
if( is_array($HTTP_GET_VARS) )
{
while( list($k, $v) = each($HTTP_GET_VARS) )
{
if( is_array($HTTP_GET_VARS[$k]) )
{
while( list($k2, $v2) = each($HTTP_GET_VARS[$k]) )
{
$HTTP_GET_VARS[$k][$k2] = addslashes($v2);
}
@reset($HTTP_GET_VARS[$k]);
}
else
{
$HTTP_GET_VARS[$k] = addslashes($v);
}
}
@reset($HTTP_GET_VARS);
}
nr. 2 sind cookies: Wenn der Benutzer sich jederzeit mit cookies wieder einloggen können soll. weil einfach user und md5 pass ins cookie speichern ist ja ganz nett aber ned wirklich sicher... dann wird dir 1x die sql db gehackt, der hacker holt sich das admin pw aus der db, fügt es in "sein" cookie ein und du hast ein deftiges problem... Wie löst man so ein problem "sicher"? thx mfg semteX
|
tomstig
OC Addicted
|
jep, so gehts, so mach ich meistens auch die sql-abfragen. einziges prob: wenn du ein usersystem hast, und einer hat einen nickname wie " bl'a " oder " wap'p'la " o.ä dann spießt sich das und es kommt zu einer fehlermeldung.
|
Ringding
Pilot
|
Ad 2.
Wenn die Datenbank gehacked wurde, musst du eben das Passwort (und alles, womit man sonst noch Zugang bekommen kann) ändern. Daran führt kein Weg vorbei.
Eine Möglichkeit, um das Generieren eines Login-Cookies schwieriger zu machen, wäre, es mit einem geheimen Schlüssel, der im Sourcecode drinnensteht, zu verschlüsseln. Dann muss ein Angreifer auch auf den Sourcecode Zugriff erlangen, bevor er sich unbemerkt einschleichen kann.
@tomstig: Sollte nicht passieren, dazu escaped man es ja schließlich.
|
semteX
begehrt die rostschaufel
|
Ad 2.
Wenn die Datenbank gehacked wurde, musst du eben das Passwort (und alles, womit man sonst noch Zugang bekommen kann) ändern. Daran führt kein Weg vorbei.
Eine Möglichkeit, um das Generieren eines Login-Cookies schwieriger zu machen, wäre, es mit einem geheimen Schlüssel, der im Sourcecode drinnensteht, zu verschlüsseln. Dann muss ein Angreifer auch auf den Sourcecode Zugriff erlangen, bevor er sich unbemerkt einschleichen kann.
@tomstig: Sollte nicht passieren, dazu escaped man es ja schließlich. k thx... jo klar musst du alle passwörter ändern. nur wenn man z.b. eine community hat mit 1000 leute wirds halt problematisch.
|
semteX
begehrt die rostschaufel
|
wieso wird eigentlich durch das slashes hinzufügen eine sql injection ausgeschlossen?
|
Ringding
Pilot
|
Backslashes müssen es sein, vor jedem einfachen Anführungszeichen.
|
gue
Addicted
|
wieso wird eigentlich durch das slashes hinzufügen eine sql injection ausgeschlossen? Die Backslashes sind deshalb nötig, um zu verhindern, dass jemand beliebige SQL-Statements ausführen kann. Beispiel: Du hast eine Maske, über die man den Benutzernamen usw. ändern kann. Die geänderten Daten fügst du einfach in die DB ein, ohne vorher Backslashes reinzumachen. Bsp.: UPDATE users SET name='$_GET["name"]', ... WHERE id=$login["id"] Wenn ein Benutzer aber für seinen Namen z.B. folgenden wählt: ', password=JA5sdf352 WHERE id=1;so kann er damit das Passwort von beliebigen Usern auf ein von ihm gewähltes umändern. Btw. würde ich mir keine Gedanken darüber machen, dass jemand deine Datenbank hackt. Das sollte im Normalfall - wenn das DBMS richtig konfiguriert ist - nicht möglich sein. Viel gefährlicher ist es z.B., dass jemand das Passwort vom Admin snifft.
|
Ringding
Pilot
|
Wieso?
Gerade mit SQL Injection ist es doch sehr leicht, sich Zugang zur Datenbank zu verschaffen.
|
semteX
begehrt die rostschaufel
|
Die Backslashes sind deshalb nötig, um zu verhindern, dass jemand beliebige SQL-Statements ausführen kann. Beispiel: Du hast eine Maske, über die man den Benutzernamen usw. ändern kann. Die geänderten Daten fügst du einfach in die DB ein, ohne vorher Backslashes reinzumachen.
Bsp.: UPDATE users SET name='$_GET["name"]', ... WHERE id=$login["id"]
Wenn ein Benutzer aber für seinen Namen z.B. folgenden wählt: ', password=JA5sdf352 WHERE id=1; so kann er damit das Passwort von beliebigen Usern auf ein von ihm gewähltes umändern.
Btw. würde ich mir keine Gedanken darüber machen, dass jemand deine Datenbank hackt. Das sollte im Normalfall - wenn das DBMS richtig konfiguriert ist - nicht möglich sein. Viel gefährlicher ist es z.B., dass jemand das Passwort vom Admin snifft. oha... alles klar danke!
|
DKCH
...
|
lustig auch beim login (und fast noch brenzliger imho)
du hast 'select * from benutzer where name="'.$user.'"'
dann gibt jemand statt "bla" "bla' OR 1=1;--" ein --> immer true, brauchst nix passwort ändern -> keiner merkts...
edit: und mit backslash davor gehts dann ned, weil er ja dann den string nicht mehr schliessen kann -> dazu slash...
Bearbeitet von DKCH am 10.06.2004, 20:56
|