在错误消息中公开SQL模式有哪些安全风险?

时间:2013-08-24 15:38:05

标签: sql security sql-injection database-schema code-injection

有一个Web应用程序可以捕获服务器错误并将其报告给管理员,以便解决错误。这些错误是在较低级别,守护进程等中发生的事情的结果。远离网络层。有时,失败的SQL语句会冒泡到错误页面,从而暴露出一定数量的数据库模式。

报告页面的URI与公开的错误之间没有相关性。如果我理解正确,我认为这意味着可以避免SQL注入的问题,因为没有注入的Web路径,但想要确认。

可以访问这些报告的用户也可以登录到服务器本身并访问相关数据库,因此如果我们真的想知道架构是什么,我们就有办法查看它。

在这种情况下是否存在安全风险?

3 个答案:

答案 0 :(得分:1)

我认为接受的做法是将错误消息记录到一个中心位置(可能是数据库),并有一个例程来清理向用户显示的消息,以确保不共享敏感信息。

坏人可以使用有关系统的知识来进行恶意目的,例如SQL注入攻击,拒绝服务器攻击等。

https://www.securecoding.cert.org/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive+information

答案 1 :(得分:0)

简短的回答是,没有理由将SQL错误暴露给用户,特别是如果这是Web应用程序前面的业务用户。这就是我们“抓住”和“抛出”的原因。内部异常只应在调试期间冒泡。否则,它应该保存在日志中。

通常,我们应该监控日志。如果您宁愿等待客户投诉(由于人员限制),您当然可以附上您“抛出”与您的日志相关的跟踪号码的消息,以说明问题的性质。

如果你在“我们都是这里的朋友”环境中工作,那么应该没有问题可能通过错误消息暴露架构。但是你对安全的担忧已经表明事实并非如此。

答案 2 :(得分:0)

首先,回答你的问题。

始终存在安全风险。攻击者有没有无用的数据。即使一个人无法在盘子上为你提供某种攻击场景,但这并不意味着没有风险。

接下来,关于在Web前端显示系统错误消息的想法。

正如其他人已经说过的那样,一般来说这是一个非常糟糕的主意。无辜的用户不必看到这些技术细节,只能看到通用的错误页面。向网络访问者显示详细信息是一个错误。错误最好修复。修复bug是一种更好的方案,而不是在Stack Overflow上询问这个bug是否关键。