How do Buffer Overflow SQL Injection occurs?

Question

I have encountered many Sites in my Penetration Testing career in which the Site have Strict WAF, but sometimes can be bypassed by the Logic of Buffer Overflow . For example, consider a Query

http://example.com/something.php?id=-1 UNION SELECT 1,2,3,4,5,6--+ Consider the Vulnerable columns are till 7 . So now, this should print a Vulnerable column number as Output but it gets Error .

Now,

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

This actually Prints out the Real column number, which means it has been Bypassed. I know %23= # and %0A = Space. But i do not understand how this acts behind the scenes. Which i mean Backend Logic.

Can anyone give me a Example of SQL Structure which can cause such type of Buffer Overflow, considering the Backend is MYSQL in terms of Backend Structure (Datatypes) and $query too ..

Help would be appreciated

Answer 1

The technical explanation of this is probably not a literal buffer overflow.

This, to me, looks like simply a mechanism for defeating a naive filter... It looks like a symptom of relying on outboard solutions, like some kind of content-inspecting firewall, or homebrew escaping, to cover up for the fact that someone doesn't know, doesn't care, or is just too lazy to write correct code... and is instead trying to "solve" the vulnerability by blocking dirty input.

Such approaches often fail, as should be expected.

Code is either vulnerable or it isn't, and if it is, then applying such "security" mechanisms instead of fixing the broken code is pretty much inexcusable. This seems like a poster child.

The explanation of the vulnerability is simple: %0A isn't a space at all... It's a newline (\n).

How do you terminate a comment in MySQL that begins with #? If you said "a newline," you win.

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

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

So, this is a single, valid query...

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

...and something about this appears to bypass whatever primitive filtering mechanism is blocking the other query, because whatever means it uses to find a suspicious UNION*SELECT makes an incorrect assumption about parsing SQL.

This doesn't look like a buffer overflow -- it looks like primitive code exhibiting ordinary, common, lazy SQL injection vulnerabilities, "protected" behind or augmented by a primitive filter.