You probably know that you can do this in PHP:
<?php include("http://example.com/foo.php"); >
This will include the output of that uri as executable PHP code. That's nifty, but it also exposes you to what are essentially cross-site scripting attacks (aka XSS). These aren't the tradtional definition of XSS, since normally that involved a compromise executing in the clients browser. This attack allows you to run code on the server. That's a bad thing. But lucky for you it's turned off by default in later versions of PHP.
Note thatregister_globalsis going to be deprecated (i.e., turned off by default) in the next version of PHP, because it often leads to security bugs.
...
You should do your best to write your scripts so that they do not require register_globals to be on
So, how do you prevent these problems in your code? Well...there are options.
register_globals=off in your php.ini. This means that variables passed on the query string now need to be accessed explicitly as $_GET['path']. From a security standpoint, your local variables cannot be set by form values unless you explicitly do so, and hopefully:
include("$_GET[path]/path/to/file.php");
looks really suspicious.allow_url_fopen=off in your php.ini. This prevents network urls from being opened via fopen(), include(), require() etc. Sure, being able to open network data sources via the file handling functions is neat, but it's clearly also dangerous and prone to intentional (and unintentional) abuse. If you need to open a remote file, use the curl facilities. Now please understand I'm not a PHP master by any stretch of the imagination. I'm still learning it. But I found this HUGE security hole interesting, and thought I'd share. I know Nash would be pleased with me being concerned about security, and then he'd promptly tell me how I'm wrong.
Tagged As Coding
Comments are Open (1)
Posted at 02:02 PM
Comments
Martin
Very interesting and beautiful site. It is a lot of helpful information. Thanks!
Posted by: Martin | March 13, 2006 12:28 PM