Home › PHP

Security Implications on Shared Hosts

16 Jun 2002 — martin

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.

Bookmark/Search this post with:

Comments

24 September 2002 - 7:51am — dude (not verified)

so... ???

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

24 September 2002 - 8:39am — Martin Tsachev (not verified)

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.

26 September 2002 - 10:58am — guillem (not verified)

Security Implications on Shared Hosts

well basic things need to be done

  1. validate data with javascript
  2. few browsers dont support javascript so server side validation is needed too
  3. formatting submited data especially if it needs to be shown without admin approval. Like htmlspecialchars() nl2br().. many ones
  4. 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.:)

27 September 2002 - 8:05am — Martin Tsachev (not verified)

On JavaScript

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.

27 November 2003 - 10:33pm — Cameron (not verified)

RE: On Javascript

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

19 July 2004 - 8:08am — pxl (not verified)

javascript

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.