PDA

Bekijk Volledige Versie : php.ini vraagje



Herbert
22/06/03, 22:37
Als iemand een regel uitvoerd in PHP: readfile('/etc/blabla');
dan kan de file blabla gelezen worden
Hoe kun je alle mappen hiervoor beveiligen?
Overal staat dat je php in de safe mode moet draaien maar dat is geen oplossing voor mij.

Heeft iemand een idee?

Web123.nl
23/06/03, 19:55
De beste beveiliging m.i. is PHP draaien als 'cgi' in apache (ik neem even aan dat je dat gebruikt als http server). Echter dan schijnt PHP langzamer te 'parsen'... (verwerking). Wij, en ik denk vele anderen, gebruiken het (daarom) niet op die manier.

SAFE MODE is wel degelijk een optie, safe mode zorgt ervoor dat een bestand enkel gelezen kan worden door een script wat de zelfde uid heeft als het betreffende bestand, dus:

/etc/blabla uid 0 (bijvoorbeeld!!)

kan niet gelezen worden door:
/www/klantx/websiteb/scrript.php met uid 1023 (voorbeeld)

Het enige buggie wat ik hieraan heb kunnen ontdekken is dat:
als je met PHP een file aanmaakt krijgt deze uid 80 (van je httpserver), zoalang deze uid 80 heeft, kan iemand anders deze uitlezen....

Oplossing hiervoor: draai een crontabje die je uid op die van jezelf zet, bijvoorbeeld iedere 10 minuten... dat scheelt iig. weer een heleboel 'hack' kansen.
Andere oplossing: Zorg dat er een lege file is met de goede uid, die je gewoon iedere keer edit. Nadeel hiervan is dat je dan niet nieuwe files kunt aanmaken.

Hopelijk kom je een beetje door mijn uitleg heen....

electric
23/06/03, 19:57
tis toch ook zo dat in safemode een aantal opties uitgeschakeld worden?
of is safemode voor bepaalde site's gemakelijk te disabelen oid ?

Web123.nl
23/06/03, 22:16
Er worden inderdaad een aantal opties uitgeschakeld. Maar dat is nietvoor niets. Zie http://nl3.php.net/manual/en/features.safe-mode.php voor meer info!

Deimos
23/06/03, 22:52
Ik heb zelf nog niets gemerkt dat PHP als CGI langzamer is dan als Module voor PHP. 1 groot voordeel is wel, dat alles onder de user die het heeft geupload draait en je dus nooit gedonder hebt met userrechten.

virtualhost.nl
23/06/03, 23:43
In de httpd.conf kun je voor een gebruiker toegang tot bestanden beperken via php_admin_value open_basedir "/user/www/dir"

Web123.nl
23/06/03, 23:55
Bedankt voor de tip virtualhost.nl!

virtualhost.nl
24/06/03, 00:15
graag gedaan :-)

Mike
24/06/03, 08:06
Origineel geplaatst door virtualhost.nl
In de httpd.conf kun je voor een gebruiker toegang tot bestanden beperken via php_admin_value open_basedir "/user/www/dir" Wel even controleren of alles werkt zoals het hoort. Ik heb het een keer gebruikt, met als gevolg dat een aantal scripts niet meer werkten omdat die geen rechten hadden buiten de basedir

StarInternet
24/06/03, 12:09
Origineel geplaatst door Mike
Wel even controleren of alles werkt zoals het hoort. Ik heb het een keer gebruikt, met als gevolg dat een aantal scripts niet meer werkten omdat die geen rechten hadden buiten de basedir

Daar is juist die beveiling voor =)
Je moet die scripts dus niet gebruiken =)
Wij gebruiken het ook maar ik ga het echt niet uit zetten omdat een klant een script heeft gedownload van hotscripts.com die niet werkt.
Laten ze maar door een echte programmeur de scripts maken.
Die weet hoe hij alles werkent krijgt zonder open_base dit uit te zetten.

Herbert
24/06/03, 20:20
Origineel geplaatst door virtualhost.nl
In de httpd.conf kun je voor een gebruiker toegang tot bestanden beperken via php_admin_value open_basedir "/user/www/dir"
Hoi,
dit zou de oplossing moeten zijn maar ik krijg deze foutmelding:
-
Invalid command 'php_admin_value', perhaps mis-spelled or defined by a module not included in the server configuration
-
Ik ben al 4 uur aan het zoeken waar dat aan ligt maar kan het niet vinden :(

StarInternet
24/06/03, 21:33
Origineel geplaatst door Herbert

Hoi,
dit zou de oplossing moeten zijn maar ik krijg deze foutmelding:
-
Invalid command 'php_admin_value', perhaps mis-spelled or defined by a module not included in the server configuration
-
Ik ben al 4 uur aan het zoeken waar dat aan ligt maar kan het niet vinden :(
Wel in de <virtualhost ???> gezet ?

Herbert
24/06/03, 22:27
Origineel geplaatst door StarInternet

Wel in de <virtualhost ???> gezet ?
Ja daar had ik hem wel ingezet.
Ik heb het geprobeerd met Apache 2.0.46 en PHP 4.3.2 en daar deed hij het wel.
Maar waar het op moet doen is Apache 1.3.23 en PHP 4.1.2

electric
24/06/03, 23:09
Origineel geplaatst door Herbert

Ja daar had ik hem wel ingezet.
Ik heb het geprobeerd met Apache 2.0.46 en PHP 4.3.2 en daar deed hij het wel.
Maar waar het op moet doen is Apache 1.3.23 en PHP 4.1.2
hmm, misschien dat het in apache 1.3.23 niet word ondersteund ? lijkt me zo ie zo verstandig om up te graden naar apache 1.3.37 + php 4.3.2 :)

Herbert
25/06/03, 23:57
Origineel geplaatst door electric

hmm, misschien dat het in apache 1.3.23 niet word ondersteund ? lijkt me zo ie zo verstandig om up te graden naar apache 1.3.37 + php 4.3.2 :)
Vertel eens waarom? ik heb nu:

Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4.2mdk) FrontPage/5.0.2.2623 auth_ldap/1.6.0 mod_gzip/1.3.19.1a mod_auth_external/2.1.14 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
X-Powered-By: PHP/4.1.2

StarInternet
26/06/03, 00:05
Origineel geplaatst door Herbert

Vertel eens waarom? ik heb nu:

Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4.2mdk) FrontPage/5.0.2.2623 auth_ldap/1.6.0 mod_gzip/1.3.19.1a mod_auth_external/2.1.14 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
X-Powered-By: PHP/4.1.2
kan wezen dat 1.3.23 te oud is plus kan fouten bevatten.

Herbert
26/06/03, 23:31
Origineel geplaatst door StarInternet

kan wezen dat 1.3.23 te oud is plus kan fouten bevatten.
Bedankt voor het antwoord.
Fouten heb ik niet kunnen ontdekken maar hij mist wel de nieuwe futures.
Ik ben al bezig met upgraden :)

Domenico
05/07/03, 15:16
Misschien overbodig te vragen maar had je apache wel restarted na de wijziging? ;)

electric
05/07/03, 16:01
ik heb het net getest met apache 1.3.27 en werkt prima :)