HowTo secure PHP (Apache-Modul)

  • Thread starter Thread starter server4downs
  • Start date Start date
S

server4downs

Guest
Hallo zusammen,

da ich kurz Zeit habe, habe ich mir mal gedacht hier einen kleinen Artikel zu schreiben wie man sich vor PHP-Hacks wenigstens grundlegend schützen kann.
Nicht immer ist es sinnvoll safe_mode auf ON zu stellen, da dann einige Scripts nur noch halbwegs funktionieren....
Hier ist dann nun aber Vorsicht geboten:
Auch wenn man keine Kunden oder ähnliches auf dem Server hosted kann dies eine Gefahr darstellen, sofern man keine weiteren Schritte vollzieht.
1. Beim Apache-Modul PHP (nicht CGI) ist es durchaus angebracht pro Virtualhost die open_basedir zu setzen (auch wenn safe_mode = ON).
Wie geht das?
Confixx und andere AdminCPs erledigen dies schon automatisch ;)
Ansonsten einfach in Virtualhost-Directive schreiben:
Code: 
php_admin_value open_basedir /home/www/whatever/:/tmp
Somit hat der entsprechende Vhost Zugriff auf
/home/www/whatever/ und /tmp.
Selbstverständlich können hier weitere paths reingehauen werden (mit Doppelpunkt).
Diese PHP-Value lässt sich nur per php.ini oder eben Vhost-File benutzen. Somit ist nicht per ini_set oder .htaccess veränderbar, was uns eine bestimmte Sicherheit gewährleistet.
2. Wir sind nun aber noch nicht fertig. Der potentielle Angreifer könnte uns immer noch am Genick packen und unseren Server für z.B. Spamming oder ähnlichen Schwachsinn ausnutzen, indem er einfach mit bestimmten PHP-Standart-Functions entspr. Files auf den Server in die zugelassenen Dirs läd und diese dann ausführt (ich spreche aus Erfahrung!).
Am sichersten ist es nun einfach noch gewissen functions zu sperren, die man eh nicht gerade tägl. braucht... Besonders die "Server-" Functions, wie z.B. exec oder system sind meiner Meinung nach zwar ein nettes Spielzeug, bieten jedoch eine extraem hohe Angriffsfläche (vor allem für unsicheres Scripting).
Nun muss man sich entweder für die Bequemlichkeit oder Sicherheit entscheiden. Ich ziehe lieber Sicherheit vor, denn die "Bequemlichkeit", d.h. das Benutzen der oben genannten Functions muss nicht nötig sein (ich komme sehr gut ohne die functions aus)...
Also, wer Sicherheit vorzieht sollte die functions entsprechend sperren:
(php.ini):
Code: 
disable_functions = exec, shell_exec, proc_open, proc_nice, escapeshellarg, escapeshellcmd, diskfreespace, passthru, system, popen, pfsockopen, link, getmyuid, set_time_limit, disk_free_space
Dies wäre mal ein Beispiel. Natürlich gibt es noch weiter Functionen, die man hier sperren könnte oder manche könnte man auch rauslassen.
Per passthru wurde einer unserer Server jedoch einmal attackiert... deswegen ist hier Vorsicht geboten ;)
disable_functions lässt sich nur per php.ini global einstellen, dies hat sicherheitsrelevante Gründe. Man könnte jedoch auch den PHP-Source anpassen und das Setzen von disable_functions per vhost zulassen. Dies ist jedoch eine andere Geschichte und soll ein anderes mal erzählt werden.

So, jetzt will ich mal zum Schluss kommen ;)
Ich weise immer und immer wieder darauf hin, dringendst auf SAUBERES PHP-Scripting zu achten, denn nur durch Schlamperei entstehen diese security holes.

Also, vielleicht hilft dieses pseudo HowTo ja mal einem Server-Neuling ;)

P.s.:
Wieso nur Apache-Modul und nicht CGI?
Die CGI-Version ist total anders aufgebaut. Hierbei läuft oder sollte es zumindest jeder vhost unter eigenem User.
Aber auch hier ist Vorsicht geboten... Man kann nie sicher genug vorgehen.
open_basedir sollte nicht außer Acht gelassen werden und auch so die ein oder andere Function ist auch via CGI nicht gerade ungefährlich!
 
Last edited by a moderator:
Secure Scripting (PHP)

So, jetzt mag der ein oder andere sich noch gefragt haben, wie "sicheres Scripting" bei PHP aussehen sollte.
Hierzu gibt es sicher x Artikel im Internet. Ich bin auch nicht ein Profi ode PHP-Gott, deswegen werde ich hier keine ausführliche List schreiben können.
Man sollte jedoch zumindest die Basics beachten!
1. Variablen per GET oder POST übergeben sind über $_GET['vari'] bzw. $_POST['vari'] abzurufen und nicht, wie in vielen Büchern etc fälschlicher Weise erklärt per $vari!
Dazu sollte nat. kommen, dass man die register_globals auf OFF stellt.
What for?
Ganz einfach: sind die register_globals auf ON, so könnte man die Anfrage sehr schnell fälschen.
Aber damit ist es noch nicht getan. Auch sollte man die übergebenen Werte jeweils überprüfen. Weiteres auf PHP.net in der Security-Section... (SQL-Injection etc).
 
Last edited by a moderator:
Mit dem letzten Post hast du sicherlich recht, aber das Beispiel ist unglücklich gewählt -- egal ob register_globals = on oder off, durch die Definition von $id wirds im Script überschrieben, dh. es ist garantiert, dass $id keine fremden Werte enthält. ;)
 
hoffie said:
Mit dem letzten Post hast du sicherlich recht, aber das Beispiel ist unglücklich gewählt -- egal ob register_globals = on oder off, durch die Definition von $id wirds im Script überschrieben, dh. es ist garantiert, dass $id keine fremden Werte enthält. ;)
Click to expand...
Wo er Recht hat, hat er Recht!
Da hatte ich was nicht ganz bedacht... Peinlich, peinlich!
War eher ein schlechtes Beispiel...
Also, demnach müsste ich mal ein anderes liefern:
Nehmen wir doch gleich das von php.net, um mir weitere Peinlichkeiten zu ersparen ;)
PHP: 
<?php
if ($username) {  // kann vom User mit get/post/cookies übermittelt werden
    $good_login = 1;
}

if ($good_login == 1) { // kann vom User mit get/post/cookies übermittelt werden
    fpassthru ("/highly/sensitive/data/index.html");
}
?>
 
Alternative (für die, die $_GET oder $_POST umständlich finden): Wenn Variablen gesetzt werden, sollte auch für den Fall das eine Bedingung nicht zutrifft die Variable gesetzt bzw. gelöscht werden. Also

PHP: 
<?php
if ($username) {  // kann vom User mit get/post/cookies übermittelt werden
    $good_login = 1;
} else $good_login = 0; // oder unset($good_login)

if ($good_login == 1) { // kann vom User mit get/post/cookies übermittelt werden
    fpassthru ("/highly/sensitive/data/index.html");
}
?>

hätte auch funktioniert :)
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top