在ajax中返回php异常消息是否安全答案

【问题标题】：Is it secure to return php exception message in ajax在ajax中返回php异常消息是否安全
【发布时间】：2013-01-17 10:43:27
【问题描述】：

我们在项目中抛出的异常包含存储过程和类的名称。有时它们包含表的名称，但我们应该捕获任何其他关键信息。在 ajax 中处理异常的防弹方法是仅使用 ajax 发送错误代码，但是作为程序员，如果您在 ajax 中传递消息（它们可能通过网络面板可见），则调试和维护代码要容易得多)。

在大型项目中这方面的最佳做法是什么？

【问题讨论】：

沙盒环境。 = 发送消息，生产 = 您可以将其登录到文件中
在开发系统上，确保：让开发人员轻松。这就是重点。但是在生产系统上，没有。不要让开发者容易，因为黑客也是开发者。设置很容易，以便开发系统显示原始错误而产品系统不显示。
顺便说一句 - 为了增加 Dev 的魅力，你应该看看 FirePHP，它可以让你从你的 PHP 代码直接发送消息到浏览器的控制台。转移到生产时也需要关闭，但非常适合开发工作。
酷！我们需要使用它的主要时间是用于异常（而不是在编写代码时进行调试），这就是问题所在，因为人们正在对我们的测试服务器 + 生产进行 QA，当那里发生异常时，能够检查真的很有帮助异常消息的网络选项卡。

【解决方案1】：

不幸的是，没有 DEBUG 语句。看here 尽管讨论了如何实施项目范围的解决方案来区分代码中的 DEBUG 和 PRODUCTION，但事实是，您应该兼顾性能（查看 here）和安全性。

攻击者肯定希望获得有关您的数据库和实施实践的一些信息。表名和字段将为他提供例如他需要在 UNION sql 注入查询中使用的字段数。

【讨论】：

在这种情况下更大的问题不是有人可以首先进行SQL注入吗？
当然可以，但是不管你做什么，sql注入永远是个问题。但是，并不总能找到现有的注入点。那里的许多漏洞利用需要表具有的列数或一些此类信息。看看 sqlmap 工具的执行，它的选项，你会发现大多数迭代都是相同的 sql 注入技术，但选项不同。另外，您永远不应该放弃您正在使用的 dbms 技术或任何其他技术。大多数攻击始于谷歌搜索特定技术的漏洞。