最终用户不应该看到您环境的血腥细节。

相反，显示一个通用的“抱歉出现问题”页面更专业。至少访问者可以看到您的网站上存在真正的错误处理机制。

但是，这些错误应该写入 mysql 错误日志，并且还应该通过电子邮件或其他方式向 IT 团队触发通知。这些错误不应该发生，因此这可能表明您的网站正在失败或可能受到攻击。

不，这绝对不安全，因为它会创建其他不存在的额外 SQL 注入攻击向量。示例：如果您在插入中有 SQL 注入流，那么这是某种“盲”注入，因为插入不会向调用者报告任何结果行。但是，如果您将潜在的插入错误消息带回客户端，那么您会使其容易受到所谓的“XPath”注入的影响（请参阅本文详情）。本质是您注入了一个 xml 函数，该函数应该计算数据类型 xml 的变量。该函数的参数之一是一个 xpath 变量，它可以再次通过 select 语句和字符串连接来计算。您不提供有效的 xpath，而是进行选择（例如“从 id='admin' 的用户中选择密码哈希”）。因此，数据库将通过您的注入执行故意错误的 INSERT。结果将是一条错误消息，例如

'bb9af55cd325deaa89bb7b4e36085b4d' 不是有效的 xpath

如果您向调用者显示此类错误消息，则可以使用它来枚举数据库。我最近看到了这种情况。错误消息被削减为 30 个字符，一次只能选择一列和一行，但仍然可以用它枚举整个数据库。

其他人正确地谈到了为什么不应通过生产服务器上网站/应用程序的主用户界面公开 MySQL 详细信息。

但是当您像这样向最终用户显示错误时，会出现一个更广泛、更高级的问题：

它基本上传达了服务器/站点管理不善的想法。

这意味着您成为黑客攻击的更成熟的目标不是因为细节的内容，而是因为细节从一开始就已经暴露。

作为应用程序开发人员（系统管理员等），您的态度是让您的最终产品能够以某种方式优雅地失败，而不会暴露系统架构的“骨骼”，但仍能以某种方式向您传达一些有用的调试数据。

如果您的应用程序设计正确，则显示错误消息文本不应该是安全问题。如果是这样，则意味着您的安全性依赖于被认为是不好的做法的混淆。

话虽如此，真正的问题是：面对这样的消息，用户体验会怎样？如果您的应用程序是为普通用户设计的，他们将收到一条消息，不会给他们带来任何有用的信息：他们要么不了解任何东西，要么无法用它做任何有用的事情。更糟糕的是，他们可能认为那些懒惰的开发人员甚至没有正确处理他们的错误——这就是我的想法……

这就是为什么常见的用法是显示一条更温和的消息，说明出现问题，如果错误仍然存​​在，请重试并联系支持人员，而不需要血淋淋的细节。仅当支持以特殊模式运行应用程序时，才应显示完整的错误消息，因为支持技术人员对错误详细信息感兴趣。

如果你真的想把错误做得最好：

• 确保记录错误及其上下文：日期时间、用户、请求参数、最终允许支持人员填写票证的关键会话数据必须在应用程序中修复
• 只向用户显示软外部信息
• 添加一种特定的支持方式，以便在他们尝试重现错误时访问所有错误详细信息 - 这是有代价的，但支持技术人员会非常感激
• 最终为事件分配一个唯一的 id 并将其显示给用户

最后一种可能性只对用户数量有限的高价值应用程序有意义。这将允许支持在用户联系他们时立即获得问题的所有参考。但这也意味着您准备好单独回答任何对于正常应用程序来说可能非常昂贵的错误。