安全

简介
总则
以 CGI 模式安装时
- 可能受到的攻击
- 情形一：只运行公开的文件
- 情形二：使用 --enable-force-cgi-redirect 选项
- 情形三：设置 doc_root 或 user_dir
- 情形四：PHP 解释器放在 web 目录以外
以 Apache 模块安装时
文件系统安全
- Null 字符问题
数据库安全
- 设计数据库
- 连接数据库
- 加密存储模型
- SQL 注入
错误报告
使用 Register Globals
用户提交的数据
魔术引号
- 什么是魔术引号
- 为什么要用魔术引号
- 为什么不用魔术引号
- 关闭魔术引号
隐藏 PHP
保持更新

用户评论:

[#1] Anonymous [2015-07-13 09:41:56]

chroot is NOT a security feature. Don't use it as one. Please read the man pages of chroot to understand what its really used for

[#2] moehbass at gmail dot com [2007-07-11 22:34:48]

First, q much simpler solution to preventing people from viewing code inside of an includable file would be to give include file an extension that ends with php (e.g. myFile.inc.php).

Secondly, and more importantly, why on earth would you want to put program-level code in an include file? By that I mean something life this:

myFile.inc.php
--------------------------------
...
if ($var = 'whatever')
// connect to the database
else
// do something else.
--------------------------------

An include file should not contain logic! Rather, it is an encapsulated unit of code that should not do anything on its own unless asked to. To implement this ideology, consider including function definitions only in your include files, then once you include them in the script, call such functions from within your program (i.e. the script that included the inc file). If you don't know the names of the functions ab initio, use call_user_func() or call_user_func_array() and pass it the name of the function that's dependent on context.

If you MUST put program-level logic in your include files, consider simply putting it in the program!

Why should you consider this? How about variable name clashes for a starter! You can think of more, I am shure!

Hope that helped

[#3] dangan at blackjaguargaming dot net [2007-02-01 18:41:54]

I'd recommend a 404 over a 403 considering a 403 proves there is something worth hacking into.

index.php:
<?php define('isdoc',1); include('includes/include.sqlfunctions.php'); // Rest of code for index.php ?>

include.sqlfunctions.php (or other include file):
<?php if(isdoc !== 1) // Not identical to 1 { header('HTTP/1.1 404 Not Found'); echo "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head>"; echo "<body>\n<h1>Not Found</h1>\n<p>The requested URL ".$_SERVER['REQUEST_URI']." was not found on this server.</p>\n"; echo "<hr>\n".$_SERVER['SERVER_SIGNATURE']."\n</body></html>\n"; // Echo output similar to Apache's default 404 (if thats what you're using) exit; } // Rest of code for this include ?>

[#4] k [2006-10-25 16:06:32]

How about not putting the php code in the web-root at all...?

You can create a public directory with the css, html, etc and index.php there. Then use the include_path setting to point to the actual php code, eg...

webstuff
  phpcode
  public
    images
    css
    index.php

then set the include path to "../phpcode" and, as php is executed from the directory of the script, all should be well.

I'd also call the main index "main.page", or something else, instead of "index.php" and change the web server default index page. That way you cant get hit by things trawlling the web for index pages.

[#5] steffen at morkland dot com [2006-09-20 06:38:26]

In Reply to djjokla and others

Consider placing all incude files as mentioned before in a seperate folder containing a .htaccess containing a Order Deny,Allow

the create a index file, which is intended to handle ALL request made to you php application, then call it with index.php?view=index

the index file could look a bit like this:

<?php switch($_GET['view']){ case 'index': include('libs/index.php'); break; default: include('libs/404.php'); break; } ?>

this could be an array or something even more creative. it actually does'nt matter how you do it... running all pages through one central script has one big advantage.... CONTROL.
at any givin time, you can easily implement access control to functions without forgetting crucial files.

[#6] djjokla AT gmail dot com [2006-04-21 08:22:02]

If a single file has to be included than I use the following

index.php ( where the file is gonna be included )
___________
<?php     define('thefooter', TRUE);     include('folder/footer.inc.php'); ?>

and the footer file (for example) looks this way then

footer.inc.php ( the file to be inluded )
___________
<?php     defined('thefooter') or die('Not with me my friend');     echo('Copyright to me in the year 2000'); ?>

So when someone tries to access the footer.php file directly he/she/it will get the "Not with me my friend" messages written on the screen. An alternative option is to redirect the person who wants to access the file directly to a different location, so instead of the above code you would have to write the following in the footer.inc.php file.

<?php     defined('thefooter') or header('Location: http://www.location.com');     echo('Copyright to me in the year 2000'); ?>

In normal case a redirection to an external site would be annoying to the visitor, but since this visitor is more interested in hacking the site than in reading the content, I think it's only fair to create such an redirection. We dont' realy want someome like this on our sites.

For the file protection I use .htaccess in which I say to protect the file itself and every .inc file

<Files ~ "^.*\.([Hh][Tt]|[Ii][Nn][Cc])">
Order allow,deny
Deny from all
Satisfy All
</Files>

The .htaccess file should result an Error 403 if someone tries to access the files directly. If for some reason this shouldn't work, then the "Not with me my friend" text apears or a redirection (depending what is used)

In my eyes this looks o.k. and safe.

[#7] Thomas "Balu" Walter [2005-10-16 13:24:40]

Since many users can not modify apache configurations or use htaccess files, the best way to avoid unwanted access to include files would be a line at the beginning of the include-file:

<?php if (!defined('APPLICATION')) exit; ?>

And in all files that are allowed to be called externally:

<?php define('APPLICATION', true); ?>

Balu

[#8] nick dot hristov at gmail dot com [2004-09-02 08:21:46]

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>

[#9] ocrow at simplexity dot net [2003-07-02 05:16:19]

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

[#10] annonymous at domain dot com [2003-06-27 06:08:43]

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)

[#11] ManifoldNick at columbus dot rr dot com [2003-04-29 22:30:57]

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.

[#12] [2003-02-25 16:00:12]

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