缓冲区溢出SQL注入是如何发生的？

我在Penetration Testing职业生涯中遇到过许多站点,其中站点具有严格的WAF,但有时可以通过缓冲区溢出逻辑来绕过.例如,考虑一个Query

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

现在,

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

这实际上打印出Real列号,这意味着它已被Bypassed.我知道%23 =#和%0A =空格.但我不明白这是如何在幕后发挥作用的.我的意思是后端逻辑.

任何人都可以给我一个SQL结构示例,它可以导致这种类型的缓冲区溢出,考虑到后端是MYSQL的后端结构(数据类型)和$查询...

帮助将不胜感激

对此的技术解释可能不是文字缓冲区溢出.

对我来说,这看起来就像是一个打败天真过滤器的机制......它看起来像依赖外置解决方案的症状,比如某种内容检查防火墙,或者自制软件逃脱,以掩盖某人的事实不知道,不关心,或者只是懒得编写正确的代码......而是试图通过阻止脏输入来"解决"漏洞.

正如所料,这种方法经常失败.

代码要么易受攻击,要么不容易,如果是,那么应用这种"安全"机制而不是修复损坏的代码几乎是不可原谅的.这看起来像个孩子.

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

你如何终止以MySQL开头的评论#？如果你说"换行",你就赢了.

从" #"字符到行尾.

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

所以,这是一个有效的查询...

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

......有些事情似乎绕过了阻止其他查询的任何原始过滤机制,因为它用于查找可疑的任何方法都会UNION*SELECT对解析SQL做出错误的假设.

这看起来不像缓冲区溢出 - 它看起来像原始代码,表现出普通的,常见的,懒惰的SQL注入漏洞,被"原始过滤器"后面或"增强"保护.