Hacker News Reader

Comment by Skalman | Hacker News Reader

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)

View on HN

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 ( \ ). ...

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.

Fun fact: Etrade won't let you use a period ( . ) in a password. No error or anything, account creation just silently fails.

You don't need one of those anyway, if you hash your passwords like you should.

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.

Which is great until you discover that your needs can't be fulfilled by the ORM and you need/have to use SQL.

ie, in every non-trivial or legacy-supporting use. Such as everything in existence for a non-brand-new company.

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.

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.

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.

I wrote fairly recently about SQL Injection in Python at 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.

Very easy in PHP. http://php.net/manual/en/pdo.prepared-statements.php

Except when the database drivers PDO relies on aren't set up by default:

http://news.ycombinator.com/item?id=2376873

Reply on news.ycombinator.com