downloads | documentation | faq | getting help | mailing lists | reporting bugs | sites | links | my 
search for in the  
<Spotting ReferencesSecurity>
view the version of this page
Last updated: Thu, 21 Aug 2003

III. Security

Table of Contents
15. Security

add a note add a note User Contributed Notes
Dave Mink
19-Sep-2003 05:13
Another way to stop a user from looking at or executing the files read by include() or require() is to use a different file extension for them (i.e. *.inc) and add the following to your apache configuration:

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all
    Satisfy All

They won't execute unless used in a include() or require() since they don't have the *.php extension, and the server won't serve them up as text/plain with the directive above.
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.
26-Feb-2003 08:00
For real security you should consider providing chrooted jail's for your users.

<Spotting ReferencesSecurity>
 Last updated: Thu, 21 Aug 2003
show source | credits | sitemap | mirror sites 
Copyright © 2001-2003 The PHP Group
All rights reserved.
This mirror generously provided by:
Last updated: Sat 01 Nov 2003 04:13:36 EST EST