Alternatieven voor 'include' en '$bestand=join("",

[Eduard Bekker]

Beste mensen!

Ik werk al enige jaren met plezier met php-scripts en inmiddels daar mijn
eigen cms daar helemaal mee.

Nu heeft mijn provider aangekondigd dat vanwege beveiliging bepaalde
routines niet meer kunnen worden aangeroepen.

Hierbij - heeft hij laten weten - zit ook 'include' en '$bestand=join("",
file("tekst.txt"));' Dit zijn routines die ik onmogelijk kan missen.

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


Weet iemand een alternatief hiervoor, zonder dat ik hele boel overhoop hoef
te gooien of gedwongen ben al mijn sites bij een andere provider onder te
brengen?

Daar zou ik erg blij mee zijn.

Bij voorbaat dank!


--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

Hallo Ronald!

On 14-12-2004 13:36, in article MPG.1c28fc93d5924fb39898cb@news.xs4all.nl,
"Ronald Klip" <nieuws@bladibla.net.invalid> wrote:

> Eduard Bekker schreef:
>>
>> Ik werk al enige jaren met plezier met php-scripts en inmiddels daar mijn
>> eigen cms daar helemaal mee.
>>
>> Nu heeft mijn provider aangekondigd dat vanwege beveiliging bepaalde
>> routines niet meer kunnen worden aangeroepen.
>>
>> Hierbij - heeft hij laten weten - zit ook 'include' en '$bestand=join("",
>> file("tekst.txt"));' Dit zijn routines die ik onmogelijk kan missen.
>
> Dan zou je zo te zien geen bestanden mogen openen/schrijven. Klinkt erg
> rigide. Gaat het niet om de 'gewone' safe_mode? (zie
> http://nl3.php.net/manual/en/features.safe-mode.php)

Daar staat:

include_path string

Specifies a list of directories where the require(), include() and
fopen_with_path() functions look for files. The format is like the system's
PATH environment variable: a list of directories separated with a colon in
Unix or semicolon in Windows.

Example H-1. Unix include_path

include_path=".:/php/includes"

Ik moet zeggen: dit is me niet helemaal duidelijk.

Begrijp ik goed, dat je dan geen relatieve, maar alleen absoluten paden moet
opgeven?

Lastig, maar er valt nog iets aan te doen.


--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

On 14-12-2004 19:45, in article MPG.1c29532c4ad219af9898cc@news.xs4all.nl,
"Ronald Klip" <nieuws@bladibla.net.invalid> wrote:

> Eduard Bekker schreef:

>>>> Nu heeft mijn provider aangekondigd dat vanwege beveiliging bepaalde
>>>> routines niet meer kunnen worden aangeroepen.
>>>>
>>>> Hierbij - heeft hij laten weten - zit ook 'include' en '$bestand=join("",
>>>> file("tekst.txt"));' Dit zijn routines die ik onmogelijk kan missen.

>>> "Ronald Klip" wrote:

>>> Dan zou je zo te zien geen bestanden mogen openen/schrijven. Klinkt erg
>>> rigide. Gaat het niet om de 'gewone' safe_mode? (zie
>>> http://nl3.php.net/manual/en/features.safe-mode.php)

>>> Eduard Bekker schreef:
>> Begrijp ik goed, dat je dan geen relatieve, maar alleen absoluten paden moet
>> opgeven?

> "Ronald Klip" wrote:

> Ho ho, je slaat een stap over: is je provider inderdaad van plan om die
> zgn. safe mode te implementeren?

Ik begrepen dat dat de bedoeling was, zoals hij schreef:

> Geachte heer/mevrouw,
>
> De laatste tijd komt het helaas erg vaak voor dat machines in ons netwerk
> "gehacked" worden via slecht geprogrameerde PHP scripts. 1 van die veel
> gebruikte scripts is forum software phpBB. Ook PHP Nuke wordt vaak misbruikt
> door spammers.
> "Hackers" kunnen via een oude versie van phpBB toegang krijgen tot uw machine,
> tot de user waar apache onder draait. Daarna plaatsen ze vaak een (perl)
> daemon, waarmee ze uw server(s) kunnen gebruiken bij Denial of Service
> attacks. Ook scannen ze vaak vanaf een machine naar verdere "slachtoffers".
> We willen daarom iedereen wijzen op dit specifieke security probleem van
> phpBB, aangezien er veel mensen actief misbruik van aan het maken zijn. Update
> het zo snel mogelijk.
> Meer informatie kunt u vinden op:
> http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=244451
> <http://www.phpbb.com/phpBB/viewtopic...4&amp;t=244451>
> Mocht uw server toch misbruikt worden voor bijvoorbeeld DoS attacks, heeft u
> grote kans dat we helaas genoodzaakt zijn om deze (tijdelijk) af te sluiten.

en

> Even geleden hebben we al eens de global instelling gewijzigd en ik kan me
> herinneren dat toen een aantal sites van je niet meer werkte. We hebben dit
> toen weer terug gedraaid, maar houd er echter wel rekening mee dat we deze
> switch nogmaals zullen gaan maken (en in dat geval blijvend). Dat voorkomt
> namelijk al een aantal eenvoudige lekken in scripting.

en

> 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.


--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

Mime-version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit
Lines: 35
Organization: Wanadoo
NNTP-Posting-Date: 15 Dec 2004 23:46:09 GMT
NNTP-Posting-Host: c3eea0252.cable.wanadoo.nl
X-Trace: 1103154369 maya.euronet.nl 45939 62.234.2.82:55227
X-Complaints-To: abuse@wanadoo.nl
Xref: nl-news.euro.net nl.internet.www.server-side:37175

On 15-12-2004 06:27, in article
41bfcb2a$0$328$e4fe514c@dreader3.news.xs4all.nl, "Daniel Tryba"
<spam@tryba.invalid> wrote:

> Eduard Bekker <e.bekker@layout.nl> wrote:
[snip]

> 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.
>
> Zou er geen alternatief zijn, dan kan ik mijn toko eigenlijk wel sluiten.
>
>
> Weet iemand een alternatief hiervoor, zonder dat ik hele boel overhoop hoef
> te gooien of gedwongen ben al mijn sites bij een andere provider onder te
> brengen?
>
> Daar zou ik erg blij mee zijn.

Weet iemand hier nu het antwoord op?
Het lijktme dat hier toch een oplossing voor moet zijn?

Bij voorbaat dank!

--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

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"]);
> ?>
>
> Een hacker kan door middel van de url
>
> http://yoursite.invalid/index.php?pa...valid/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?



--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

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.
>>>
>>> Zou er geen alternatief zijn, dan kan ik mijn toko eigenlijk wel sluiten.
>
> Waaruit maak je nu eigenlijk op dat include/file/enz. niet meer gaan
> werken?
>
> De oplossing is uitermate makkelijk: verhuizen.

De verhouding met mijn provider is verder uitstekend.
Bovendien: wie garandeert me dat niet bij een volgende provider dezelfde
problemen ontstaan?

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


--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/

[Eduard Bekker]

On 16-12-2004 13:15, in article 41c17c6e$0$78738$e4fe514c@news.xs4all.nl,
"Michiel de Roo" <yourlove@welovespam.nl> wrote:


>
> 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']);
> ?>

Eigenlijk doe ik dit altijd al.


--
/\/\/\/\/\/\/\/\/\
..|
..| Groetjes, Eduard
..|
\/\/\/\/\/\/\/\/\/