SQL injection isn't dead, because I stumble upon a sql injection vulnerability every other day as a part of my job.
cqqxo4zV46cp 14 days ago [-]
Django got hit with an SQL injection vulnerability just the other day. I basically fell out of my chair when I saw it.
plugger 14 days ago [-]
Can confirm. My last good finding was a unauthed and blind SQLi.
29athrowaway 15 days ago [-]
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.
colimbarna 13 days ago [-]
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.
They do eventually, but it usually takes at least a couple months if not more.
seeknotfind 15 days ago [-]
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
fulafel 15 days ago [-]
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?)
avery17 15 days ago [-]
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.
crooked-v 15 days ago [-]
Web dev land has a borderline pathological obsession with NEW NEW NEW, which contributes to much of it.
jakubmazanec 15 days ago [-]
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).
barryrandall 15 days ago [-]
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.
jiggawatts 14 days ago [-]
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.
barryrandall 14 days ago [-]
That doesn’t stop businesses from falling for the sales pitch.
bigiain 13 days ago [-]
Or auditors from ticking that box.
yencabulator 13 days ago [-]
It's request smuggling, not a buffer overflow.
Ekaros 14 days ago [-]
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.
14 days ago [-]
TedDallas 14 days ago [-]
I’m seriously thinking about getting a custom made bumper sticker with the following text: ‘; select 1/0;
> 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.
root_axis 14 days ago [-]
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.
Stefan-H 15 days ago [-]
What part of that do you interpret as trusting the client?
CodeWriter23 15 days ago [-]
> Paul points out that alternative paths such as WebSockets might bypass limits that are in place for regular HTTP requests <
zbentley 15 days ago [-]
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.
echoangle 14 days ago [-]
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.
Sohcahtoa82 14 days ago [-]
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.
cma 15 days ago [-]
He says it's more difficult than you might expect not to.
CodeWriter23 15 days ago [-]
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.
Rendered at 10:07:08 GMT+0000 (Coordinated Universal Time) with Vercel.
SQL injection isn't dead, because I stumble upon a sql injection vulnerability every other day as a part of my job.
Anyone know if DEF CON publish videos of this kind of session?
https://www.youtube.com/@DEFCONConference
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
(A case could be made for calling it a buffer underflow maybe?)
You can’t use a dumb appliance to fix developer stupidity.
So it is complex field and there is always more vectors like this.
Interesting...a security researcher that thinks it's ok to trust the client.
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.