【问题标题】:Reported error code considered SQL Injection?报告的错误代码认为是 SQL 注入?
【发布时间】:2010-06-09 11:36:55
【问题描述】:

实际运行 SQL 命令的 SQL 注入是一回事。但是注入实际上不会运行有害查询但可能会告诉您有关数据库有价值的数据的数据,这是否被视为 SQL 注入?还是只是用作构造有效 SQL 注入的一部分?

一个例子可以是

set rs = conn.execute("select headline from pressReleases 
where categoryID = " & cdbl(request("id")) )

传递一个无法转换为数值的字符串会导致

Microsoft VBScript runtime error '800a000d'
Type mismatch: 'cdbl'

这会告诉您有问题的列只接受数字数据,因此可能是整数或类似类型。

我似乎在很多讨论 SQL 注入的页面中都发现了这一点,但如果这本身被认为是 SQL 注入,我并没有真正得到答案。我的问题的原因是我有一个扫描工具报告 SQL 注入漏洞并报告 VBScript 运行时错误“800a000d”作为发现的原因。

【问题讨论】:

  • 仅仅因为您不一定知道如何构建恶意攻击向量,并不意味着其他人都不知道。在你的 sql 中使用绑定参数来消除任何注入的可能性。

标签: sql database security sql-injection


【解决方案1】:

这显然是一个SQL注入漏洞,需要修复。

在您的场景中有几个原因:

  • 找出您所描述的附带信息可能对攻击者有用,尤其是当他们有其他攻击媒介时。
  • 鼓励发现此漏洞的攻击者去寻找更多漏洞。这里的马虎可能意味着其他地方的马虎。
  • 在安全方面,不要太聪明很重要。你的攻击者可能比你知道的更多,或者更多的东西。因此,您认为包含的漏洞可能是对其他人敞开的大门。

所以是的,您的工具正在做正确的事情。

【讨论】:

  • 报告这样的发现我可以理解,因为它披露了一些最可能不应该披露的信息。但它仍然符合 SQL“注入”攻击的标准吗?使它成为 SQL 注入的官方定义是什么?这就是我想要找到的 ;)
  • SQL 注入确实被定义为用户使用特殊格式的输入执行 sql 命令的操作。由于 cdbl(),使用您的 SQL 可能无法进行注入。但正如 Phil Wallach 所说,用户有可能以我们不知道的方式执行此操作 - 所以这是一个可能发生 sql 注入的地方。因此,它不是“sql 注入”,而是“sql 注入漏洞”。 (想象一下,您有时会移除 cdbl - 注射会立即成为可能。)
  • 我不是安全专家,所以我无法给出定义。我只是认为最好避免所有可能的漏洞,即使它们不是明确危险的。
【解决方案2】:

我会说是的!您注入一个 SQL 字符串并获取您不应该获取的信息。我认为这已经够“有害”了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-04-20
    • 2019-09-02
    • 2022-01-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-11
    相关资源
    最近更新 更多