3 ms·

One of the hats I wear these days is looking through source code for security vulnerabilities. It's shocking how many SQL injection vulnerabilities I find in ne

One of the hats I wear these days is looking through source code for security vulnerabilities. It's shocking how many SQL injection vulnerabilities I find in newly written code. I remember first reading about SQL injection back in the 90s and yet developers are still making that very basic mistake. It is also a bit scary how many of the code analysist tools miss intentional flaws I've added to the code to test the scanner. These aren't ancient lint checkers, they're ridiculously priced enterprise tools. It worries me that they're giving a false sense of security that is going to get lots of implementations burned.

mgkimsal 6y ago
>These aren't ancient lint checkers, they're ridiculously priced enterprise tools. It worries me that they're giving a false sense of security that is going to get lots of implementations burned. But no one is going to get fired or held back for choosing those 'enterprise' tools. They've spent a lot of money, everyone has a checklist, and people move on, even if there's a breach. And some jr might have pointed out "hey, this open source toolset does this, but is kept up to date and has found 47 things our scanner didn't find" and this jr will likely be ignored.
- sokoloff 6y ago
  “Well with open source tools, you pay with time and we prefer this gold-plated, Cadillac, enterprise-grade tool. We’re a serious company now, after all.” It’s maddening.
greggman3 6y ago
I'd argue it's bad API design. You can't make an API that's easy to use wrong and insecurely and then be surprised that people use it wrong and insecurely.
- 0xFluegel 6y ago
  I can only half agree with you on that. Yes, I also dislike APIs that make wrong or unsafe use easy and correct use more bothersome but seemingly no different in behaviour (until it goes BOOM), but I also find that soooo many people simply don't have the awareness that they are interfacing with another system that interprets their data in a potentially unsafe way. And these people will misuse any API like this.
  - larssorenson 6y ago
    Unfortunately short of forcing everyone to use an ORM I don't see how we can block the unsafe API, which I'm assuming to be the string-based query interface e.g. `conn.query("SELECT * FROM users")` since any interface that accepts a string will allow a dynamically constructed string which lets developers open themselves to injection attacks. Only ORMs AFAIK can prevent this, e.g. db().users.all() or db().users.select(name="bob"). Maybe there's a clever trick I'm missing here.
    - aaronmdjones 6y ago
      It'd be nice if the languages offered a way for the query-compiling function to require that the query strings given to it are static, compile-time strings.

mgkimsal 6y ago

>These aren't ancient lint checkers, they're ridiculously priced enterprise tools. It worries me that they're giving a false sense of security that is going to get lots of implementations burned. But no one is going to get fired or held back for choosing those 'enterprise' tools. They've spent a lot of money, everyone has a checklist, and people move on, even if there's a breach. And some jr might have pointed out "hey, this open source toolset does this, but is kept up to date and has found 47 things our scanner didn't find" and this jr will likely be ignored.

sokoloff 6y ago
“Well with open source tools, you pay with time and we prefer this gold-plated, Cadillac, enterprise-grade tool. We’re a serious company now, after all.” It’s maddening.

greggman3 6y ago

I'd argue it's bad API design. You can't make an API that's easy to use wrong and insecurely and then be surprised that people use it wrong and insecurely.

0xFluegel 6y ago
I can only half agree with you on that. Yes, I also dislike APIs that make wrong or unsafe use easy and correct use more bothersome but seemingly no different in behaviour (until it goes BOOM), but I also find that soooo many people simply don't have the awareness that they are interfacing with another system that interprets their data in a potentially unsafe way. And these people will misuse any API like this.
- larssorenson 6y ago
  Unfortunately short of forcing everyone to use an ORM I don't see how we can block the unsafe API, which I'm assuming to be the string-based query interface e.g. `conn.query("SELECT * FROM users")` since any interface that accepts a string will allow a dynamically constructed string which lets developers open themselves to injection attacks. Only ORMs AFAIK can prevent this, e.g. db().users.all() or db().users.select(name="bob"). Maybe there's a clever trick I'm missing here.
  - aaronmdjones 6y ago
    It'd be nice if the languages offered a way for the query-compiling function to require that the query strings given to it are static, compile-time strings.