PHP基础第十六章安全-KeepStudy

PHP基础第十六章安全

## 1、以 CGI 模式安装时
可能受到的攻击
- 访问系统文件
- 访问服务器上的任意目录

#### 情形一：只运行公开的文件
如果 web 服务器中所有内容都受到密码或 IP 地址的访问限制，就不需要设置这些选项。如果 web 服务器不支持重定向，或者 web 服务器不能和 PHP 通信而使访问请求变得更为安全，可以在 configure 脚本中指定 --enable-force-cgi-redirect 选项。

#### 情形二：使用 --enable-force-cgi-redirect 选项
此编译选项可以防止任何人通过如 http://my.host/cgi-bin/php/secretdir/script.php 这样的 URL 直接调用 PHP。PHP 在此模式下只会解析已经通过了 web 服务器的重定向规则的 URL。

#### 情形三：设置 doc_root 或 user_dir
 对于前面所说无法判断是否重定向的情况，很有必要在主文档目录之外建立一个专用于脚本的 doc_root 目录。可以通过配置文件内的 doc_root 或设置环境变量 PHP_DOCUMENT_ROOT 来定义 PHP 脚本主目录。如果设置了该项，那么 PHP 就只会解释 doc_root 目录下的文件，并确保目录外的脚本不会被 PHP 解释器执行。

另一个可用的选项就是 user_dir。当 user_dir 没有设置的时候，doc_root 就是唯一能控制在哪里打开文件的选项。如果设置了 user_dir，例如 public_php，那么像 http://my.host/~user/doc.php 这样的请求将会执行用户主目录下的 public_php 子目录下的 doc.php 文件。user_dir 的设置与 doc_root 无关，所以可以分别控制 PHP 脚本的主目录和用户目录。

#### 情形四：PHP 解释器放在 web 目录以外
 一个非常安全的做法就是把 PHP 解释器放在 web 目录外的地方，比如说 /usr/local/bin。这样做唯一不便的地方就是必须在每一个包含 PHP 代码的文件的第一行加入如下语句：#!/usr/local/bin/php

## 2、以 Apache 模块安装时
一个常犯的对安全性不利的错误就是让 Apache 拥有 root 权限，或者通过其它途径斌予 Apache 更强大的功能。
把 Apache 用户的权限提升为 root 是极度危险的做法，而且可能会危及到整个系统的安全。所以除非是安全专家，否则决不要考虑使用 su，chroot 或者以 root 权限运行。
除此之外还有一些比较简单的解决方案。比如说可以使用 open_basedir 来限制哪些目录可以被 PHP 使用。也可以设置 Apache 的专属区域，从而把所有的 web 活动都限制到非用户和非系统文件之中。

## 3、文件系统安全
PHP 被设计为以用户级别来访问文件系统，所以完全有可能通过编写一段 PHP 代码来读取系统文件如 /etc/passwd，更改网络连接以及发送大量打印任务等等。因此必须确保 PHP 代码读取和写入的是合适的文件

## 4、数据库安全
- 设计数据库
- 连接数据库
- 加密存储模型
- SQL 注入

## 5、错误报告
攻击系统时经常使用的手法就是输入不正确的数据，然后查看错误提示的类型及上下文。这样做有利于攻击者收集服务器的信息以便寻找弱点。

很多 PHP 开发者会使用 show_source()、highlight_string() 或者 highlight_file() 函数来调试代码，但是在正式运行的网站中，这种做法可能会暴露出隐藏的变量、未检查的语法和其它的可能危及系统安全的信息。在运行一些具有内部调试处理的程序，或者使用通用调试技术是很危险的。如果让攻击者确定了程序是使用了哪种具体的调试技术，他们会尝试发送变量来打开调试功能。

一个函数错误就可能暴露系统正在使用的数据库，或者为攻击者提供有关网页、程序或设计方面的有用信息。攻击者往往会顺藤摸瓜地找到开放的数据库端口，以及页面上某些 bug 或弱点等。一个文件系统或者 PHP 的错误就会暴露 web 服务器具有什么权限，以及文件在服务器上的组织结构。开发者自己写的错误代码会加剧此问题，导致泄漏了原本隐藏的信息。

有三个常用的办法处理这些问题。第一个是彻底地检查所有函数，并尝试弥补大多数错误。第二个是对在线系统彻底关闭错误报告。第三个是使用 PHP 自定义的错误处理函数创建自己的错误处理机制。根据不同的安全策略，三种方法可能都适用

