Onderwerp: Externe PHP-code blokkeren?

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

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?