Security Implications on Shared Hosts

Posted by martin on 1 Jun 2002.

Besides variables coming from query strings ($_GET), posted form data ($_POST), and cookies ($_COOKIE) you should treat session variables as tainted too if your site is on a shared host.

User input

If you have used Perl you probably have heard of tainted variables - they are variables that come from user input and as such shouldn't be trusted. The only way to untaint a variable in Perl is to use a regular expression to extract a value out of it.

It doesn't matter what language you are using to build your scripts you should never trust user input.

What's so special on shared hosts

If your site is on a shared hosting service that probably means that other people may have the ability to open your files and get sensitive data out of there.

What's more if other sites on the host share the same domain - your site is reachable under a directory which is different from the root, cookies shouldn't be trusted. Not that it is a good idea to trust cookies but other people on the hosting service may generate sessions that will be valid for your site.

Tainted variables

Query strings, accessible via $_GET
Posted forms, accessible via $_POST
Cookies, accessible via $_COOKIE
Sessions on shared hosts, accessible via $_SESSION

The superglobal arrays $_GET... are available since PHP 4.1.0, for previous versions of PHP the equivalents are the $HTTP_*_VARS.

I didn't mention the case when you're using register_globals = on, because that implies that you don't care about security at all.

Comments

so... ???
by dude () on 24 Sep 2002 4:51pm GMT

OOpss!! You forgot to write the solution for this problem !??

A solution
by martin on 24 Sep 2002 5:39pm GMT

The solution is to always check important session data.

In my PHP login script there is an example which shows how you can check session data.

It does not show all available methods but just a few to get you started.

Security Implications on Shared Hosts
by guillem (catalaestape@terra.es) on 26 Sep 2002 7:58pm GMT

well basic things need to be done

validate data with javascript
few browsers dont support javascript so server side validation is needed too
formatting submited data especially if it needs to be shown without admin approval. Like htmlspecialchars() nl2br().. many ones
make sure the form can only be filled and submitted trought your site. Shouldn't really be a problem but in some cases its essential.

well thats my 2 cents on protecting forms. :)

On JavaScript
by martin on 27 Sep 2002 5:05pm GMT

The strange thing about JavaScript is that more and more people disable it according to statistics. In other words the JavaScript visitors are less than those who use browsers which support JavaScript - this should make you think about it before doing something client-side only.

RE: On Javascript
by Cameron () on 28 Nov 2003 7:33am GMT

"other words the JavaScript visitors are less than those who use browsers which support JavaScript"

Really? Which crack-pot website did you get that data from?

Last I checked, a whole 3 months ago which was after the date of your post, the stats showed only 6% of users disabled javascript and a further 1% used browsers that didn't support it at all.

7% is a far cry from 51% or more.

javascript
by pxl () on 19 Jul 2004 5:08pm GMT

Using javascript is ok, but it is by no means a method to rely on. And yes, some users have javascript disabled, especially panicked IE users maybe, hehe.

Server-side validation using regExps , intval, stripping html and SQL comments is the best way I know, although it takes the workload to the server.