mirror of
https://github.com/php/doc-zh.git
synced 2026-03-24 07:02:15 +01:00
110 lines
5.4 KiB
XML
110 lines
5.4 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<!-- $Revision$ -->
|
||
<!-- EN-Revision: ae725a44023db78b9f6e9d2a0baac8c8dc337d38 Maintainer: lm92 Status: ready -->
|
||
<!-- CREDITS: dallas, mowangjuanzi -->
|
||
<chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
|
||
<title>错误报告</title>
|
||
<para>
|
||
对于 PHP 的安全性来说错误报告是一把双刃剑。一方面可以提高安全性，另一方面又有害。
|
||
</para>
|
||
<para>
|
||
攻击系统时经常使用的手法就是输入不正确的数据，然后查看错误提示的类型及上下文。这样做有利于攻击者收集服务器的信息以便寻找弱点。比如说，如果一个攻击者知道了一个页面所基于的表单信息，那么他就会尝试修改变量：
|
||
<example>
|
||
<title>用自定义的 HTML 页面攻击变量</title>
|
||
<programlisting role="html">
|
||
<![CDATA[
|
||
<form method="post" action="attacktarget?username=badfoo&password=badfoo">
|
||
<input type="hidden" name="username" value="badfoo" />
|
||
<input type="hidden" name="password" value="badfoo" />
|
||
</form>
|
||
]]>
|
||
</programlisting>
|
||
</example>
|
||
</para>
|
||
<para>
|
||
通常 PHP
|
||
所返回的错误提示都能帮助开发者调试程序，它会提出哪个文件的哪些函数或代码出错，并指出错误发生的在文件的第几行，这些就是
|
||
PHP 本身所能给出的信息。很多 PHP 开发者会使用
|
||
<function>show_source</function>、<function>highlight_string</function>
|
||
或者 <function>highlight_file</function>
|
||
函数来调试代码，但是在正式运行的网站中，这种做法可能会暴露出隐藏的变量、未检查的语法和其它的可能危及系统安全的信息。在运行一些具有内部调试处理的程序，或者使用通用调试技术是很危险的。如果让攻击者确定了程序是使用了哪种具体的调试技术，他们会尝试发送变量来打开调试功能：
|
||
<example>
|
||
<title>利用变量打开调试功能</title>
|
||
<programlisting role="html">
|
||
<![CDATA[
|
||
<form method="post" action="attacktarget?errors=Y&showerrors=1&debug=1">
|
||
<input type="hidden" name="errors" value="Y" />
|
||
<input type="hidden" name="showerrors" value="1" />
|
||
<input type="hidden" name="debug" value="1" />
|
||
</form>
|
||
]]>
|
||
</programlisting>
|
||
</example>
|
||
</para>
|
||
<para>
|
||
不管错误处理机制如何，可以探测系统错误的能力会给攻击者提供更多信息。
|
||
</para>
|
||
<para>
|
||
比如说，PHP 的独有的错误提示风格可以说明系统在运行 PHP。如果攻击者在寻找一个 <literal>.html</literal>
|
||
页面，想知道其后台的技术（为了寻找系统弱点），他们就会把错误的数据提交上去，然后就可以得知系统是基于
|
||
PHP 的了。
|
||
</para>
|
||
<para>
|
||
一个函数错误就可能暴露系统正在使用的数据库，或者为攻击者提供有关网页、程序或设计方面的有用信息。攻击者往往会顺藤摸瓜地找到开放的数据库端口，以及页面上某些 bug
|
||
或弱点等。比如说，攻击者可以一些不正常的数据使程序出错，来探测脚本中认证的顺序（通过错误提示的行号数字）以及脚本中其它位置可能泄露的信息。
|
||
</para>
|
||
<para>
|
||
一个文件系统或者 PHP 的错误就会暴露 web
|
||
服务器具有什么权限，以及文件在服务器上的组织结构。开发者自己写的错误代码会加剧此问题，导致泄漏了原本隐藏的信息。
|
||
</para>
|
||
<para>
|
||
有三个常用的办法处理这些问题。第一个是彻底地检查所有函数，并尝试弥补大多数错误。第二个是对在线系统彻底关闭错误报告。第三个是使用
|
||
PHP 自定义的错误处理函数创建自己的错误处理机制。根据不同的安全策略，三种方法可能都适用。
|
||
</para>
|
||
<para>
|
||
一个能提前阻止这个问题发生的方法就是利用
|
||
<function>error_reporting</function> 来帮助使代码更安全并发现变量使用的危险之处。在发布程序之前，先打开
|
||
<constant>E_ALL</constant> 测试代码，可以帮你很快找到变量使用不当的地方。一旦准备正式发布，就应该把
|
||
<function>error_reporting</function> 的参数设为 0 来彻底关闭错误报告或者把 &php.ini;
|
||
中的 <literal>display_errors</literal> 设为 off
|
||
来关闭所有的错误显示以将代码隔绝于探测。当然，如果要迟一些再这样做，就不要忘记打开 ini 文件内的
|
||
<literal>log_errors</literal> 选项，并通过 <literal>error_log</literal> 指定用于记录错误信息的文件。
|
||
<example>
|
||
<title>用 E_ALL 来查找危险的变量</title>
|
||
<programlisting role="php">
|
||
<![CDATA[
|
||
<?php
|
||
if ($username) { // Not initialized or checked before usage
|
||
$good_login = 1;
|
||
}
|
||
if ($good_login == 1) { // If above test fails, not initialized or checked before usage
|
||
readfile ("/highly/sensitive/data/index.html");
|
||
}
|
||
?>
|
||
]]>
|
||
</programlisting>
|
||
</example>
|
||
</para>
|
||
</chapter>
|
||
|
||
<!-- Keep this comment at the end of the file
|
||
Local variables:
|
||
mode: sgml
|
||
sgml-omittag:t
|
||
sgml-shorttag:t
|
||
sgml-minimize-attributes:nil
|
||
sgml-always-quote-attributes:t
|
||
sgml-indent-step:1
|
||
sgml-indent-data:t
|
||
indent-tabs-mode:nil
|
||
sgml-parent-document:nil
|
||
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
|
||
sgml-exposed-tags:nil
|
||
sgml-local-catalogs:nil
|
||
sgml-local-ecat-files:nil
|
||
End:
|
||
vim600: syn=xml fen fdm=syntax fdl=2 si
|
||
vim: et tw=78 syn=sgml
|
||
vi: ts=1 sw=1
|
||
-->
|