## 6、使用 Register Globals
当 register_globals 打开以后，各种变量都被注入代码，例如来自 HTML 表单的请求变量。再加上 PHP 在使用变量之前是无需进行初始化的，这就使得更容易写出不安全的代码。这是个很艰难的抉择，但 PHP 社区还是决定默认关闭此选项。当打开时，人们使用变量时确实不知道变量是哪里来的，只能想当然。但是 register_globals 的关闭改变了这种代码内部变量和客户端发送的变量混杂在一起的糟糕情况。

## 7、用户提交的数据
很多 PHP 程序所存在的重大弱点并不是 PHP 语言本身的问题，而是编程者的安全意识不高而导致的。因此，必须时时注意每一段代码可能存在的问题，去发现非正确数据提交时可能造成的影响。 
必须时常留意你的代码，以确保每一个从客户端提交的变量都经过适当的检查，然后问自己以下一些问题：

- 此脚本是否只能影响所预期的文件？ 
- 非正常的数据被提交后能否产生作用？ 
- 此脚本能用于计划外的用途吗？ 
- 此脚本能否和其它脚本结合起来做坏事？ 
- 是否所有的事务都被充分记录了？

在写代码的时候问自己这些问题，否则以后可能要为了增加安全性而重写代码了。注意了这些问题的话，也许还不完全能保证系统的安全，但是至少可以提高安全性。 
还可以考虑关闭 register_globals，magic_quotes 或者其它使编程更方便但会使某个变量的合法性，来源和其值被搞乱的设置。在开发时，可以使用 error_reporting(E_ALL) 模式帮助检查变量使用前是否有被检查或被初始化，这样就可以防止某些非正常的数据的挠乱了。

## 8、魔术引号
#### 8.1  什么是魔术引号
 当打开时，所有的 '（单引号），"（双引号），\（反斜线）和 NULL 字符都会被自动加上一个反斜线进行转义。这和 addslashes() 作用完全相同。

一共有三个魔术引号指令：
-** magic_quotes_gpc** 影响到 HTTP 请求数据（GET，POST 和 COOKIE）。不能在运行时改变。在 PHP 中默认值为 on。 
- **magic_quotes_runtime **如果打开的话，大部份从外部来源取得数据并返回的函数，包括从数据库和文本文件，所返回的数据都会被反斜线转义。该选项可在运行的时改变，在 PHP 中的默认值为 off。 
-** magic_quotes_sybase **如果打开的话，将会使用单引号对单引号进行转义而非反斜线。此选项会完全覆盖 magic_quotes_gpc。如果同时打开两个选项的话，单引号将会被转义成 ''。而双引号、反斜线 和 NULL 字符将不会进行转义。

#### 8.2  为什么要用魔术引号
没有理由再使用魔术引号，因为它不再是 PHP 支持的一部分。 不过它帮助了新手在不知不觉中写出了更好（更安全）的代码。 但是在处理代码的时候，最好是更改你的代码而不是依赖于魔术引号的开启。 为什么这个功能存在？是为了阻止SQL 注入。

#### 8.3  为什么不用魔术引号
- 可移植性。编程时认为其打开或并闭都会影响到移植性。可以用get_magic_quotes_gpc() 来检查是否打开，并据此编程。
- 性能。由于并不是每一段被转义的数据都要插入数据库的，如果所有进入 PHP 的数据都被转义的话，那么会对程序的执行效率产生一定的影响。在运行时调用转义函数（如 addslashes()）更有效率。 尽管 php.ini-dist 默认打开了这个选项，但是 php.ini-recommended 默认却关闭了它，主要是出于性能的考虑。
- 不便。由于不是所有数据都需要转义，在不需要转义的地方看到转义的数据就很烦。比如说通过表单发送邮件，结果看到一大堆的 \'。针对这个问题，可以使用 stripslashes() 函数处理。

#### 8.4 关闭魔术引号
magic_quotes_gpc 指令只能在系统级关闭，不能在运行时。也就是说不能用 ini_set()。 
如果不能修改服务器端的配置文件，使用 .htaccess 也可以。范例如下：php_flag magic_quotes_gpc Off

## 9、隐藏 PHP
一般而言，通过隐藏的手段提高安全性被认为是作用不大的做法。但某些情况下，尽可能的多增加一份安全性都是值得的。
一些简单的方法可以帮助隐藏 PHP，这样做可以提高攻击者发现系统弱点的难度。在 php.ini 文件里设置 expose_php = off ，可以减少他们能获得的有用信息。
另一个策略就是让 web 服务器用 PHP 解析不同扩展名。无论是通过 .htaccess 文件还是 Apache 的配置文件，都可以设置能误导攻击者的文件扩展名

## 10、保持更新

顶部

PHP基础

目录

相关推荐