mysql - 缓冲区溢出 SQL 注入(inject)是如何发生的？

Question

在我的渗透测试生涯中，我遇到过很多站点有严格的 WAF，但有时可以被缓冲区溢出逻辑绕过。例如，考虑一个查询

http://example.com/something.php?id=-1 UNION SELECT 1,2,3,4,5,6--+ 考虑易受攻击的列直到 7 。所以现在，这应该打印一个 Vulnerable 列号作为 Output 但它得到 Error 。

现在，

http://example.com/something.php?id=-1 UNION%23AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%0aselect 1,2,3,4,5,6--+

这实际上打印出了 Real 列号，这意味着它已被绕过。我知道 %23= # 和 %0A = 空间。但我不明白这是如何在幕后运作的。我的意思是后端逻辑。

任何人都可以给我一个可能导致此类缓冲区溢出的 SQL 结构示例，考虑到后端在后端结构(数据类型)和 $query 方面也是 MYSQL ..

帮助将不胜感激

Answer 1

对此的技术解释可能不是字面上的缓冲区溢出。

对我来说，这看起来只是一种击败简单过滤器的机制......它看起来像是依赖外部解决方案的症状，例如某种内容检查防火墙或自制程序转义，以掩盖事实上，有人不知道、不关心或懒得编写正确的代码……而是试图通过阻止脏输入来“解决”漏洞。

正如所料，此类方法经常失败。

代码要么易受攻击，要么不易受攻击，如果是，那么应用此类“安全”机制而不是修复损坏的代码几乎是不可原谅的。这似乎是典型代表。

对该漏洞的解释很简单:%0A 根本不是一个空格...它是一个换行符 (\n)。

如何在 MySQL 中终止以 # 开头的注释？如果你说“换行”，你就赢了。

From a “#” character to the end of the line.

http://dev.mysql.com/doc/refman/5.7/en/comments.html

所以，这是一个单一的、有效的查询...

SELECT ... WHERE  ...  UNION #AAAAAAA...\n
SELECT ...

...这似乎绕过了阻止其他查询的任何原始过滤机制，因为它用来查找可疑 UNION*SELECT 的任何方法都对解析 SQL 做出了错误的假设。

这看起来不像是缓冲区溢出——它看起来像是展示普通的、常见的、惰性 SQL 注入(inject)漏洞的原始代码，在原始过滤器后面“保护”或由原始过滤器增强。