0

就在最近，我们的客户让渗透测试公司对他们的网站进行了测试，并在报告中指出，在某些领域可能会以某种形式执行 SQL 注入。他们只说明数据库服务器版本和他们找到的一些表。

我试图在该字段上执行 SQL 注入，但我无法获得相关结果。我猜该字段上的 SQL 注入问题是：

  • 字段由 AJAX 验证模糊
  • 字段具有 JS 验证，输入只能是数字（任何其他字符都被剥离）
  • 该字段的 AJAX 验证使用 SQL 询问数据库是否可以找到该值，如果是则返回 1，否则返回 false（简单SELECT 1 FROM table WHERE column = '{$value}'）
  • 然后验证方法返回 true 或错误消息，并以 JSON 格式返回到表单

由于这一切，我不知道如何执行会返回一些数据的 SQL 注入...我知道我可以执行插入、更新、删除查询，所以确实存在 SQL 注入，但是如何从 select 中检索一些数据使用该字段及其验证方法查询？？？

大家好！ 我不是在问“是否有任何 SQL 注入？” 或“SQL 注入是一件坏事吗？” -我知道有 SQL 注入，我知道它非常糟糕，但我的问题是我如何执行 SQL 注入，以便在您知道上述条件的情况下检索任何数据......

楼下那些评论都没用。。。

4

2 回答 2

4

It's clear that:

  1. You aren't using the prepared statements feature that the OCI8 PHP extension provides (otherwise, you'd have column = :value instead of column = '{$value}')

  2. Your validation is client-side, thus can be easily overridden.

So you do have a SQL injection vulnerability. Now, that doesn't mean that we can necessarily steal your passwords or credit card numbers. The minimum effect is that parameters provided by user can make you app crash and that's bad enough.

About the precise potential of this injection, it's hard to say without even knowing what the app does. Usual possibilities include:

  • Retrieve rows you're not supposed to see
  • Inject data manipulation statements

Update:

Without seeing what your PHP code does:

$value = "' UNION ALL SELECT credit_card FROM billing_info -- ";
于 2012-11-15T11:50:36.490 回答
2

一旦发现漏洞，可能需要时间来设计一种方法来完全控制您的数据库，特别是如果攻击方必须欺骗/重写客户端代码以与您易受攻击的服务器端验证兼容。这也可能不是安全任务的一部分：它的实际目标是发现漏洞，而不是利用它们。

因此，在这里花费资源是毫无意义的，主要是你有一个漏洞，你必须纠正它。即使安全团队无法利用它，它也不能证明任何事情：一个更有经验和/或更积极的不法分子团队当然可以利用它。特别是，有一些工具可以在发现 SQL 注入漏洞后自动执行利用该漏洞的过程。

不要花太多时间试图理解客户端更改的微妙之处：最重要的部分是强大的服务器端验证。

也使用准备好的语句，问题解决了。

于 2012-11-15T12:20:57.273 回答