SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level | Hacker News Reader

SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level

simonwillison.net

112 pointsulrischa31 comments

>Topic

SQL injection isn't dead, because I stumble upon a sql injection vulnerability every other day as a part of my job.

Can confirm. My last good finding was a unauthed and blind SQLi.

Django got hit with an SQL injection vulnerability just the other day. I basically fell out of my chair when I saw it.

I do not like the term SQL injection nowadays. I think it must be generalized to query injection. It makes people believe that NoSQL somehow is exempt from such problems.

I agree, I also dislike the term SQL injection. But the problem isn't that there is a query, there problem is that the source code of one program is constructed by string manipulation in the source code of another program. XSS issues (where javascript can be embedded into a string that is supposed to be a value in a HTML document) are the same. Also occurs with shell scripts. The goal has to be to avoid such manual processes. Between lower level languages, it's customary to export a function call in a standard ABI. It should also be the same here: regard queries as function calls in a foreign language. Javascript is basically there, but query languages only have fits and starts (e.g. you often have some syntax like `SELECT * FROM "tbl" where "field" = ?` which can then accept the parameter in a form that is intended for transferring user values) and generally rely on good hygiene and ORMs to protect the end user.

The full slides for the presentation (PDF) are here: https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20pre...

Anyone know if DEF CON publish videos of this kind of session?

They do eventually, but it usually takes at least a couple months if not more.

Yes, they'll publish them on their YouTube channel, usually a couple weeks after the convention.

https://www.youtube.com/@DEFCONConference

Well this is a buffer overflow attack, not injection, but hey, it's in a SQL program!

Though SQL injection and other injection attacks are definitely not dead. All it takes is one programmer mistake and poof! Lots of XSS rely on accidentally injection of some value. Also hey lots of LLM based attacks are injection. Injection is not dead... oh no oh no

I always thought the internet would get more sophisticated and secure as time went on and my days of SQL injection were limited to my teenage years but it seems as the internet becomes more accessible the number of armature developers putting insecure websites up in rising raidly.

Web dev land has a borderline pathological obsession with NEW NEW NEW, which contributes to much of it.

That's not the reason why web development is in its current state (not bad, actually). The reason is simple: it is difficult and therefore costly to make good and secure web app, and their owners are not willing to spend money/energy on this. Actually I would argue the speed of changes in web development is useful, because it lowers this cost. HN folks love to hate on e.g. Next.js and Vercel, but there's a reason they're so popular (though you should still spend much more resources on UX and security than average Next.js dev does).

A lot of companies with SQL injection vulnerabilities remediated them by buying security appliances advertised to stop SQL injection attacks. That works for a while until time and turnover result in someone optimizing the appliance out of the stack. Then the cycle repeats.

Those things are digital snake oil. If you turn on the web application firewall (WAF) features your app breaks. If you “tune” it to fix that, you let the attackers back through.

You can’t use a dumb appliance to fix developer stupidity.

That doesn’t stop businesses from falling for the sales pitch.

Or auditors from ticking that box.

No, it's a desync by integer overflow, there's no overflowing buffer. Due to the incorrect length field, the db server starts parsing the next db protocol message from the middle of attacker-supplied data which gives the attacker control of db commands.

(A case could be made for calling it a buffer underflow maybe?)

It's request smuggling, not a buffer overflow.

Also I get the feeling lot of instruction on topic like SQL Injection is just incorrect or not even best practise anymore. And it keeps being parroted. Like recommending input sanitization. It can be part of solution and probably should consider what to accept on any input. But it is not full or even efficient solution, specially when often it is implemented incorrectly or imperfectly...

So it is complex field and there is always more vectors like this.

I’m seriously thinking about getting a custom made bumper sticker with the following text: ‘; select 1/0;

https://hackaday.com/wp-content/uploads/2014/04/18mpenleoksq...

Very smart!

> The current way to protect against these attacks is to ensure a size limit on incoming requests. This can be more difficult than you may expect - Paul points out that alternative paths such as WebSockets might bypass limits that are in place for regular HTTP requests, plus some servers may apply limits before decompression, allowing an attacker to send a compressed payload that is larger than the configured limit.

Interesting...a security researcher that thinks it's ok to trust the client.

He says it's more difficult than you might expect not to.

I think that's an artifact of the problem statement. For example, "length check while receiving or in the process of decompressing" eliminates things like websockets from the equation entirely.

What part of that do you interpret as trusting the client?

> Paul points out that alternative paths such as WebSockets might bypass limits that are in place for regular HTTP requests <

I'm not sure I interpret that as trusting the client; rather, it seems like the implication is that HTTP limits will be handled correctly by webserver harnesses, whereas WebSockets may not get any such behavior "for free" from the server framework.

He’s saying that some Webservers allow you to limit request size, but the limits you set might only apply to HTTP(S) and can be circumvented when using another protocol. That’s a server side problem.

Is English not your first language? If it is, I am utterly baffled as how you think that's an endorsement trusting the client, rather than merely a description.

He's saying the opposite.

His point is that adding in a request limit in your server config may not be enough because protocols like websocket might not inherit those size restrictions automatically due to specialized logic for implementing sockets over http.

Reply on news.ycombinator.com