SQL Injection

QUOTE (jAuer @ So 23.4.2006, 21:47) Das Argument ist strukturell falsch: Eine gehackte Anwendung läßt sich vielfach mißbrauchen, bsp. als Mailspamschleuder. Ein Server im Web, auf dem man anonym tun und lassen kann, was man will und für den offiziell jemand anderes verantwortlich ist ... ist doch wunderbar - da muß man sich nicht für irgendwelche Daten auf diesem Server interessieren. Und wenn jemand aus dem Ausland den Server knackt, benötigt er keinerlei Deutschkenntnis, um die Daten vielleicht lesen zu können.

Ihr versteht mich falsch...

Ich möchte euch ein Beispiel machen...

Ich habe ein Warenhaus. Da ich gehört habe, dass viel geklaut wird, möchte ich einen Ladendetektiv anstellen.

Ich bin aber keine Nationalbank.

Klar wäre einen Applikation, welche so sicher ist wie jene der Banken schön, das wäre aber mit Schrotfinten auf Vögel geschossen.

Ich möchte einfach die Script Kiddies Aussperren, genügt hierfür folgendes Script?

CODE
$varname = mysql_real_escape_string($varname);
mysql_query( "INSERT INTO tblname SET varname='$varname';" );


Sollte dann mal irgendwer es trozdem schaffen, meine App zu hacken und die DB zerstören, fahre ich einfach ein Restore der DB...
 
Ich denke es kommen da 2 Punkte zusammen.

1. Jürgen stellt richtigerweise fest, dass auch wenn deine Daten nicht so sicherungswürdig sind ein unsicheres Script zu anderen illegalen Aktivitäten gebraucht werden kann. Auch wenn der direkte Schaden für dich nicht so groß ist kann da eine Menge passieren. Wie da die rechtliche Verantwortung aussieht weiß ich nicht, aber das alleine sollte nicht der Grund sein hier ordentlich zuarbeiten

2. Du musst auch bei mysql_real_escape_string den Inhalt checken
Lesestoff => http://ilia.ws/archives/103-mysql_real_esc...Statements.html
 
QUOTE (hatschi1810 @ Di 25.4.2006, 12:05) 1. Jürgen stellt richtigerweise fest, dass auch wenn deine Daten nicht so sicherungswürdig sind ein unsicheres Script zu anderen illegalen Aktivitäten gebraucht werden kann. Auch wenn der direkte Schaden für dich nicht so groß ist kann da eine Menge passieren. Wie da die rechtliche Verantwortung aussieht weiß ich nicht, aber das alleine sollte nicht der Grund sein hier ordentlich zuarbeiten

Was kann denn z. B. passieren?
 
Z.B. könnte jemand versuchen von dir aus massenweise Spams zu verschicken, versteckt illegale downloads anbieten, von dort aus eine Attacke auf sein eigentliches Ziel starten,….

Man darf die Frage ja nicht darauf eingrenzen was mit dem einem Statement machbar ist, weil das ja oft erst der Startpunkt ist um etwas anderes zu machen (z.B. sich als Admin einloggen, dann eine eigene Datei auf den Server laden die wer weiß was macht).
 
QUOTE (hatschi1810 @ Di 25.4.2006, 12:55) Z.B. könnte jemand versuchen von dir aus massenweise Spams zu verschicken, versteckt illegale downloads anbieten, von dort aus eine Attacke auf sein eigentliches Ziel starten,….

- ich habe nirgendwo die funktion "mail()" im Einsatz.
- ich habe nirgendwo eine Uploadfunktion, ausser ftp, hat andere Benutzerdaten, als andere Logins

Ich möchte nur etwas verhindern:
- es sollen keine Daten aus der DB unbefugt ausgelesen werden können.
- keine Daten unbefugt verändert werden
- keine Daten oder Tabellen unbefugt gelöscht werden

Und da ist die Frage ob "mysql_real_escape_string" dass einigermassen erfüllt.
 
Ich kann dir keine Garantie geben, aber ich denke, dass genügt... Würde es aber eher so machen, dann können es wirklich alle User brauchen:
CODE
function escape_string($string,$db)
{
if(get_magic_quotes_gpc() == 1) {
$string = stripslashes($string);
}
return mysql_real_escape_string($string,$db);
}

 
QUOTE (Benedikt @ Di 25.4.2006, 12:31) [...]
- ich habe nirgendwo die funktion "mail()" im Einsatz.
- ich habe nirgendwo eine Uploadfunktion, ausser ftp, hat andere Benutzerdaten, als andere Logins
[...]

