Suzanne — Mon, 15 Mar 2004 03:26:22 +0000

Whenever possible I include files only in the same directory, or secure files in a non-browsable web directory accessed through a path, not a variable.

i.e. include('this/is/the/actual/path/to/the/file.php');

Where the browser viewable files are somewhere else like 'this/is/the/actual/path/to/www/files/'.

That way the important information isn't browsable (in case of php failure, errors, et cetera).

Chroder — Sun, 14 Mar 2004 22:47:10 +0000

Ah, I didn't know you were talking about variable includes. I see what you mean now.

Mark Hensler — Sun, 14 Mar 2004 22:28:11 +0000

Chroder wrote: "dot dot slash" simply means "up one directory"...

That's exactly why. Because it goes up one directory. And if you string them back to back (../../../), you can go up more than one directory.

Say someone uses a form upload script to send a malicious shell script into your /tmp directory. Then they navigate to a page on your site that uses include($folder/$file); They may be able to adjust $folder and $file to execute the malicious file.

And along the same lines of eval(), you must filter anything in system(), shell_exec(), exec(), passthru(), and the backtick operator (``).

Chroder — Sun, 14 Mar 2004 22:13:24 +0000

I was wondering that too. "dot dot slash" simply means "up one directory"...

Busy — Sun, 14 Mar 2004 22:11:32 +0000

Mark Hensler wrote: Any variables used in file paths for include() or require() calls should never contain dot dot slash (../ or ..\).

I don't use this method, but curious as to why include('../$folder/file.php') is bad.

If you have a variable in a include (or require) tag, this could be hijacked sure (reason to not do it) but how does the ../ or ..\ effect it?

Mark Hensler — Sat, 13 Mar 2004 07:09:42 +0000

Simply put, filter your data. Before you use a variable from get/post/cookie/etc, check to make sure there are no invalid (or only valid) characters (im assuming strings).

Examples:

Any variables used in file paths for include() or require() calls should never contain dot dot slash (../ or ..\).

Variables printed to the html source should first be cleansed of any Cross Site Scripting (ex: javascript code).

Any variables inserted into a database should be escaped (to prevent breaking the sql code).

Any variables put through an eval() call should be *very* closely scrutinized.

Suzanne — Sat, 13 Mar 2004 00:28:53 +0000

http://www.sitepoint.com/article/write-secure-scripts-php-4-2

emma12345 — Fri, 12 Mar 2004 23:59:38 +0000

Thanks Chroder,

Great stuff.. going to test all these ...very useful

Thanks guys

emma12345 — Fri, 12 Mar 2004 23:52:27 +0000

forwardtrends wrote: on any login screens .. make sure the user can only type in letters or numbers into the textfields. A simple apostraphe ' will break the code string your using and past that you can guess what is possible.

Oh yes that's very true, I saw this happen in a cgi script..cheers

Thanks

Chroder — Fri, 12 Mar 2004 23:50:09 +0000

If your working with a database, escape all of the database characters that could cause problems. For example, say you have a user log in accepting a username and password to get access to a special client area:

User inputs:
User: hax0r' or ''='
Pass: hax0r' or ''='

SQL Query run:
SELECT * FROM users WHERE user='hax0r' or ''='' AND pass='hax0r' or ''=''

Since "" does indeed equal "" (blank string equals blank string), the query would return with rows and the "hax0r" would have access. A solution to this would be to escape your data you stick into your query. For example, using the addslashes() function for PHP. This would make the query
[INDENT]SELECT * FROM users WHERE user='hax0r\' or \'\'=\'' AND pass='hax0r\' or \'\'=\''[/INDENT]
Which would not return any rows.

Another thing would be to double check where you're values are coming from. There are a couple of places that data could come from, amongst them are: sessions, cookies, get, post. So if you have something like this:

<?php
if($access = 'yes')
{
    // found secret area!!!
}
?>

The user could simply go
[INDENT]script.php?access=yes[/INDENT]
So if you make sure your getting the data from where you want to be getting it from, you should be alrignt.

<?php
$access = 'no';

// code to check login or whatever

if($access = 'yes')
{
    // found secret area!!!
}
?>

In that example, the access variable is set at the start of the script, so the same exploitation could not be used.