PostgreSQL 的安全性与 MySQL 等相比
面对一些关于 PostgreSQL 不安全性的大胆说法（同时赞扬 MySQL 的安全性），我想听听其他人的意见：
- “PostgreSQL 由于多重选择而不安全” - 我认为“多重选择”就是我所说的“子选择” '，但我可能是错的。当前的 MySQL 版本支持子选择，但根据 [1]，某些库可能不支持或可能已禁用它们。这可能是索赔的原因还是我在这里忽略了一些东西？
- “SQL 注入是 PostgreSQL 中最容易利用的” - 恕我直言，SQL 注入是一个应用程序/库问题，并且只是有效的 SQL 查询，因此数据库之间没有真正的区别，对吧？！
- “我喜欢 PostgreSQL 获得 root 权限，因为它有很多安全漏洞”——首先我假设 PostgreSQL 的安全记录与 MySQL 的一样好（在这方面确实找不到太多信息）？其次，以 root 身份运行 PostgreSQL 是一个愚蠢的想法。或者这里面有什么道理吗？
我想说 PostgreSQL 比 MySQL 更具安全意识（支持角色、更多身份验证方法……），但数据库本身对应用程序安全性的影响通常非常有限。或者我忽略了这里的任何论点？
[1] MySQL 是否比 PostgreSQL（在 Perl/DBI 下）更能抵抗 SQL 注入攻击？
PS：MySQL 和 PostgreSQL 都是很棒的产品 - 不需要任何非安全相关的东西讨论;-)
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 ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
默认的 PostgreSQL 安装会阻止通过 pg_hba.conf 文件以非常严格的方式访问数据库。数据库如何向外界公开取决于系统管理员。配置完成后，就由应用程序来防止数据库“攻击”。
The default PostgreSQL installation prevents accessing the database in very rigorous ways via pg_hba.conf file. It is up to the system administrator how the database will be exposed to the outside world. Once it is configured, it is up to the application to prevent DB "attacks".
PostgreSQL 并不是不安全的，因为多查询语句，这是正常功能，但在较旧的 MySQL 驱动程序中不可用 MySQLi 驱动程序还支持多查询语句。几乎所有其他数据库都有这个选项，MySQL 只是很晚才实现它，并不意味着“安全”
SQL 注入是程序员犯的一个重大错误，而不是数据库的主要问题。键盘，这是罪魁祸首。
使用准备好的语句并停止信任用户输入，这就是避免 SQL 注入和其他安全问题的方法。存储过程还可以帮助降低 SQL 注入的影响，这些在 PostgreSQL 中非常易于使用。还有quote_ident() 当 SQL 中有动态表名或列名时。 MySQL缺少这样的功能。
PostgreSQL 有角色和继承角色来设置和维护权限。如果您将超级用户权限（root）授予每个人，就会产生问题。如果你不这样做，你就安全了。超级用户权限中没有已知的错误，有关这些权限中的安全漏洞的声明听起来像是 FUD，因为没有证据。
您检查过 SE PostgreSQL 吗？这是更高级别的安全性。 PostgreSQL 9.1 版（目前为测试版）也为 SE 提供了新选项。 MySQL 只能梦想这种级别的安全性。
PostgreSQL isn't unsecure because of multi-query-statements, that's normal functionality but it isn't available in older MySQL-drivers. The MySQLi-driver also supports multi-query-statements. SQL Server, Oracle, DB2 and almost all other databases have this option, MySQL was just very late to implement it. Being late, doesn't mean "safe".
SQL injection is a major error made the programmer, not by the database. The major problem sits behind the keyboard, that's the one to blame.
Use prepared statements and STOP trusting userinput, that's how you avoid SQL injection and other security problems. Stored procedures can also help to lower the impact of SQL injection, these are very ease to use in PostgreSQL. Check also quote_ident() when you have dynamic table- or columnnames in your SQL. MySQL lacks functions like this.
PostgreSQL has ROLES and inherited roles to set and maintain permissions. If you give away superuser permissions (root) to everybody, you create problems. If you don't, you're safe. There are no known bugs in superuser permissions, the claim about security holes in these permissions sounds like FUD because there is no proof.
Did you check SE PostgreSQL? That's security on a higher level. PostgreSQL version 9.1 (beta at this moment) has new options for SE as well. MySQL can only dream about this level of security.
我个人认为，针对不同数据库技术的安全争论通常是完全没有根据的，并且在许多情况下，那些快速指责其中一种或另一种技术的人可能没有意识到数据泄漏的原因并不是因为数据库，但因为他们没有正确保护他们的应用程序，但不能承认错误，从而将责任归咎于其他地方。至少这是迄今为止我对任何数据库技术进行的所有安全辩论。
一个很好的例子是，SQL 注入根本就不是数据库错误。 SQL 是一种标准化语言，被 MySQL 和 PostgreSQL（以及 Oracle 等）所接受。 SQL 注入是对结构化查询语言的操纵，而不是服务器安全缺陷。其原因是应用程序没有正确清理输入。您不能说，使用相同标准化语言的一个数据库在防止意外查询操作方面的安全性比使用相同技术的另一个数据库要低，因此无论谁告诉您 SQL 注入显然更多的是这两个数据库之一的问题不明白SQL注入到底是什么。
关于以 root 身份运行 PostgreSQL，您不应该以 root 身份运行任何一个。以 root 用户身份在服务器上运行服务始终是一个坏主意，同样，与服务器无关。
我对 PostgreSQL 的经验很少，但我会说 MySQL 有一个出色的权限系统，允许用户在特定的数据库列表上、在选择列表客户端主机上委派一组可用命令。 PostgreSQL 的做法可能与此不同，但我很难接受，当与身份验证和用户帐户相关时，一个人的安全性会超越另一个人。
It's my personal opinion that security debates with different database technologies are often entirely unfounded and in many cases, those who are quick to point the finger at one or the other likely fail to realize that the reason for a data spillage wasn't because of the database, but because they didn't properly secure their application, but can't admit fault, thus placing blame elsewhere. At least that's every security debate I've had thus far over any database technology.
A good example, SQL injection is not the database fault at all, ever. SQL is a standardized language, accepted by both MySQL and PostgreSQL (and Oracle, and others...). SQL injection is the manipulation of the Structured Query Language, not a server security flaw. The fact that the application did not properly sanitize input is the reason for it. You can't argue that one database that uses the same standardized language is any less secure against unintended query manipulation than another database that uses the same techonology, so whoever told you that SQL injection is more of a problem with one of these two databases clearly doesn't understand what exactly SQL injection is.
With regards to running PostgreSQL as root, you shouldn't run either as root. Running a service on a server as the root user is always a bad idea, again, nothing related to the servers.
I have very little experience with PostgreSQL, but I will say that MySQL has an outstanding permission system in place that allows users to be delegated a set of available commands, on a specific list of databases, on a select list client hosts. PostgreSQL may be done differently than that, but I'd be hard pressed to accept that one's security when related to authentication and user accounts is leaps and bounds over the other.
作为对 Scott 答案（+1）的补充，我要添加几件事：
DROP table foo;指令。In complement to Scott answer (+1), I would add several things:
DROP table foo;instructions.将其作为注释放在此处并不是一个好地方：
多选是这样的查询：
两个单独的查询，一个查询调用。这是经典的 SQL 注入场景，其中用户提供的数据执行与编码器意图完全不同的查询，例如 Bobby Tables 攻击。
MySQL/PHP 不受此影响，只是因为 MySQL 的驱动程序不允许此类构造。它仍然完全容易受到子查询注入的攻击，但它不允许在同一语句中存在两个完全独立的查询。
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.