Curl Nutzung gefährlich / vermeidbar

Wenn Dein Server-Admin nicht aufgepasst hat, funktioniert vielleicht 
wget.

Rufus Τ. F. schrieb:
> Wenn Dein Server-Admin nicht aufgepasst hat, funktioniert vielleicht
> wget.

Nein. Die TO schreibt ja eindeutig PHP. Es geht also um die 
PHP-Anbindung der libcurl, nicht um das Kommandozeilenprogramm.

Siehe hier:
http://php.net/manual/de/ref.curl.php

curl bietet relativ umfangreiche Möglichkeiten um HTTP- und FTP-Requests 
abzusetzen. Aber es ist bei weitem nicht die einzige Möglichkeit sowas 
von php aus zu machen, bei PHP kann man sogar einem fopen() eine URL 
mitgeben und der macht dann den entsprechenden Request.

Also ich würde mal sagen daß das keine speziellen bekannten 
Sicherheitsrisiken mit sich bringt, nur wird der Admin sagen daß er nur 
die tatsächlich benötigten Module freischaltet. Desto weniger Module, 
desto weniger Angriffsfläche.

Gerd E. schrieb:
> Nein. Die TO schreibt ja eindeutig PHP.

Blond, wie ich bin, bin ich davon ausgegangen, daß es natürlich auch 
eine wget-Anbindung für PHP gibt.

Was curl ist, weiß ich (ich benutze es allerdings weit jenseits des 
php-Umfelds, und erst recht nicht auf angemieteten Servern)


Deinem vernünftig klingenden Fazit schließe ich mich an:
> Desto weniger Module, desto weniger Angriffsfläche.

Planlos schrieb:
> Wobei die großem Angriffsflächen von PHP (selbst) meist nicht in den
> Modulen liegen, sondern eher in dem (immer noch nicht einfach
> abschaltbaren) "eval"-Sprachkonstrukt.

http://php.net/manual/en/ini.core.php#ini.disable-functions

das gibt's jetzt seid gut 15 Jahren.

Nur leider brauchen z.B. Forumssoftware, Content-Management-Systeme,... 
meistens eval(), da sie PHP-Code aus irgendwelchen Datenbanken oder 
Config-Dateien nachladen und dann per eval() ausführen.

Und dieses Konstrukt ist tatsächlich für viele Sicherheitsprobleme 
verantwortlich: schafft man es einmal per SQL injection etwas in die 
entsprechenden Datenbankfelder reinzuschreiben, kann man beliebigen 
PHP-Code ausführen.

Gerd E. schrieb:
> Nur leider brauchen z.B. Forumssoftware, Content-Management-Systeme,...
> meistens eval() [...]

Da das stimmt leider, da muss man dann abwägen ob man lieber potentiell 
unsichere Software installiert, und welche Sicherheitsmaßnahmen man noch 
zusätzlich ergreifen will, oder ob einem die Sicherheit seines Server 
lieber ist.

Mir ging es aber um die aussage eval sei nicht einfach abzuschalten, was 
einfach Unsinn ist, ich hab nur ein vhost bei den eval aktiviert ist, 
der ist für ein phpbb und der ist an vielen stellen abgesichert.

Er läuft in nem chroot, der php-Prozess hat nur Schreibrechte in Ordnern 
die ausschliesslich direkt vom Webserver ausgeliefert werden, er kann 
also keine php-Scripte anlegen / verändern die ausführbar sind.
Er darf keine ausgehenden Verbindungen öffnen, keine Prozesse starten.
Emails gehen über ein sendmail raus das prüft ob der Empfänger ein 
registrierter Benutzer ist, und ob der Inhalt ungefähr zu einem 
Mailtemplate passt, somit werde ich eher nicht zur Spamschleuder.

Dicky D. schrieb:
> Er läuft in nem chroot

Das reicht nicht!
http://www.lst.de/~okir/blackhats/node122.html
Kombinire dass unbedingt mit einer Sandbox, z.B. selinux oder apparmor.

Daniel A. schrieb:
> Dicky D. schrieb:
>> Er läuft in nem chroot
>
> Das reicht nicht!
Stimmt, nur chroot reicht nicht, aber
man kann keine Dateien schreiben die ausgeführt werden können, man kann 
keine weiteren Prozesse ausführen, wie will man da aus einen chroot 
ausbrechen. Nicht zu vergessen das man ja erstmal root werden muss.

Noch einer schrieb:
> bei dem sich der Admin des
> Providers um diese Fragen kümmert.

Tut er nicht.
Er sperrt dich ein, und wenn einer bei dir einbricht ist das dein 
Problem.

Außerdem nimmst du was dein Provider dir anbietet, wenn dir das nicht 
gefällt hast du ein Problem.