1.高手们能列一下常见的安全性问题么?
2.我见过有个好像是1' or '1'='1漏洞,这是什么?
3.还听说过sql注入攻击问题.详细是怎样的?
谢谢啦^_^
13 个解决方案
#1
1.转贴一篇文章，
2.3.不知道:(
通过对php一些服务器端特性的配置加强php的安全
前面象Shaun Clowes和rfp等都比较详细的介绍了php、cgi程序在编程过程中遇到的问题，以及如何通过应用程序漏洞突破系统，这篇文章我们来通过对php的一些服务器端特性来进行配置加强php的安全。写cgi脚本的时候我们的确一定注意各种安全问题，对用户输入进行严格的过滤，但是常在岸边走哪有不湿鞋，吃烧饼哪有不掉芝麻，人有失蹄马有失手，连著名的phpnuke、phpMyAdmin等程序都出现过很严重的问题，更何况象我等小混混写的脚本。所以现在我们假设php脚本已经出现严重问题，比如象前一阵子 phpnuke的可以上传php脚本的大问题了，我们如何通过对服务器的配置使脚本出现如此问题也不能突破系统。
1、编译的时候注意补上已知的漏洞
从4.0.5开始，php的mail函数加入了第五个参数，但它没有好好过滤，使得php应用程序能突破safe_mode的限制而去执行命令。所以使用4.0.5和4.0.6的时候在编译前我们需要修改php源码包里ext/standard/mail.c文件，禁止mail函数的第五参数或过滤shell字符。在mail.c文件的第152行，也就是下面这行：
if (extra_cmd != NULL) {
后面加上extra_cmd=NULL;或extra_cmd = php_escape_shell_cmd(extra_cmd);然后编译php那么我们就修补了这个漏洞。
2、修改php.ini配置文件
以php发行版的php.ini-dist为蓝本进行修改。
1)Error handling and logging
在Error handling and logging部分可以做一些设定。先找到：
display_errors = On
php缺省是打开错误信息显示的，我们把它改为：
display_errors = Off
关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下：
log_errors = Off
改为：
log_errors = On
以及指定文件，找到下面这行：
;error_log = filename
去掉前面的;注释，把filename改为指定文件，如/usr/local/apache/logs/php_error.log
error_log = /usr/local/apache/logs/php_error.log
这样所有的错误都会写到php_error.log文件里。
2)Safe Mode
php的safe_mode功能对很多函数进行了限制或禁用了，能在很大程度解决php的安全问题。在Safe Mode部分找到：
safe_mode = Off
改为：
safe_mode = On
这样就打开了safe_mode功能。象一些能执行系统命令的函数shell_exec()和``被禁止，其它的一些执行函数如：exec(), system(), passthru(), popen()将被限制只能执行safe_mode_exec_dir指定目录下的程序。如果你实在是要执行一些命令或程序，找到以下：
safe_mode_exec_dir =
指定要执行的程序的路径，如：
safe_mode_exec_dir = /usr/local/php/exec
然后把要用的程序拷到/usr/local/php/exec目录下，这样，象上面的被限制的函数还能执行该目录里的程序。
关于安全模式下受限函数的详细信息请查看php主站的说明：
http://www.php.net/manual/en/features.safe-mode.php
3)disable_functions
如果你对一些函数的危害性不太清楚，而且也没有使用，索性把这些函数禁止了。找到下面这行：
disable_functions =
在”=“后面加上要禁止的函数，多个函数用”,“隔开。
3、修改httpd.conf
如果你只允许你的php脚本程序在web目录里操作，还可以修改httpd.conf文件限制php的操作路径。比如你的web目录是/usr/local/apache/htdocs，那么在httpd.conf里加上这么几行：
<Directory /usr/local/apache/htdocs>
php_admin_value open_basedir /usr/local/apache/htdocs
</Directory>
这样，如果脚本要读取/usr/local/apache/htdocs以外的文件将不会被允许，如果错误显示打开的话会提示这样的错误：
Warning: open_basedir restriction in effect. File is in wrong directory in
/usr/local/apache/htdocs/open.php on line 4 等等。
4、对php代码进行编译
Zend对php的贡献很大，php4的引擎就是用Zend的，而且它还开发了ZendOptimizer和ZendEncode等许多php的加强组件。优化器ZendOptimizer只需在http://www.zend.com注册就可以免费得到，下面几个是用于4.0.5和4.0.6的ZendOptimizer，文件名分别对于各自的系统：
ZendOptimizer-1.1.0-PHP_4.0.5-FreeBSD4.0-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Solaris-sparc.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Windows-i386.zip
优化器的安装非常方便，包里面都有详细的说明。以UNIX版本的为例，看清操作系统，把包里的ZendOptimizer.so文件解压到一个目录，假设是/usr/local/lib下，在php.ini里加上两句：
zend_optimizer.optimization_level=15
zend_extension="/usr/local/lib/ZendOptimizer.so" 就可以了。用phpinfo()看到Zend图标左边有下面文字：
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies
那么，优化器已经挂接成功了。
但是编译器ZendEncode并不是免费的，这里提供给大家一个http://www.PHPease.com的马勇设计的 编译器外壳，如果用于商业目的，请与http://www.zend.com联系取得许可协议。
php脚本编译后，脚本的执行速度增加不少，脚本文件只能看到一堆乱码，这将阻止攻击者进一步分析服
务器上的脚本程序，而且原先在php脚本里以明文存储的口令也得到了保密，如mysql的口令。不过在服务器端改脚本就比较麻烦了，还是本地改好再上传吧。
5、文件及目录的权限设置
web目录里除了上传目录，其它的目录和文件的权限一定不能让nobody用户有写权限。否则，攻击者可以修改主页文件，所以web目录的权限一定要设置好。
还有，php脚本的属主千万不能是root，因为safe_mode下读文件的函数被限制成被读文件的属主必须和当前执行脚本的属主是一样才能被读，否则如果错误显示打开的话会显示诸如以下的错误：
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /usr/local/apache/htdocs/open.php
on line 3
这样我们能防止许多系统文件被读，比如：/etc/passwd等。
上传目录和上传脚本的属主也要设成一样，否则会出现错误的，在safe_mode下这些要注意。
6、mysql的启动权限设置
mysql要注意的是不要用root来启动，最好另外建一个mysqladm用户。可以在/etc/rc.local等系统启动脚本里加上一句：
su mysqladm -c "/usr/local/mysql/share/mysql/mysql.server start"
这样系统重启后，也会自动用mysqladmin用户启动mysql进程。
7、日志文件及上传目录的审核及
查看日志和人的惰性有很大关系，要从那么大的日志文件里查找攻击痕迹有些大海捞针，而且也未必有。
web上传的目录里的文件，也应该经常检查，也许程序有问题，用户传上了一些非法的文件，比如执行脚本等。
8、操作系统自身的补丁
一样，给系统打已知漏洞的补丁是系统管理员最基本的职责，这也是最后一道防线。
经过以上的配置，虽然说不上固若金汤，但是也在相当程度上给攻击者的测试造成很多麻烦，即使php脚本程序出现比较严重的漏洞，攻击者也无法造成实际性的破坏。
如果您还有更古怪，更变态的配置方法，希望能一起分享分享；）
2.3.不知道:(
通过对php一些服务器端特性的配置加强php的安全
前面象Shaun Clowes和rfp等都比较详细的介绍了php、cgi程序在编程过程中遇到的问题，以及如何通过应用程序漏洞突破系统，这篇文章我们来通过对php的一些服务器端特性来进行配置加强php的安全。写cgi脚本的时候我们的确一定注意各种安全问题，对用户输入进行严格的过滤，但是常在岸边走哪有不湿鞋，吃烧饼哪有不掉芝麻，人有失蹄马有失手，连著名的phpnuke、phpMyAdmin等程序都出现过很严重的问题，更何况象我等小混混写的脚本。所以现在我们假设php脚本已经出现严重问题，比如象前一阵子 phpnuke的可以上传php脚本的大问题了，我们如何通过对服务器的配置使脚本出现如此问题也不能突破系统。
1、编译的时候注意补上已知的漏洞
从4.0.5开始，php的mail函数加入了第五个参数，但它没有好好过滤，使得php应用程序能突破safe_mode的限制而去执行命令。所以使用4.0.5和4.0.6的时候在编译前我们需要修改php源码包里ext/standard/mail.c文件，禁止mail函数的第五参数或过滤shell字符。在mail.c文件的第152行，也就是下面这行：
if (extra_cmd != NULL) {
后面加上extra_cmd=NULL;或extra_cmd = php_escape_shell_cmd(extra_cmd);然后编译php那么我们就修补了这个漏洞。
2、修改php.ini配置文件
以php发行版的php.ini-dist为蓝本进行修改。
1)Error handling and logging
在Error handling and logging部分可以做一些设定。先找到：
display_errors = On
php缺省是打开错误信息显示的，我们把它改为：
display_errors = Off
关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下：
log_errors = Off
改为：
log_errors = On
以及指定文件，找到下面这行：
;error_log = filename
去掉前面的;注释，把filename改为指定文件，如/usr/local/apache/logs/php_error.log
error_log = /usr/local/apache/logs/php_error.log
这样所有的错误都会写到php_error.log文件里。
2)Safe Mode
php的safe_mode功能对很多函数进行了限制或禁用了，能在很大程度解决php的安全问题。在Safe Mode部分找到：
safe_mode = Off
改为：
safe_mode = On
这样就打开了safe_mode功能。象一些能执行系统命令的函数shell_exec()和``被禁止，其它的一些执行函数如：exec(), system(), passthru(), popen()将被限制只能执行safe_mode_exec_dir指定目录下的程序。如果你实在是要执行一些命令或程序，找到以下：
safe_mode_exec_dir =
指定要执行的程序的路径，如：
safe_mode_exec_dir = /usr/local/php/exec
然后把要用的程序拷到/usr/local/php/exec目录下，这样，象上面的被限制的函数还能执行该目录里的程序。
关于安全模式下受限函数的详细信息请查看php主站的说明：
http://www.php.net/manual/en/features.safe-mode.php
3)disable_functions
如果你对一些函数的危害性不太清楚，而且也没有使用，索性把这些函数禁止了。找到下面这行：
disable_functions =
在”=“后面加上要禁止的函数，多个函数用”,“隔开。
3、修改httpd.conf
如果你只允许你的php脚本程序在web目录里操作，还可以修改httpd.conf文件限制php的操作路径。比如你的web目录是/usr/local/apache/htdocs，那么在httpd.conf里加上这么几行：
<Directory /usr/local/apache/htdocs>
php_admin_value open_basedir /usr/local/apache/htdocs
</Directory>
这样，如果脚本要读取/usr/local/apache/htdocs以外的文件将不会被允许，如果错误显示打开的话会提示这样的错误：
Warning: open_basedir restriction in effect. File is in wrong directory in
/usr/local/apache/htdocs/open.php on line 4 等等。
4、对php代码进行编译
Zend对php的贡献很大，php4的引擎就是用Zend的，而且它还开发了ZendOptimizer和ZendEncode等许多php的加强组件。优化器ZendOptimizer只需在http://www.zend.com注册就可以免费得到，下面几个是用于4.0.5和4.0.6的ZendOptimizer，文件名分别对于各自的系统：
ZendOptimizer-1.1.0-PHP_4.0.5-FreeBSD4.0-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Solaris-sparc.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Windows-i386.zip
优化器的安装非常方便，包里面都有详细的说明。以UNIX版本的为例，看清操作系统，把包里的ZendOptimizer.so文件解压到一个目录，假设是/usr/local/lib下，在php.ini里加上两句：
zend_optimizer.optimization_level=15
zend_extension="/usr/local/lib/ZendOptimizer.so" 就可以了。用phpinfo()看到Zend图标左边有下面文字：
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies
那么，优化器已经挂接成功了。
但是编译器ZendEncode并不是免费的，这里提供给大家一个http://www.PHPease.com的马勇设计的 编译器外壳，如果用于商业目的，请与http://www.zend.com联系取得许可协议。
php脚本编译后，脚本的执行速度增加不少，脚本文件只能看到一堆乱码，这将阻止攻击者进一步分析服
务器上的脚本程序，而且原先在php脚本里以明文存储的口令也得到了保密，如mysql的口令。不过在服务器端改脚本就比较麻烦了，还是本地改好再上传吧。
5、文件及目录的权限设置
web目录里除了上传目录，其它的目录和文件的权限一定不能让nobody用户有写权限。否则，攻击者可以修改主页文件，所以web目录的权限一定要设置好。
还有，php脚本的属主千万不能是root，因为safe_mode下读文件的函数被限制成被读文件的属主必须和当前执行脚本的属主是一样才能被读，否则如果错误显示打开的话会显示诸如以下的错误：
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /usr/local/apache/htdocs/open.php
on line 3
这样我们能防止许多系统文件被读，比如：/etc/passwd等。
上传目录和上传脚本的属主也要设成一样，否则会出现错误的，在safe_mode下这些要注意。
6、mysql的启动权限设置
mysql要注意的是不要用root来启动，最好另外建一个mysqladm用户。可以在/etc/rc.local等系统启动脚本里加上一句：
su mysqladm -c "/usr/local/mysql/share/mysql/mysql.server start"
这样系统重启后，也会自动用mysqladmin用户启动mysql进程。
7、日志文件及上传目录的审核及
查看日志和人的惰性有很大关系，要从那么大的日志文件里查找攻击痕迹有些大海捞针，而且也未必有。
web上传的目录里的文件，也应该经常检查，也许程序有问题，用户传上了一些非法的文件，比如执行脚本等。
8、操作系统自身的补丁
一样，给系统打已知漏洞的补丁是系统管理员最基本的职责，这也是最后一道防线。
经过以上的配置，虽然说不上固若金汤，但是也在相当程度上给攻击者的测试造成很多麻烦，即使php脚本程序出现比较严重的漏洞，攻击者也无法造成实际性的破坏。
如果您还有更古怪，更变态的配置方法，希望能一起分享分享；）
#2
谢谢 :)
有关于代码编写的安全问题么?
:)
有关于代码编写的安全问题么?
:)
#3
http://www.xfocus.net/articles/200111/304.html
http://www.52157.com/shownews.asp?news_id=315
http://www.moderntech.com.cn/darticle/list.asp?id=941
http://www.52157.com/shownews.asp?news_id=315
http://www.moderntech.com.cn/darticle/list.asp?id=941
#4
一般策略
一个绝对安全的系统是不可能实现的，因此一个安全策略的核心通常都是寻求风险与可用性之间的平衡点。如果用户提交的每个变量都需要两种生物统计学的校验（例如视网膜扫描和指纹检验），那么我们将会需要进行极其高阶的计算。这还可能造成我们需要花费半个小时来填写一个及其繁琐的表单，使得用户更倾向于寻找一些捷径来绕过这些安全机制。
最好的安全策略通常能够不那么明显地适应环境的需求，它不会妨碍用户完成他们的工作，也不会使代码编写员面过分负担复杂的情形。实际上，一些安全攻击的成功正是这种过分冗杂的安全机制随着时间逐渐毁坏的结果。
数据库安全
现在，为了使得网站能够提供各种各样动态的内容，数据库已经成为所有基于 WEB 应用程序最重要的组件。由于一些十分敏感或者保密的信息可能会存储在这样的数据库中，因此，您需要非常慎重的考虑如何保护它们。
为了能够存储或者检索信息，您需要连接到数据库，发送一个合法的查询命令，得到结果，然后关闭连接
…………
可以参考php手册，php中文指南等书。
一个绝对安全的系统是不可能实现的，因此一个安全策略的核心通常都是寻求风险与可用性之间的平衡点。如果用户提交的每个变量都需要两种生物统计学的校验（例如视网膜扫描和指纹检验），那么我们将会需要进行极其高阶的计算。这还可能造成我们需要花费半个小时来填写一个及其繁琐的表单，使得用户更倾向于寻找一些捷径来绕过这些安全机制。
最好的安全策略通常能够不那么明显地适应环境的需求，它不会妨碍用户完成他们的工作，也不会使代码编写员面过分负担复杂的情形。实际上，一些安全攻击的成功正是这种过分冗杂的安全机制随着时间逐渐毁坏的结果。
数据库安全
现在，为了使得网站能够提供各种各样动态的内容，数据库已经成为所有基于 WEB 应用程序最重要的组件。由于一些十分敏感或者保密的信息可能会存储在这样的数据库中，因此，您需要非常慎重的考虑如何保护它们。
为了能够存储或者检索信息，您需要连接到数据库，发送一个合法的查询命令，得到结果，然后关闭连接
…………
可以参考php手册，php中文指南等书。
#5
mark
#6
好！！
#7
2.我见过有个好像是1' or '1'='1漏洞,这是什么?
3.还听说过sql注入攻击问题.详细是怎样的?
没有人知道这个么? ;(
3.还听说过sql注入攻击问题.详细是怎样的?
没有人知道这个么? ;(
#8
1' or '1'='1 的漏洞可以用addslashes()函数来解决。
有些程序员在判断用户名和密码的时候直接使用了用户提交的变量生成的sql查询。
1' or '1'='1 的结果永远为真，故可以跳过验证。
这要靠程序员的经验和安全意识。
严谨的代码不仅要安全，也要考虑效率。
有些程序员在判断用户名和密码的时候直接使用了用户提交的变量生成的sql查询。
1' or '1'='1 的结果永远为真，故可以跳过验证。
这要靠程序员的经验和安全意识。
严谨的代码不仅要安全，也要考虑效率。
#9
ok
#10
谢谢,那关于sql注入攻击的呢?^_^
#11
精华！
#12
谢谢了
#13
刷分来了
#1
1.转贴一篇文章，
2.3.不知道:(
通过对php一些服务器端特性的配置加强php的安全
前面象Shaun Clowes和rfp等都比较详细的介绍了php、cgi程序在编程过程中遇到的问题，以及如何通过应用程序漏洞突破系统，这篇文章我们来通过对php的一些服务器端特性来进行配置加强php的安全。写cgi脚本的时候我们的确一定注意各种安全问题，对用户输入进行严格的过滤，但是常在岸边走哪有不湿鞋，吃烧饼哪有不掉芝麻，人有失蹄马有失手，连著名的phpnuke、phpMyAdmin等程序都出现过很严重的问题，更何况象我等小混混写的脚本。所以现在我们假设php脚本已经出现严重问题，比如象前一阵子 phpnuke的可以上传php脚本的大问题了，我们如何通过对服务器的配置使脚本出现如此问题也不能突破系统。
1、编译的时候注意补上已知的漏洞
从4.0.5开始，php的mail函数加入了第五个参数，但它没有好好过滤，使得php应用程序能突破safe_mode的限制而去执行命令。所以使用4.0.5和4.0.6的时候在编译前我们需要修改php源码包里ext/standard/mail.c文件，禁止mail函数的第五参数或过滤shell字符。在mail.c文件的第152行，也就是下面这行：
if (extra_cmd != NULL) {
后面加上extra_cmd=NULL;或extra_cmd = php_escape_shell_cmd(extra_cmd);然后编译php那么我们就修补了这个漏洞。
2、修改php.ini配置文件
以php发行版的php.ini-dist为蓝本进行修改。
1)Error handling and logging
在Error handling and logging部分可以做一些设定。先找到：
display_errors = On
php缺省是打开错误信息显示的，我们把它改为：
display_errors = Off
关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下：
log_errors = Off
改为：
log_errors = On
以及指定文件，找到下面这行：
;error_log = filename
去掉前面的;注释，把filename改为指定文件，如/usr/local/apache/logs/php_error.log
error_log = /usr/local/apache/logs/php_error.log
这样所有的错误都会写到php_error.log文件里。
2)Safe Mode
php的safe_mode功能对很多函数进行了限制或禁用了，能在很大程度解决php的安全问题。在Safe Mode部分找到：
safe_mode = Off
改为：
safe_mode = On
这样就打开了safe_mode功能。象一些能执行系统命令的函数shell_exec()和``被禁止，其它的一些执行函数如：exec(), system(), passthru(), popen()将被限制只能执行safe_mode_exec_dir指定目录下的程序。如果你实在是要执行一些命令或程序，找到以下：
safe_mode_exec_dir =
指定要执行的程序的路径，如：
safe_mode_exec_dir = /usr/local/php/exec
然后把要用的程序拷到/usr/local/php/exec目录下，这样，象上面的被限制的函数还能执行该目录里的程序。
关于安全模式下受限函数的详细信息请查看php主站的说明：
http://www.php.net/manual/en/features.safe-mode.php
3)disable_functions
如果你对一些函数的危害性不太清楚，而且也没有使用，索性把这些函数禁止了。找到下面这行：
disable_functions =
在”=“后面加上要禁止的函数，多个函数用”,“隔开。
3、修改httpd.conf
如果你只允许你的php脚本程序在web目录里操作，还可以修改httpd.conf文件限制php的操作路径。比如你的web目录是/usr/local/apache/htdocs，那么在httpd.conf里加上这么几行：
<Directory /usr/local/apache/htdocs>
php_admin_value open_basedir /usr/local/apache/htdocs
</Directory>
这样，如果脚本要读取/usr/local/apache/htdocs以外的文件将不会被允许，如果错误显示打开的话会提示这样的错误：
Warning: open_basedir restriction in effect. File is in wrong directory in
/usr/local/apache/htdocs/open.php on line 4 等等。
4、对php代码进行编译
Zend对php的贡献很大，php4的引擎就是用Zend的，而且它还开发了ZendOptimizer和ZendEncode等许多php的加强组件。优化器ZendOptimizer只需在http://www.zend.com注册就可以免费得到，下面几个是用于4.0.5和4.0.6的ZendOptimizer，文件名分别对于各自的系统：
ZendOptimizer-1.1.0-PHP_4.0.5-FreeBSD4.0-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Solaris-sparc.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Windows-i386.zip
优化器的安装非常方便，包里面都有详细的说明。以UNIX版本的为例，看清操作系统，把包里的ZendOptimizer.so文件解压到一个目录，假设是/usr/local/lib下，在php.ini里加上两句：
zend_optimizer.optimization_level=15
zend_extension="/usr/local/lib/ZendOptimizer.so" 就可以了。用phpinfo()看到Zend图标左边有下面文字：
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies
那么，优化器已经挂接成功了。
但是编译器ZendEncode并不是免费的，这里提供给大家一个http://www.PHPease.com的马勇设计的 编译器外壳，如果用于商业目的，请与http://www.zend.com联系取得许可协议。
php脚本编译后，脚本的执行速度增加不少，脚本文件只能看到一堆乱码，这将阻止攻击者进一步分析服
务器上的脚本程序，而且原先在php脚本里以明文存储的口令也得到了保密，如mysql的口令。不过在服务器端改脚本就比较麻烦了，还是本地改好再上传吧。
5、文件及目录的权限设置
web目录里除了上传目录，其它的目录和文件的权限一定不能让nobody用户有写权限。否则，攻击者可以修改主页文件，所以web目录的权限一定要设置好。
还有，php脚本的属主千万不能是root，因为safe_mode下读文件的函数被限制成被读文件的属主必须和当前执行脚本的属主是一样才能被读，否则如果错误显示打开的话会显示诸如以下的错误：
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /usr/local/apache/htdocs/open.php
on line 3
这样我们能防止许多系统文件被读，比如：/etc/passwd等。
上传目录和上传脚本的属主也要设成一样，否则会出现错误的，在safe_mode下这些要注意。
6、mysql的启动权限设置
mysql要注意的是不要用root来启动，最好另外建一个mysqladm用户。可以在/etc/rc.local等系统启动脚本里加上一句：
su mysqladm -c "/usr/local/mysql/share/mysql/mysql.server start"
这样系统重启后，也会自动用mysqladmin用户启动mysql进程。
7、日志文件及上传目录的审核及
查看日志和人的惰性有很大关系，要从那么大的日志文件里查找攻击痕迹有些大海捞针，而且也未必有。
web上传的目录里的文件，也应该经常检查，也许程序有问题，用户传上了一些非法的文件，比如执行脚本等。
8、操作系统自身的补丁
一样，给系统打已知漏洞的补丁是系统管理员最基本的职责，这也是最后一道防线。
经过以上的配置，虽然说不上固若金汤，但是也在相当程度上给攻击者的测试造成很多麻烦，即使php脚本程序出现比较严重的漏洞，攻击者也无法造成实际性的破坏。
如果您还有更古怪，更变态的配置方法，希望能一起分享分享；）
2.3.不知道:(
通过对php一些服务器端特性的配置加强php的安全
前面象Shaun Clowes和rfp等都比较详细的介绍了php、cgi程序在编程过程中遇到的问题，以及如何通过应用程序漏洞突破系统，这篇文章我们来通过对php的一些服务器端特性来进行配置加强php的安全。写cgi脚本的时候我们的确一定注意各种安全问题，对用户输入进行严格的过滤，但是常在岸边走哪有不湿鞋，吃烧饼哪有不掉芝麻，人有失蹄马有失手，连著名的phpnuke、phpMyAdmin等程序都出现过很严重的问题，更何况象我等小混混写的脚本。所以现在我们假设php脚本已经出现严重问题，比如象前一阵子 phpnuke的可以上传php脚本的大问题了，我们如何通过对服务器的配置使脚本出现如此问题也不能突破系统。
1、编译的时候注意补上已知的漏洞
从4.0.5开始，php的mail函数加入了第五个参数，但它没有好好过滤，使得php应用程序能突破safe_mode的限制而去执行命令。所以使用4.0.5和4.0.6的时候在编译前我们需要修改php源码包里ext/standard/mail.c文件，禁止mail函数的第五参数或过滤shell字符。在mail.c文件的第152行，也就是下面这行：
if (extra_cmd != NULL) {
后面加上extra_cmd=NULL;或extra_cmd = php_escape_shell_cmd(extra_cmd);然后编译php那么我们就修补了这个漏洞。
2、修改php.ini配置文件
以php发行版的php.ini-dist为蓝本进行修改。
1)Error handling and logging
在Error handling and logging部分可以做一些设定。先找到：
display_errors = On
php缺省是打开错误信息显示的，我们把它改为：
display_errors = Off
关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下：
log_errors = Off
改为：
log_errors = On
以及指定文件，找到下面这行：
;error_log = filename
去掉前面的;注释，把filename改为指定文件，如/usr/local/apache/logs/php_error.log
error_log = /usr/local/apache/logs/php_error.log
这样所有的错误都会写到php_error.log文件里。
2)Safe Mode
php的safe_mode功能对很多函数进行了限制或禁用了，能在很大程度解决php的安全问题。在Safe Mode部分找到：
safe_mode = Off
改为：
safe_mode = On
这样就打开了safe_mode功能。象一些能执行系统命令的函数shell_exec()和``被禁止，其它的一些执行函数如：exec(), system(), passthru(), popen()将被限制只能执行safe_mode_exec_dir指定目录下的程序。如果你实在是要执行一些命令或程序，找到以下：
safe_mode_exec_dir =
指定要执行的程序的路径，如：
safe_mode_exec_dir = /usr/local/php/exec
然后把要用的程序拷到/usr/local/php/exec目录下，这样，象上面的被限制的函数还能执行该目录里的程序。
关于安全模式下受限函数的详细信息请查看php主站的说明：
http://www.php.net/manual/en/features.safe-mode.php
3)disable_functions
如果你对一些函数的危害性不太清楚，而且也没有使用，索性把这些函数禁止了。找到下面这行：
disable_functions =
在”=“后面加上要禁止的函数，多个函数用”,“隔开。
3、修改httpd.conf
如果你只允许你的php脚本程序在web目录里操作，还可以修改httpd.conf文件限制php的操作路径。比如你的web目录是/usr/local/apache/htdocs，那么在httpd.conf里加上这么几行：
<Directory /usr/local/apache/htdocs>
php_admin_value open_basedir /usr/local/apache/htdocs
</Directory>
这样，如果脚本要读取/usr/local/apache/htdocs以外的文件将不会被允许，如果错误显示打开的话会提示这样的错误：
Warning: open_basedir restriction in effect. File is in wrong directory in
/usr/local/apache/htdocs/open.php on line 4 等等。
4、对php代码进行编译
Zend对php的贡献很大，php4的引擎就是用Zend的，而且它还开发了ZendOptimizer和ZendEncode等许多php的加强组件。优化器ZendOptimizer只需在http://www.zend.com注册就可以免费得到，下面几个是用于4.0.5和4.0.6的ZendOptimizer，文件名分别对于各自的系统：
ZendOptimizer-1.1.0-PHP_4.0.5-FreeBSD4.0-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Solaris-sparc.tar.gz
ZendOptimizer-1.1.0-PHP_4.0.5-Windows-i386.zip
优化器的安装非常方便，包里面都有详细的说明。以UNIX版本的为例，看清操作系统，把包里的ZendOptimizer.so文件解压到一个目录，假设是/usr/local/lib下，在php.ini里加上两句：
zend_optimizer.optimization_level=15
zend_extension="/usr/local/lib/ZendOptimizer.so" 就可以了。用phpinfo()看到Zend图标左边有下面文字：
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies
那么，优化器已经挂接成功了。
但是编译器ZendEncode并不是免费的，这里提供给大家一个http://www.PHPease.com的马勇设计的 编译器外壳，如果用于商业目的，请与http://www.zend.com联系取得许可协议。
php脚本编译后，脚本的执行速度增加不少，脚本文件只能看到一堆乱码，这将阻止攻击者进一步分析服
务器上的脚本程序，而且原先在php脚本里以明文存储的口令也得到了保密，如mysql的口令。不过在服务器端改脚本就比较麻烦了，还是本地改好再上传吧。
5、文件及目录的权限设置
web目录里除了上传目录，其它的目录和文件的权限一定不能让nobody用户有写权限。否则，攻击者可以修改主页文件，所以web目录的权限一定要设置好。
还有，php脚本的属主千万不能是root，因为safe_mode下读文件的函数被限制成被读文件的属主必须和当前执行脚本的属主是一样才能被读，否则如果错误显示打开的话会显示诸如以下的错误：
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /usr/local/apache/htdocs/open.php
on line 3
这样我们能防止许多系统文件被读，比如：/etc/passwd等。
上传目录和上传脚本的属主也要设成一样，否则会出现错误的，在safe_mode下这些要注意。
6、mysql的启动权限设置
mysql要注意的是不要用root来启动，最好另外建一个mysqladm用户。可以在/etc/rc.local等系统启动脚本里加上一句：
su mysqladm -c "/usr/local/mysql/share/mysql/mysql.server start"
这样系统重启后，也会自动用mysqladmin用户启动mysql进程。
7、日志文件及上传目录的审核及
查看日志和人的惰性有很大关系，要从那么大的日志文件里查找攻击痕迹有些大海捞针，而且也未必有。
web上传的目录里的文件，也应该经常检查，也许程序有问题，用户传上了一些非法的文件，比如执行脚本等。
8、操作系统自身的补丁
一样，给系统打已知漏洞的补丁是系统管理员最基本的职责，这也是最后一道防线。
经过以上的配置，虽然说不上固若金汤，但是也在相当程度上给攻击者的测试造成很多麻烦，即使php脚本程序出现比较严重的漏洞，攻击者也无法造成实际性的破坏。
如果您还有更古怪，更变态的配置方法，希望能一起分享分享；）
#2
谢谢 :)
有关于代码编写的安全问题么?
:)
有关于代码编写的安全问题么?
:)
#3
http://www.xfocus.net/articles/200111/304.html
http://www.52157.com/shownews.asp?news_id=315
http://www.moderntech.com.cn/darticle/list.asp?id=941
http://www.52157.com/shownews.asp?news_id=315
http://www.moderntech.com.cn/darticle/list.asp?id=941
#4
一般策略
一个绝对安全的系统是不可能实现的，因此一个安全策略的核心通常都是寻求风险与可用性之间的平衡点。如果用户提交的每个变量都需要两种生物统计学的校验（例如视网膜扫描和指纹检验），那么我们将会需要进行极其高阶的计算。这还可能造成我们需要花费半个小时来填写一个及其繁琐的表单，使得用户更倾向于寻找一些捷径来绕过这些安全机制。
最好的安全策略通常能够不那么明显地适应环境的需求，它不会妨碍用户完成他们的工作，也不会使代码编写员面过分负担复杂的情形。实际上，一些安全攻击的成功正是这种过分冗杂的安全机制随着时间逐渐毁坏的结果。
数据库安全
现在，为了使得网站能够提供各种各样动态的内容，数据库已经成为所有基于 WEB 应用程序最重要的组件。由于一些十分敏感或者保密的信息可能会存储在这样的数据库中，因此，您需要非常慎重的考虑如何保护它们。
为了能够存储或者检索信息，您需要连接到数据库，发送一个合法的查询命令，得到结果，然后关闭连接
…………
可以参考php手册，php中文指南等书。
一个绝对安全的系统是不可能实现的，因此一个安全策略的核心通常都是寻求风险与可用性之间的平衡点。如果用户提交的每个变量都需要两种生物统计学的校验（例如视网膜扫描和指纹检验），那么我们将会需要进行极其高阶的计算。这还可能造成我们需要花费半个小时来填写一个及其繁琐的表单，使得用户更倾向于寻找一些捷径来绕过这些安全机制。
最好的安全策略通常能够不那么明显地适应环境的需求，它不会妨碍用户完成他们的工作，也不会使代码编写员面过分负担复杂的情形。实际上，一些安全攻击的成功正是这种过分冗杂的安全机制随着时间逐渐毁坏的结果。
数据库安全
现在，为了使得网站能够提供各种各样动态的内容，数据库已经成为所有基于 WEB 应用程序最重要的组件。由于一些十分敏感或者保密的信息可能会存储在这样的数据库中，因此，您需要非常慎重的考虑如何保护它们。
为了能够存储或者检索信息，您需要连接到数据库，发送一个合法的查询命令，得到结果，然后关闭连接
…………
可以参考php手册，php中文指南等书。
#5
mark
#6
好！！
#7
2.我见过有个好像是1' or '1'='1漏洞,这是什么?
3.还听说过sql注入攻击问题.详细是怎样的?
没有人知道这个么? ;(
3.还听说过sql注入攻击问题.详细是怎样的?
没有人知道这个么? ;(
#8
1' or '1'='1 的漏洞可以用addslashes()函数来解决。
有些程序员在判断用户名和密码的时候直接使用了用户提交的变量生成的sql查询。
1' or '1'='1 的结果永远为真，故可以跳过验证。
这要靠程序员的经验和安全意识。
严谨的代码不仅要安全，也要考虑效率。
有些程序员在判断用户名和密码的时候直接使用了用户提交的变量生成的sql查询。
1' or '1'='1 的结果永远为真，故可以跳过验证。
这要靠程序员的经验和安全意识。
严谨的代码不仅要安全，也要考虑效率。
#9
ok
#10
谢谢,那关于sql注入攻击的呢?^_^
#11
精华！
#12
谢谢了
#13
刷分来了