Having been confronted with some bold claims about PostgreSQL’s insecurity (while hailing MySQL’s security) I’d like to get someone else’s opinion:
- “PostgreSQL is insecure because of multiselects” – I’d assume `multiselects` are what I’d call `subselects`, but I might be wrong. Current MySQL versions support subselects, but according to [1] some libraries might not support or might have disabled them. Could that be the reason for the claim or am I overlooking something here?
- “SQL injections are the easiest to exploit with PostgreSQL” – IMHO SQL injections are an application / library problem and are simply valid SQL queries, so there is no real difference between databases, right?!
- “I love PostgreSQL for getting root permissions as it has so many security holes” – first I’d assume PostgreSQL’s security track record is about as good as MySQL’s (couldn’t really find much on this)? Secondly running PostgreSQL as root is simply a stupid idea. Or is there anything valid in this?
I’d have said that PostgreSQL is more security aware than MySQL (supporting roles, more authentication methods,…), but that the database itself has generally a very limited impact on the security of an application. Or am I overlooking any arguments here?
[1] Is MySQL more resistant to SQL injection attack than PostgreSQL (under Perl/DBI)?
PS: Both MySQL and PostgreSQL are great products – no need for any non-security related discussions 😉
Putting this here as a comment isn’t a good place for it:
A multiselect is a query like:
Two seperate queries, one single query call. It’s the classic SQL injection scenario, where user-provided data executes a completely different query than the coder had intented, e.g. The Bobby Tables attack.
MySQL/PHP are immune to this only by virtue of MySQL’s driver not allowing such constructs. It’s still totally vulnerable to sub-query injections, but it won’t allow two totally independent queries in the same statement.