As far as it goes, it's at least as correct as it is for shell scripts and things.

so theres no other things to worry about? no javascript injections etc?

No automatic safety feature is a substitute for thinking.

If CGI param()s are tainted (and I believe they are) and you're using the bind params, then I think SQL injection is the least of your worries. It will probably complain if you don't think to check the tainted stuff. And if you test poorly and untaint and it gets passed to DBI ... it probably won't matter because the DBI quoting and bind params should take care of it automatically. I don't believe javascript can change the problem space with respect to SQL injection.

However taint and DBI probably won't help with things like cross site scripting and the remote root hole on some random service you didn't know you had running (if applicable).

-Paul

Taint-checking and placeholders help protect the server against clients trying to perform actions they're not authorized for. They don't help at all against "cross-site scripting" (where one client uses the server to attack other clients).

Cross-site scripting attacks are dangerous because they can trick legitimate users/clients into performing actions they do have authority for, but don't want to do.

So you still need to worry about anything that can influence the client - like html/javascript in input etc. Usually, like quoting with DBI, HTML-escaping all output should go some way, but there are more complex issues.

http://www.owasp.org/ is a good resource if you're serious about web security.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

You asked about SQL injection attacks. The protective steps you've described protects against those *only*.

If you then take what's in the database and send it out in HTML, then you're publishing someone else submission, and that's a whole different problem.

"As long as I taint and use placeholders with DBI, theres no way they'll ever be a SQL injection through this web app"

Tainting helps, but won't solve the problem, because it's always possible to untaint poorly (e.g., if you black list unacceptable patterns, instead of white listing the acceptable ones).

Do you think that placeholders, by themselves, entirelly solve the problem of SQL injections? That's the question.

I stand under correction, but I would say yes. The reason being that everything in a placeholder goes via $dbh->quote(), so unless there is a bug in the quoting code, it should be fine.

Also, DBI runs only one command at a time, so sticking two commands in there (as is usually done with SQL injections), shouldn't succeed.

YMMV

clint

Yes, the DBI documentation says that only one command should be run at a time. That is more of a recommendation of how the DBI is intended to be used. It is not necessarily descriptive of what will be accepted. Whether multiple commands are accepted is up to the individual drivers and databases:

In ODBC terms, the DBI is in "pass-thru" mode, although individual drivers might not be.

- The DBI documentation

I have seen DBD::Mysql and DBD::Sybase accept multiple commands at a time. I don't know about other drivers.

But, as you say, unless there's a bug in the quoting code, placeholders are quite safe. They won't necessarily prevent you from running multiple commands at once, but they will prevent user-supplied data from being interpreted as SQL commands.

If you never include user-supplied data directly in a SQL statement passed to DBI, then yes, you have entirely solved the problem of SQL injection. Placeholders are the tool that lets you do that.