• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 194
  • Last Modified:

Home made php site security

Ok guys I've been working for a few weeks on a large php site from scratch, where the whole site runs on a set of scripts I wrote, the site currently receives over 100,000 visitors a month, and as such, I do not want security holes.

What can I do to ensure that if somebody does find a hole, I am able to find it and patch it?

Any ideas, comments, suggestions are welcomed...
0
benwiggy
Asked:
benwiggy
4 Solutions
 
alextr2003frCommented:
one of important points is to secure your :
- sessions against injections or hijackings
- your database queries against *sql injection problems see slash/quotes
  a good point to know too is that your script should be secure even if globals are On, also show all your errors by setting all your error reports on, it will prevent you from creating non intialized variables
ini_set ('display_errors',true);
error_reporting(E_ALL);

here is few links that should lead you to more detailed solutions :
http://www.acros.si/papers/session_fixation.pdf
http://fr3.php.net/session
http://fr3.php.net/session_regenerate_id
http://shiflett.org/articles/the-truth-about-sessions
http://www.phparch.com/issuedata/articles/article_66.pdf
http://phpsec.org/projects/guide/
0
 
zendomaniacCommented:

1st rule of thumb:

ALWAYS KEEP BACKUPS! It doesn't matter if you have to burn the entire webserver directory (along with the scripts) or mirror the files somewhere, but DO ALWAYS KEEP BACKUPS.

2nd rule:

Asses the security environment of you webserver first. If you are using Apache as your webserver, then visit this site which will help you secure and lock down Apache:

http://www.securityfocus.com/infocus/1694

And make sure you keep your webserver up to date with the latest security patches (if any). Don't forget to test out the patches on a NON-PRODUCTION system before actually applying the patches on a PRODUCTION system.

3rd rule:

Be a secure programmer. I mean, make sure you double, HECK! even tripple check any variables coming in and out of the user. Always, check, limit or restrict command or argument variables coming in to your php script. Most common buffer overflows exist when programmers don't verify or check variables for int, double and string data types. When dealing with FORMS, use the POST method instead of GET, because GET will submit values appended to the URL (eg home.php?password=123). POST will simply submit values in the body of the server request (hidden from the end user). Check out these articles about secure PHP programming:

http://www.zend.com/zend/art/art-oertli.php

http://www.developer.com/lang/article.php/918141

http://www.onlamp.com/pub/a/php/2003/04/03/php_security.html

http://www.pcworld.idg.com.au/index.php/id;1178207715;pp;2;fp;2;fpid;76768

Finally, 4th rule:

If somebody did find out security hole(s) in your scripts then:

1. Find out if the security hole(s) affect your php scripts only or the entire PHP ENGINE itself. If the security holes affect the entire PHP ENGINE then look for the patches in www.php.net. If the security exploit is relatively new and there are no patches available notify php.net team and they will advise you how to circumvent the security hole(s). However, DO NOT SPREAD THE METHODS OF THE SECURITY EXPLOITS IN ANY FORUMS, CHATS OR ANY EMAILS TO ANY ONE BESIDES AUTHORIZED OR TRUSTED PERSONALS.

2. To find out whether the security holes affect your scripts only, simply go through all the variables in your script and put an IF AND ELSE STATEMENT to post out (debug) all the data of the variables and then do an audit check, meaning asses whether the data coming from the variables were expected or not and what will happen if the data in the variables were changed.

There you go. ITS ALL ABOUT TESTING. The more you test, the better you are.

Hope it helps.

- zendomaniac
0
 
alextr2003frCommented:
P.S. : when you are in development mode you it is highly adviced to work with all errors reporting to E_ALL but once you put it on your server turn it off.
0
 
neesterCommented:
Furthering ALEXTR2003FR's response:

<?php

// Turn off all error reporting
error_reporting(0);

// Report simple running errors
error_reporting(E_ERROR | E_WARNING | E_PARSE);

// Reporting E_NOTICE can be good too (to report uninitialized
// variables or catch variable name misspellings ...)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

// Report all errors except E_NOTICE
// This is the default value set in php.ini
error_reporting(E_ALL ^ E_NOTICE);

// Report all PHP errors (bitwise 63 may be used in PHP 3)
error_reporting(E_ALL);

// Same as error_reporting(E_ALL);
ini_set('error_reporting', E_ALL);

?>

Source: http://au.php.net/error_reporting
0
 
quad341Commented:
a few tips:  usually you don't need register globals and shouldn't depend on them because they can be used against you IF you forget any elses to your ifs

insure all else blocks are proper and catch errors when possible.  I also found that checking access logs is sometimes useful.  you may want to try to implement your own tracking for security.

don't leave your debugging remarks publically viewable, ie. don't have results printing to html comments when they aren't needed by the user.

my best method:  open the system to a few friends and ask them to try to exploit it.  maybe do this for a few days, then fix anything you've found.

and as already said above:  KEEP BACKUPS
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now