nicht angemeldet
你好 Andreas,
Hauptverursacher ist IMHO der User mit dem Buggy Script.
Hauptverursacher ist eine konzeptionelle Schwäche in PHP.
Die da wäre?
Das transparente Verwischen von Datei- und Netzwerk-Zugriffen.
Warum sollte ich include(), fopen() oder ähnliche _Datei_-Operationen
nutzen, um das zu tun?Warum nicht?
Weil sie für _Datei_-Operationen gedacht sind. Nicht für
Netzwerk-Operationen. Wenn man sowas transparent verwischt muss was übles
bei rauskommen. Einmal nicht aufgepasst und schon machts krach-bumm.
Man kann auch mysql_query() so nutzen, dass eine Sicherheitslücke
entsteht - was soll man dagegen machen?
Da kann man nichts gegen machen, das kann immer mal passieren. Aber man
kann unnötige Risikofaktoren ausschliessen.
allow_url_fopen habe ich abgeschaltet.
Leider scheinen das einige unserer Kunden zu brauchen. Wobei ich sagen
muss, dass ich überlege, das trotzdem abzuschalten.
Ich finde allow_url_fopen selber schlecht, weil sobald sich irgendwo
eine entsprechende, kleine Lücke einschleicht - ob es ein eigenes Script
ist oder ein fremdes, oder eine fertige Software - ist ein Angreifer
sofort in der Lage eigenen PHP-Code auszuführen.
Ja, eben!
IMHO sollten User nur Prozesse unter eigener UID laufen lassen können
(suexec/suphp für CGI),
Das sagst du so. Das führt dazu, dass PHP einige Unterschiede zur
(normalerweise installierten) Modul-Version aufweist.
entsprechend sollen User nur die Programme auf der Kommandozeile
ausführen können, die sie evtl. benötigen, alles andere nach Möglichkeit
entfernen, oder wenigstens chmod (0700).
Das hätte in diesem Fall auch nichts geholfen. Perl zu verbieten ist...
naja, leicht lächerlich ;-) Da hilft nur eine vernünftige Administration,
der Angreifer konnte ja nichts ausrichten, er hatte “nur” Apache-Rechte.
Und der darf nicht sonderlich viel... wenn man mit ACLs arbeitet, kann
man da sehr viel recht schön einschränken.
Allerdings betreue ich keine Server mit fremden Usern und habe da
möglicherweise gut Reden ;-)
Ja ;-)
再见,
克里斯蒂安
MudGuard