[HN Gopher] SQL Injection Isn't Dead: Smuggling Queries at the P...
       ___________________________________________________________________
        
       SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level
        
       Author : ulrischa
       Score  : 74 points
       Date   : 2024-08-12 18:52 UTC (1 days ago)
        
 (HTM) web link (simonwillison.net)
 (TXT) w3m dump (simonwillison.net)
        
       | seeknotfind wrote:
       | 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
        
         | avery17 wrote:
         | 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 wrote:
           | Web dev land has a borderline pathological obsession with NEW
           | NEW NEW, which contributes to much of it.
        
             | jakubmazanec wrote:
             | 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 wrote:
           | 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 wrote:
             | 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.
        
         | fulafel wrote:
         | 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?)
        
       | simonw wrote:
       | 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?
        
         | mmetzger wrote:
         | They do eventually, but it usually takes at least a couple
         | months if not more.
        
       | boltzmann_ wrote:
       | Very smart!
        
       | CodeWriter23 wrote:
       | > 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.
        
         | cma wrote:
         | He says it's more difficult than you might expect not to.
        
           | CodeWriter23 wrote:
           | 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.
        
         | Stefan-H wrote:
         | What part of that do you interpret as trusting the client?
        
           | CodeWriter23 wrote:
           | > Paul points out that alternative paths such as WebSockets
           | might bypass limits that are in place for regular HTTP
           | requests <
        
             | zbentley wrote:
             | 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.
        
       | 29athrowaway wrote:
       | 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.
        
       | poincaredisk wrote:
       | >Topic
       | 
       | SQL injection isn't dead, because I stumble upon a sql injection
       | vulnerability every other day as a part of my job.
        
       ___________________________________________________________________
       (page generated 2024-08-13 23:01 UTC)