4 ms·

Rather than drag the lawyers into this, (just more paperwork)why don't we look at it from the perspective of the tools we are using? For SQL injection, what sto

Rather than drag the lawyers into this, (just more paperwork)why don't we look at it from the perspective of the tools we are using? For SQL injection, what stops databases from building an input scrubber that sits between the database and user input and scrubs input to block SQL injection? Or for that matter, why don't we see languages and frameworks used for web development touting the fact they include robust security that's easy to use? Part of it is culture, we actually have to care about security and part of it is ease of security. If we build tools that make it easier to create a (more) secure environment and push it by default, we can at least make improving security easier.

tptacek 15y ago
Nothing stops them from doing that. But they don't. Now what? See, we're back at the premise of the article.
- floppydisk 15y ago
  Partially because there hasn't been user demand for it to date. Such a change will require the programming community to start clamoring for tools to make things secure. We want speed, easy to use syntax, things like that.
  - ZoFreX 15y ago
    You'd be hard pushed to find a framework or language that didn't have, and recommend, ways to access a database that guarantee injection can't happen. If people choose not to use them, there's not a whole lot you can do. That's just a small part of the puzzle, though, and not every security issue would or could be fixed by solutions of that nature. There is no fix, other than developers being informed, capable, and diligent.
- HeyLaughingBoy 15y ago
  It's been a while coming, but this isn't surprising. Years ago, Nancy Leveson predicted that failures in software systems would lead to quality improvements through lawsuits and legislation, similar to what happened in the early 19th century with steam boilers; http://sunnyday.mit.edu/steam.pdf http://sunnyday.mit.edu/steam.pdf It's just a matter of enough of the right people being pissed off, and software is going to find itself more subject to contract laws (click through EULAs won't cut it) and liability.
dangrossman 15y ago
I think you just described PHP's old magic quotes feature, which automatically escaped all user input to, among other things, block SQL injection. It's universally reviled as one of PHP's worst design decisions and is no longer part of the default feature set.
- jquery 15y ago
  Because it escaped input too early (and did not fully escape), not because auto escaping sql is a bad idea.

tptacek 15y ago

Nothing stops them from doing that. But they don't. Now what? See, we're back at the premise of the article.

floppydisk 15y ago
Partially because there hasn't been user demand for it to date. Such a change will require the programming community to start clamoring for tools to make things secure. We want speed, easy to use syntax, things like that.
- ZoFreX 15y ago
  You'd be hard pushed to find a framework or language that didn't have, and recommend, ways to access a database that guarantee injection can't happen. If people choose not to use them, there's not a whole lot you can do. That's just a small part of the puzzle, though, and not every security issue would or could be fixed by solutions of that nature. There is no fix, other than developers being informed, capable, and diligent.
HeyLaughingBoy 15y ago
It's been a while coming, but this isn't surprising. Years ago, Nancy Leveson predicted that failures in software systems would lead to quality improvements through lawsuits and legislation, similar to what happened in the early 19th century with steam boilers; http://sunnyday.mit.edu/steam.pdf http://sunnyday.mit.edu/steam.pdf It's just a matter of enough of the right people being pissed off, and software is going to find itself more subject to contract laws (click through EULAs won't cut it) and liability.

dangrossman 15y ago

I think you just described PHP's old magic quotes feature, which automatically escaped all user input to, among other things, block SQL injection. It's universally reviled as one of PHP's worst design decisions and is no longer part of the default feature set.

jquery 15y ago
Because it escaped input too early (and did not fully escape), not because auto escaping sql is a bad idea.