Posted by Richard Lynch on 04/12/05 01:06

On Mon, April 11, 2005 3:05 am, zini10 said:
> ok, that will do some of the trick , but still , a user can just write a
> script which:
>
> for($i=0;$i<99999999;$i++)
> {
> $x=$x+1;
> }
>
> or something and refresh it the whole time and really slow down everybody
> else....

Yes.

Allowing untrusted users to write PHP scripts on your server is a big no-no.

PHP has some crude techniques (time_limit, memory_limit) to stop the silly
mistakes of scripters.

But if you have somebody who *WANTS* to harm your server, and they can
execute a PHP script on your server... Well, for starters,
denial-of-service attacks are only the baby child of the *BIG* problems
they can cause.

If you trust the users, but think they are inexperienced, you can:

1) Enable and shorten time_limit and memory_limit in php.ini

2) Set up a development server where they must test and QA their code,
along with a reasonable QA process for code to pass *before* it goes live.
The development server *MUST* be a box that you don't give a damn if it
gets sent crawling to its knees with a script like the above, or worse,
and you have to re-boot it. If it bothers you to re-boot it, it's not a
development server, or you don't have enough development servers. Note
that each user can install Apache/PHP/MySQL/Linux on their OWN el-cheapo
desktop you buy on eBay for $50, or find in a dumpster for FREE and then
they have a development "server" of their own that only hurts them when
they Nuke it. A three-stage QA process, then, where they test on their
own dev server, then promote it to a shared dev server for more extensive
QA, and then *IF* it passes, it goes "live"

I quit my last job in part because my "dev" server was a "live" box. Sheesh!


--
Like Music?
http://l-i-e.com/artists.htm

[Back to original message]