Hallo.
Wenn jemand Zugang zu den Dateien auf dem Server hat (z.B. per FTP), kann er sich natürlich auch den PHP-Quelltext angucken. Wenn die Seite nur durch den Browser angezeigt wird, besteht keine Chance, den PHP-Quelltext zu betrachten.
Allerdings kann das Passwort mit einem Sniffer(z.B. Ethereal) abgefangen werden, da Das Passwort und der Benutzername auf dem Weg zur Datenbank übers Netzwerk meines Wissen snicht verschlüsselt übertragen werden.
Gibt aber glaub ich auch keine Chance, sich dessen zu erwehren.
Allerdings kann das Passwort mit einem Sniffer(z.B. Ethereal)
abgefangen werden, da Das Passwort und der Benutzername auf
dem Weg zur Datenbank übers Netzwerk meines Wissen snicht
verschlüsselt übertragen werden.
Gibt aber glaub ich auch keine Chance, sich dessen zu
erwehren.
mit anderen worten: php ist unsicher und für den professionellen einsatz völlig unbrauchbar oder wie? es kann ja wohl nicht sein, das irgendjemand, der sich dieses tool runterlad plötzlich zugriff auf die datenbank bekommt. das wäre dann ja wohl das ende von php oder nicht?
mal im ernst: wenn es so einfach geht, dann wird es doch auch niemand benutzen?!?
mit anderen worten: php ist unsicher und für den
professionellen einsatz völlig unbrauchbar oder wie? es kann
ja wohl nicht sein, das irgendjemand, der sich dieses tool
runterlad plötzlich zugriff auf die datenbank bekommt. das
wäre dann ja wohl das ende von php oder nicht?
mal im ernst: wenn es so einfach geht, dann wird es doch auch
niemand benutzen?!?
Ein Sniffer ist ein Tool, um den gesamten Netzwerkverkehr, der an dem Rechner von dir vorbeikommt, aufzuzeichnen und zu analysieren.
Mit anderen Worten: Es ist nicht einfach, das PWD der Datenbank herauszukriegen, da man erst den Netzwerkverkehr auf seinen Rechner umleiten müsste (dies geht nur, wenn man im selben Subnetz wie der DB-Server ist.
Wenn nun DB und der Webserver, auf dem das PHP-Script ausgeführt wird, auf dem selben Rechner liegen, werden Benutzername und Passwort erst gar nicht übers Netzwerkinterface verschickt.
Damit kann man auch nicht sniffen.
Also so lange wie die PHP-Dateien geparst werden, kann das Paßwort nicht von einem User ausgespäht werden. Sollte der PHP-Parser allerdings (aus welchen Gründen auch immer) nicht funktionieren, könnte ein User sich deine PHP-Datei mit dem Paßwort als Plain/Text ansehen. Um sich davorzu schützen kannst du ein extra Verzeichnis anlegen, in das Du eine PHP-Datei mit dem Datenbankconnect reinlegst und in deine PHP-Skripte includierst. Dieses Verzeichnis kannst du nun mit einen Paßwort schützen.
Natürlich kann man die Zugangsdaten auch mit einem Sniffer ausspähen, vorausgesetzt man hat Zugriff auf die Verbindung zwischen Web- und Datenbankserver. Bei vielen Internetpräsenzen ist es allerdings so, das Web- und Datenbank über ein lokales Netz verbunden sind. In dieses müßte man sich dann erstmal „reinhacken“.
Eine Verschlüsselte Übertragung der Zugangsdaten zur Datenbank ist meines Wissens (noch) nicht ohen weiters machbar.
mit anderen worten: php ist unsicher und für den
professionellen einsatz völlig unbrauchbar oder wie? es kann
ja wohl nicht sein, das irgendjemand, der sich dieses tool
runterlad plötzlich zugriff auf die datenbank bekommt. das
wäre dann ja wohl das ende von php oder nicht?
mal im ernst: wenn es so einfach geht, dann wird es doch auch
niemand benutzen?!?
Das Problem hat übrigens überhaupt nichts mit PHP zu tun, das ist in allen anderen Sprachen genau gleich. Wenn du einen Datenbankzugriff machst, musst du dich am Datenbankserver authentifizieren und diese Infos müssen ja irgendwo hinterlegt sein. Die grösste Gefahr ist die dass jemand anders deien Datei lesen kann, indem er Zugriff auf den Server hat. Der beste Schutz dagegen ist wenn es dein eigener Server ist und ausser dir niemand einen Zugang drauf hat (es gibt noch andere Lösungen mit datei-Rechten etc. ist aber alles recht kompliziert, da der Webserver die Datei lesen können muss, aber andere wieder nicht etc.). Wenn dann der Datenbankserver noch lokal auf der gleichen Maschine ist, kann eigentlich nichts passieren. Ansich liesse sich die Datenbankverbindung sicher auch irgendwie verschlüsseln, den Angriffspunkt sehe ich aber eher weniger, weil der Datenbankserver kaum mal irgendwo ganz anders im internet steht (wäre auch ziemlich langsam) und ins lokale Netz musst einer erstmal eingreifen.
mit anderen worten: php ist unsicher und für den
professionellen einsatz völlig unbrauchbar oder wie? es kann
PHP ist genauso sicher oder unsicher wie ASP oder Perl oder jedes andere CGI-Script.
Nur mal so als Anmerkung. Auf einer „normalen“ Website werden die connect-Daten zur Datenbank immer im Skript übergeben, daher besteht auch immer die Gefahr, dass diese mit einem Sniffer ausgespäht werden können.
#1
wie bereits beantwortet: wenn alles so funktioniert, wie es sollte, sieht das php-file keiner, da es ausgeführt wird.
fällt php aus bestimmten gründen aus, kann es passieren, dass das php als plaintext (also der sourcecode) sichtbar wird. um das zu verhindern solltest du die db-connects anders formulieren:
host, username und passwort nicht im klartext ins connect stellen, sondern variablen dafür verwenden. diese werden in einem include-file definiert, welches außerhalb des webroots steht, also wenn dein webroot auf www/html liegt, dann lege die include-datei einfach in www - so kann sie von außen keiner sehen, selbst wenn php ausfällt.
#2
sicherheit zwischen webserver (php) und datenbankserver (mysql)
meistens liegen die im selben lan, also wird ausspionieren (hoffentlich) SEHR schwer.
falls die verbindung aber über eine web-connection läuft, so ist login/passwort für jeden sichtbar, der den traffic dazwischen abhorcht. würde ich mir nicht antun, mehrere megabyte an datenmüll pro sekunde auf login/pwd durchzusuchen, aber …
mysql 4 bringt dann aber erstmals ssl-unterstützung.
#3
mach dir keine sorgen. wähle deine logins/passwörter gut (also nicht: „knuddelhasi“/„knuddelhasi“), probier den trick mit den includes, und vertraue darauf, dass deine webhoster keine absoluten idioten sind, und den traffic zwischen webserver und db-server abhören lassen.
stefan
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
