Greenguy's Board

Greenguy's Board (http://www.greenguysboard.com/board/index.php)
-   General Business Knowledge (http://www.greenguysboard.com/board/forumdisplay.php?f=10)
-   -   Some PHP security tips for programmers & non-programmers (http://www.greenguysboard.com/board/showthread.php?t=24937)

cd34 2005-10-12 03:39 PM

Some PHP security tips for programmers & non-programmers
 
Recently, there have been a number of exploits targeted on holes in commonly run software. Autolinks Pro was one such exploit with a direct call to al_initialize.php.

Today, we found another script that has also been exploited -- a script that was downloaded off a site that provides some quick and easy functionality, however, has a pretty serious url injection issue.

There are a few things that can be done to prevent this pretty easily. If the software you installed has an include or inc directory, it is generally accepted that you wouldn't ever directly link those files. To avoid most web exploits, an .htaccess file in the include directory with

Code:

deny from all
will prevent web hits on those files without preventing those files to be included by scripts on that machine. If you are remotely including those files, this won't work and you need to have those files still accessible.

Another method that can be used within your php script is:

Code:

if(strpos($_SERVER['PHP_SELF'], "filename.php") !== false) {
  exit;
}

where filename.php is the name of your include file. Since we're using strpos, you'll want to use somewhat unique filenames to avoid any false matches. For example, if your script blog.php includes /include/blog.php, it would match and thus error. This is probably not the desired behavior. You could name your include files, filename.inc.php or have some standard naming convention that you use.

I'm not a fan of using somefile.php.inc as a filename because even though you have prevented the server from parsing the file, a normally configured server will make that file viewable by a surfer, perhaps giving them other opportunities to exploit other code.

Even if it is code that is written by reputable firms, you still need to protect yourself.

Another possibility which might add some headaches is running mod_security, an apache module which attempts to filter requests that might be exploit attempts.

It isn't just php that is a problem here. Safe coding really needs to be used whenever you use any programming language.

Useless 2005-10-12 03:52 PM

Shit! |angry|

This is twice within two weeks you and Brian have saved my pathetic ass. :D I'm beginning to take it as a sign of respect that script kiddies have chosen to take advantage of my excess and mostly useless scripts at Whoring Wives. I just deleted the script that may have sparked this thread. Thanks for the heads up on ICQ and for blocking those bastard's access. |thumb I really need to inventory some of that old shit I have running in the background.

rich06 2005-10-13 02:18 AM

with all the scripts I develop I have all the php include files outside the web document root so they can only be pulled in by a php script and cannot be loaded up directly by a browser.

hth
rich

Halfdeck 2005-10-13 08:52 AM

Quote:

Originally Posted by rich06
with all the scripts I develop I have all the php include files outside the web document root so they can only be pulled in by a php script and cannot be loaded up directly by a browser.

hth
rich

I used to do the same, but the problem comes when I want to move servers, although the problem can be alleviated by using config files for paths, I guess. Another problem is making multiple domains dependent on one php file.

I use classes, not bare functions, so access to a php file doesn't do anything.

Useless 2005-10-13 09:05 AM

I download free scripts and put them exactly where the install directions tell me to put them.:D

mikeyddddd 2005-10-13 11:01 AM

cd24, thanks for the excellent advice. That's a good tip, rich06.

rich06 2005-10-13 04:45 PM

Quote:

Originally Posted by Halfdeck
I used to do the same, but the problem comes when I want to move servers, although the problem can be alleviated by using config files for paths, I guess. Another problem is making multiple domains dependent on one php file.

well i'm currently running a couple of domains off a single set of php code and that can be extended to multiple domains easily. At the moment I use a couple of scripts to handle all requests (1 for browser/1 for ajax) so only 2 scripts have to find their config files (which are outside the web root) but that's pretty trivial to do using dirname() and __FILE__ etc

cheers
rich

Halfdeck 2005-10-13 05:03 PM

Quote:

Originally Posted by rich06
well i'm currently running a couple of domains off a single set of php code and that can be extended to multiple domains easily.

Yeah, I had the same set up and I had no problems till I tried moving servers. One big advantage of having my scripts inside the domain is - as superficial as it sounds - the ability for me to edit the php files, html and graphic layout of my sites in Dreamweaver without having to keep reconnecting.

Also, each of my domain requires a variant of the basic classes I use across all domains, so it's easier for me to use a set per domain instead of set per server.

raymor 2005-10-13 07:40 PM

More PHP security advice:

ALL PHP scripts have security issues, including
the following script, which lets any visitor to the
site upload any file they want to your server:
PHP Code:

<?php ?>

Even a totally empty PHP file with no code lets
people uploaded files to your server due to the
design (or rather lack of design) of PHP itself.

To improve PHP security turn register_globals off,
fopen_url off, open_basedir on, and except
for directories that hold scripts which accept
file uploads turn file uploads off.

oast 2005-10-14 12:08 PM

Another option is to deter the 'hackers' in the first place by:
1) disguising the fact you use scripting by renaming your .php files to .htm and adding the following to your .htaccess
Quote:

AddType application/x-httpd-php .htm
Using .htm istead of .html will let you have static files without putting undue load on the server.

2) hiding all file extensions using mod_rewrite so that they appear to be directories.

I do that at my TopSites list at topsites.allyoursex.com


Option 1 would be the easiest for most, I expect, but I mentioned option 2 as an alternative for those in position to use it.


All times are GMT -4. The time now is 01:38 AM.

Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© Greenguy Marketing Inc