phpbar.de logo

Mailinglisten-Archive

[php] PHP Sicherheit und CERT

[php] PHP Sicherheit und CERT

Friedhelm Betz holliwell at gmx.net
Don Okt 14 17:19:06 CEST 2004


Hi Frank,

[...]

>>http://cert.uni-stuttgart.de/archive/win-sec-ssc/2004/10/msg00015.html
>>Was haltet Ihr davon?
> 
> 
> Wer immer noch ungeprüft irgendwelche GET/POST/COOKIE-Parameter
> übernimmt und einsetzt... (naja, spar ich mir, das wird wohl jeder
> hier wissen ;) )
> Dergleichen gilt natürlich auch für XSS oder dem Zugriff auf lokale
> Systemdateien, alles längst bekannt.

genau ;-)

>>Irgendwie ist das doch ziemlich duenne Suppe, ich
>>weiss nicht was ich von diesen Warnungen per se halten soll.
> 
> 
> Das kam wohl aus aktuellem Anlass (Stichwort: Warez/Uniserver/FTP) und man
> sollte auch berücksichtigen, dass diese CERT-Meldungen eigentlich an
> die Admins der Uni gerichtet sind. Ich könnte mir durchaus vorstellen,
> dass es auf einigen Uniservern tatsächlich ein Problem darstellt, wo
> alle Studenten und Institute ein paar MB Webspace umsonst bekommen und je
> nach Kenntnisstand ein paar PHP-Skripte laufen lassen (von denen sie
> wissen, was sie tun ;) ).
> 
> Aus Programmierersicht ist der Artikel natürlich ziemlicher Bullshit.

Schon und aus Adminsicht? Und was macht Admin mit seinen Studierenden?

> 
>>Hoeflicherweise wird empfohlen PHP Installationen auf Einbruchsversuche
>>zu pruefen, toll, aber mit keinem Wort explizit erwaehnt, welche 
>>Massnahmen ergriffen werden koennten. Ausser implizit url_fopen 
>>auszustellen.
> 
> 
> Ja, das ist allerdings dürftig, aber wie gesagt, das sind eigentlich
> nur die Möglichkeiten, die ein Admin hat, insofern kann ich das
> einigermassen nachvollziehen. Der erste Weg des Admin muss sein,
> url_fopen abzustellen, wenn er eine solche Konstelleation entdeckt,
> dann kann er versuchen den betreffenden User, der die Skripte/Webseite
> betreut ausfindig zu machen.

Viel Spass;-) Wenn es keine andere Moeglichkeit gibt, bleibt url_fopen 
aus, basta. Also ich haette keine Lust, weblogs zu durchforsten mit dem 
Ziel bescheuerte PHP-Skripts aufzuspueren, User zu identifizieren und 
diese dann hoeflich auf schlechte Skripte hinzuweisen. Dafuer ist mir 
meine Zeit zu schade;-)

> Er darf sonst nachher als Netzverantworlicher den Mist ausbaden, wenn
> ein Bot den Server missbraucht.

Genau und was ist gangbar aus Adminsicht? Dazu gibts nix explizites.....
Ueber irgendwelchen PHP Hurzelkram, was bei einzelnen Leuten laeuft, 
gibt es keine Kontrolle.
Staendiges Ueberwachen der Logfiles (o.k. IDS gibts auch) mit dem Ziel 
zu checken, ob sich ein Trojaner installiert hat? Falls ja spuere ich 
das verantwortliche Skript auf, identifiziere den User und deaktiviere 
seine fraglichen Skripte? Kaum.

Ausser url_fopen global zu deaktivieren faellt mir aus Adminsicht grad 
nix ein? Euch?
Wie regeln das die Massenhoster?

Gruesse
Friehelm


php::bar PHP Wiki   -   Listenarchive