4 ms·

I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SE

by Skalman 16y ago

I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SELECT * FROM mytable WHERE name = ?', name) (I'm aware that this defeats the purpose of prepared statements to be reusable - this is just an API that's better than the current methods)

tptacek 16y ago
This is the second time in a few days someone has made the point that web stacks make it hard to use prepared statements†. This is a one-liner in Rails. Does it not work in Python? How hard is it in PHP? † Which are not a cure-all for SQLI.
- T-hawk 16y ago
  I think the problem angle is slightly different: it's too easy to use simple string concatenation for SQL. That works across pretty much every web stack, so it's the path of least resistance to get something working, and many a developer never bothers to learn the proper idiom anew for every framework. Side note: We're jumping to conclusions by thinking that the javascript is the entire implementation. It's perfectly possible that the server is already safe against SQL injection and the javascript is just an extra line of defense. Maybe the client and server were done by separate programmers and the client programmer wanted to make sure he wouldn't get blamed. It's a government website: nobody in government ever got fired for being too careful. Or maybe the programmer had to do it to satisfy some non-technical bureaucrat who wanted to think that hacking attempts couldn't even reach his server.
- timwiseman 16y ago
  I wrote fairly recently about SQL Injection in Python at http://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/ http://www.simple-talk.com/sql/learn-sql-server/sql-injectio... . I do not address web stacks directly there, but Python itself will happily let you use prepared statements, it is up to the programmer to take effective steps to prevent SQL Injection.
- cosmok 16y ago
  Very easy in PHP. http://php.net/manual/en/pdo.prepared-statements.php http://php.net/manual/en/pdo.prepared-statements.php
  - damncabbage 16y ago
    Except when the database drivers PDO relies on aren't set up by default: http://news.ycombinator.com/item?id=2376873 http://news.ycombinator.com/item?id=2376873
moe 16y ago
it's just that every language makes it so difficult to use prepared statements Huh? Most web frameworks use ORMs and discourage you from touching SQL at all.
- graywh 16y ago
  Which is great until you discover that your needs can't be fulfilled by the ORM and you need/have to use SQL.
  - Groxx 16y ago
    ie, in every non-trivial or legacy-supporting use. Such as everything in existence for a non-brand-new company.
  - wladimir 16y ago
    A good ORM such as SQLAlchemy can do (nearly) everything that SQL can, it even knows quite some specific options for SQL dialects. Yes, there might be cases that a very specifically optimized query needs SQL, but those should be the exception not the rule.
steve-howard 16y ago
The side benefit of prepared statements, perhaps even more importantly if security is not really your concern, is that you don't need a password page that looks like this (this is really the password requirements page for my school): A password must: be 6-8 characters in length. contain a non-alphanumeric character such as ( ! ] & * , + = A password cannot: ... include a dollar sign ( $ ), a single quote ( ‘ ), a double quote ( “ ), a number sign ( # ), a less-than sign ( < ), a question mark ( ? ), a pipe ( | ), a back quote ( ` ), or a backslash ( \ ). ...
- reemrevnivek 16y ago
  I hate those signups. The worst part about them is that they're usually on sites I'm required to sign up for, like a school, work, or corporate service. If it was a startup web app I was signing up for, I'd send the developer a polite email saying that I didn't feel comfortable putting my data in such a system. Unfortunately, all I can usually do is gripe a little in private.
- sbierwagen 16y ago
  Fun fact: Etrade won't let you use a period ( . ) in a password. No error or anything, account creation just silently fails.
- amalcon 16y ago
  You don't need one of those anyway, if you hash your passwords like you should.

by Skalman 16y ago

tptacek 16y ago

This is the second time in a few days someone has made the point that web stacks make it hard to use prepared statements†. This is a one-liner in Rails. Does it not work in Python? How hard is it in PHP? † Which are not a cure-all for SQLI.

T-hawk 16y ago
I think the problem angle is slightly different: it's too easy to use simple string concatenation for SQL. That works across pretty much every web stack, so it's the path of least resistance to get something working, and many a developer never bothers to learn the proper idiom anew for every framework. Side note: We're jumping to conclusions by thinking that the javascript is the entire implementation. It's perfectly possible that the server is already safe against SQL injection and the javascript is just an extra line of defense. Maybe the client and server were done by separate programmers and the client programmer wanted to make sure he wouldn't get blamed. It's a government website: nobody in government ever got fired for being too careful. Or maybe the programmer had to do it to satisfy some non-technical bureaucrat who wanted to think that hacking attempts couldn't even reach his server.
timwiseman 16y ago
I wrote fairly recently about SQL Injection in Python at http://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/ http://www.simple-talk.com/sql/learn-sql-server/sql-injectio... . I do not address web stacks directly there, but Python itself will happily let you use prepared statements, it is up to the programmer to take effective steps to prevent SQL Injection.
cosmok 16y ago
Very easy in PHP. http://php.net/manual/en/pdo.prepared-statements.php http://php.net/manual/en/pdo.prepared-statements.php
- damncabbage 16y ago
  Except when the database drivers PDO relies on aren't set up by default: http://news.ycombinator.com/item?id=2376873 http://news.ycombinator.com/item?id=2376873

moe 16y ago

it's just that every language makes it so difficult to use prepared statements Huh? Most web frameworks use ORMs and discourage you from touching SQL at all.

graywh 16y ago
Which is great until you discover that your needs can't be fulfilled by the ORM and you need/have to use SQL.
- Groxx 16y ago
  ie, in every non-trivial or legacy-supporting use. Such as everything in existence for a non-brand-new company.
- wladimir 16y ago
  A good ORM such as SQLAlchemy can do (nearly) everything that SQL can, it even knows quite some specific options for SQL dialects. Yes, there might be cases that a very specifically optimized query needs SQL, but those should be the exception not the rule.

steve-howard 16y ago

The side benefit of prepared statements, perhaps even more importantly if security is not really your concern, is that you don't need a password page that looks like this (this is really the password requirements page for my school): A password must: be 6-8 characters in length. contain a non-alphanumeric character such as ( ! ] & * , + = A password cannot: ... include a dollar sign ( $ ), a single quote ( ‘ ), a double quote ( “ ), a number sign ( # ), a less-than sign ( < ), a question mark ( ? ), a pipe ( | ), a back quote ( ` ), or a backslash ( \ ). ...

reemrevnivek 16y ago
I hate those signups. The worst part about them is that they're usually on sites I'm required to sign up for, like a school, work, or corporate service. If it was a startup web app I was signing up for, I'd send the developer a polite email saying that I didn't feel comfortable putting my data in such a system. Unfortunately, all I can usually do is gripe a little in private.
sbierwagen 16y ago
Fun fact: Etrade won't let you use a period ( . ) in a password. No error or anything, account creation just silently fails.
amalcon 16y ago
You don't need one of those anyway, if you hash your passwords like you should.