Du verstehst das falsch, es kann durch eine SQL Injection mehr passieren als nur auf die Datenbank begrenzt.
Er kann durchaus auch über die Datenbank das System konterminieren, da spielt es dann keine Rolle mehr ob Du sowas in Deinem Script verwendest. Gut, hier spielen auch noch einige andere Faktoren mit rein, aber die Möglichkeit besteht einfach.



MfG Sascha Ahlers
 
QUOTE (Benedikt @ Di 25.4.2006, 11:07) Was kann denn z. B. passieren?


Man kann bei Serverkonfigurationen ziemlich viel falsch machen. Das Ergebnis: Über eine Sql-Injektion erstellt man sich erst einen Datenbank-Administrator, mit dem erstellt man sich einen Webserver-Administrator, mit dem installiert man neue Dienste, öffnet neue Ports. Dann ist der Server nicht mehr dein Server, allerdings wird jeder in der Welt dich für alle von diesem Server ausgehenden Aktivitäten verantwortlich machen.

Harmlos: Die IP-Nummer als Mailspam-Nummer einstufen. Nicht mehr harmlos: Deinen Rechner als Pseudo-Postbank verwenden, um eine Postbank-Seite zu erstellen, Nutzer per Phishing zur PIN/TAN-Eingabe zu veranlassen und das Geld abheben. Von deinem Rechner aus andere Systeme angreifen, die machen dich dann bsp. für den entstandenen Schaden haftbar (oder könnten es zumindest versuchen). Dann weise nach, daß Du das nicht warst.


QUOTE (Benedikt @ Di 25.4.2006, 7:48)Sollte dann mal irgendwer es trozdem schaffen, meine App zu hacken und die DB zerstören, fahre ich einfach ein Restore der DB...


Das machen bloß harmlose Scriptkiddies. Die mit den obigen Zielen werden peinlichst bemüht sein, ja nicht aufzufallen, sondern den Server ungestört nutzen zu können.
 
QUOTE (jAuer @ Di 25.4.2006, 23:28) Man kann bei Serverkonfigurationen ziemlich viel falsch machen. Das Ergebnis: Über eine Sql-Injektion erstellt man sich erst einen Datenbank-Administrator, mit dem erstellt man sich einen Webserver-Administrator, mit dem installiert man neue Dienste, öffnet neue Ports. Dann ist der Server nicht mehr dein Server, allerdings wird jeder in der Welt dich für alle von diesem Server ausgehenden Aktivitäten verantwortlich machen.

Ich hab ja mit meinen mySQL Benutzeraccounts kaum rechte....

Viel mehr als lesen und schreiben kann ich nicht.

Ich darf nicht mal eine neue Datenbank anlegen (nur über das Hoster Script).

Wenn ich (wo möglich) mit einen Account arbeite, welcher nur leserechte hat, bestehen da noch grosse Risiken?
 
Grosse gefahren per SQL-Injection hast du sowieso nicht, wenn du die Strings escaped hast.

Gibt ja noch andere Gefahren als SQL-Injection
wink.gif
...

- Die grösste Gefahr ist bei der Benutzung von Standard-Scripten (z.B. phpBB, etc.).
- Register-Globals muss auf jeden Fall ausgeschaltet sein.
- File-Uploads absichern (*.php, etc.)
- Passwörter MD5

etc.
 
QUOTE (Benedikt @ Mi 26.4.2006, 8:31)Ich hab ja mit meinen mySQL Benutzeraccounts kaum rechte....

Viel mehr als lesen und schreiben kann ich nicht.

Ich darf nicht mal eine neue Datenbank anlegen (nur über das Hoster Script).

Wenn ich (wo möglich) mit einen Account arbeite, welcher nur leserechte hat, bestehen da noch grosse Risiken?

Bei einer solchen Konfiguration ist allerdings der Hoster für so gut wie alles verantwortlich, da über deine Eingabeformulare höchstens ein Zugriff unter einem eingeschränkten Konto auf deine Datenbank möglich sein dürfte (außer, dem Hoster unterlaufen gravierende Fehler, aber da könntest Du sowieso nichts machen).
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben