PHP: Security - Manual

User Contributed Notes
Security

administrator at galbadian dot com
24-Apr-2005 02:47


yeah alot of people dont think about the possibility of...



Lets say a user posts $var=" " . $dbpass . " "



and your page has 



echo($var)



which shows the var $dbpass (in this case the MySQL db pass)

nighma at skynet dot be
01-Mar-2005 03:04


Another new good site about security ;)



http://phpsec.org/

tobozo at phpsecure dot info
10-Sep-2004 09:21


another site about php and security : 



http://www.phpsecure.info



some parts of the content are available in english, french or russian... but all advisories are in english.

nick dot hristov at gmail dot com
02-Sep-2004 10:21


A correction to previous post by Dave Mink.



<Files ~ "\.inc$">

   Order allow,deny

   Deny from all

   Satisfy All

</Files>



Will not stop something like

http://www.yourserver.com/includefile.inc?pointlessvar=blahblah



Here is something more sophisticated for this task:



<Location ~ "/[^ ](?=\.inc(\?[^ ]*)?)/">

    Options None

    Order Allow, Deny

    Deny from All

    AllowOverride None

    Satisfy All

</Location>



Also, consider placing in your httpd.conf



<Location ~ "/[^ ](?=\.phps(\?[^ ]*)?)/">

    Options None

    Order Allow, Deny

    Deny from All

    AllowOverride None

    Satisfy All

</Location>

28-Aug-2004 11:21


Another good source of information on writing secure PHP code is http://securephp.damonkohler.com/

philip
05-Aug-2004 02:19


For tips on making your PHP code [more] secure, read this:

 * http://shiflett.org/php-security.pdf

ocrow at simplexity dot net
02-Jul-2003 07:16


If your PHP pages include() or require() files that live within the web server document root, for example library files in the same directory as the PHP pages, you must account for the possibility that attackers may call those library files directly.  



Any program level code in the library files (ie code not part of function definitions) will be directly executable by the caller outside of the scope of the intended calling sequence.  An attacker may be able to leverage this ability to cause unintended effects.



The most robust way to guard against this possibility is to prevent your webserver from calling the library scripts directly, either by moving them out of the document root, or by putting them in a folder configured to refuse web server access. With Apache for example, create a .htaccess file in the library script folder with these directives:



Order Allow,Deny

Deny from any

annonymous at domain dot com
27-Jun-2003 08:08


best bet is to build php as cgi, run under suexec, with chroot jailed users. Not the best, but fairly unobtrusive, provides several levels of checkpoints, and has only the detriment of being, well, kinda slow. 8)

ManifoldNick at columbus dot rr dot com
30-Apr-2003 12:30


Remember that security risks often don't involve months of prep work or backdoors or whatever else you saw on Swordfish ;) In fact one of the bigges newbie mistakes is not removing "<" from user input (especially when using message boards) so in theory a user could secerely mess up a page or even have your server run php scripts which would allow them to wreak havoc on your site.

25-Feb-2003 06:00


For real security you should consider providing chrooted jail's for your users.

IV. Security