PostgreSQL的安全性与MySQL等相比

问题描述

| 在面对有关Postgresql不安全的一些大胆主张（同时赞扬MysqL的安全性）之后，我想征询其他人的意见： \“由于多重选择，Postgresql是不安全的” \-我假设`multiselects'是我称之为`subselects`的东西，但是我可能是错的。当前的MysqL版本支持子选择，但根据[1]，某些库可能不支持或已禁用它们。这可能是提出索赔的原因，还是我在这里忽略了某些内容？ \“ sql注入是最容易使用Postgresql进行开发的\”-IMHO sql注入是一个应用程序/库问题，只是有效的SQL查询，因此数据库之间没有真正的区别，对吧？ \“我喜欢Postgresql，因为它具有很多安全漏洞，因此获得了root权限” –首先，我假设Postgresql的安全记录与MysqL一样好（在这方面确实找不到很多）这个）？其次，以root用户身份运行Postgresql只是一个愚蠢的想法。还是有什么有效的方法？ 我曾说过Postgresql比MysqL更安全（支持角色，更多身份验证方法等），但是数据库本身通常对应用程序的安全性影响非常有限。还是我忽略了这里的任何论点？ [1] MysqL是否比Postgresql（在Perl / DBI下）更能抵抗sql注入攻击？ PS：MysqL和Postgresql都是很棒的产品-无需任何与安全无关的讨论;-)     

解决方法

        在此处添加注释不是一个好地方： 多选是一个查询，例如：

mysql_query(\"SELECT x FROM y; SELECT p FROM q;\");

两个单独的查询，一个单独的查询调用。这是经典的SQL注入方案，在这种情况下，用户提供的数据执行的编码与编码器意图执行的查询完全不同。 Bobby Tables攻击。 MySQL / PHP仅通过MySQL的驱动程序不允许这种构造，才能避免这种情况。它仍然完全容易受到子查询注入的影响，但在同一条语句中将不允许两个完全独立的查询。     ,           \“默认情况下，PostgreSQL可能是   最了解安全性的数据库   可用... \“      数据库黑客手册 PostgreSQL并非由于多重查询语句而变得不安全，这是正常的功能，但在较旧的MySQL驱动程序中不可用。 MySQLi驱动程序还支持多查询语句。 SQL Server，Oracle，DB2和几乎所有其他数据库都具有此选项，而MySQL实施起来还很晚。迟到并不意味着“安全”。 SQL注入是程序员造成的主要错误，而不是数据库造成的。主要问题出在键盘后面，这是应该负责的问题。 使用准备好的语句并停止信任用户输入，这就是避免SQL注入和其他安全问题的方式。存储过程还可以帮助降低SQL注入的影响，这些在PostgreSQL中非常容易使用。当您的SQL中有动态表名或列名时，也请检查quote_ident（）。 MySQL缺少这样的功能。 PostgreSQL具有ROLES和继承的角色来设置和维护权限。如果向所有人放弃超级用户权限（root），则会造成问题。如果不这样做，那就很安全。超级用户权限中没有已知的错误，关于这些权限中的安全漏洞的声明听起来像FUD，因为没有证据。 您检查了SE PostgreSQL吗？这是更高级别的安全性。 PostgreSQL 9.1版（目前为beta版）也为SE提供了新选项。 MySQL只能梦想这种安全级别。     ,我个人认为，使用不同的数据库技术进行安全性辩论通常是完全没有根据的，并且在许多情况下，那些很快将矛头指向另一方的人可能没有意识到数据泄漏的原因不是“原因在于数据库，但是因为他们没有适当地保护其应用程序，但不能承认错误，因此将责任归咎于其他地方。到目前为止，至少这是我就任何数据库技术所进行的每一次安全性辩论。 一个很好的例子，SQL注入根本不是数据库故障。 SQL是一种标准语言，被MySQL和PostgreSQL（以及Oracle，以及其他语言）接受。 SQL注入是对结构化查询语言的操纵，而不是服务器安全性缺陷。该应用程序未正确清理输入的事实是其原因。您不能说与使用相同技术的另一个数据库相比，使用相同标准化语言的一个数据库在防止意外查询操作方面的安全性要低得多，因此无论谁告诉您，SQL注入对于这两个数据库中的一个问题更多显然不明白什么是SQL注入。 关于以root身份运行PostgreSQL，您也不应以root身份运行。以root用户身份在服务器上运行服务始终是一个坏主意，同样，与服务器无关。 我对PostgreSQL的经验很少，但是我要说的是MySQL具有出色的权限系统，该系统允许在特定列表的数据库上，在选择列表客户端主机上，委派用户一组可用的命令。 PostgreSQL的做法可能与此不同，但我很难接受的是，与身份验证和用户帐户有关的安全性是跨越其他安全性的。     ,        为了补充Scott的答案（+1），我将添加以下内容： MySQL无法进行带有子查询的SQL注入，但是您可以使用UNION查询进行SQL注入，这要长一些，但是就信息公开而言，UNION注入是必须的。 SQL注入最常用于信息公开，而不是注入“ 1”指令。 PostgreSQL拒绝基础间查询，除非您使用dbi_connect特殊行为。因此，就数据库分离而言，它更好。 PostgreSQL具有很大的用户/组特权管理，并且您可以为每个用户或组的所有对象和数据提供非常好的SQL策略。我会说它甚至比您在MySQL中拥有的更好（但我可能错了）。在数据库连接用户凭据管理方面，您有一个非常强大的工具，例如，您可以将数据库用户映射到外部SSO系统上。 然后，这对我来说是最重要的一点。在安全性方面，拥有安全可靠的数据库的一种方法是限制应用程序入口点并管理数据库中的数据完整性和繁重的数据操作。如果将应用程序入口点限制为某些存储过程和视图，某些存储语句，然后在其他一些存储过程和触发器中执行重要的操作，或者如果仅向用户显示视图，并使用规则来执行实际的写作业等等，明白我的意思吗？好的，构建这样的应用程序PostgreSQl实际上是两者中最好的。     ,        默认的PostgreSQL安装会阻止通过pg_hba.conf文件以非常严格的方式访问数据库。系统管理员将如何将数据库公开给外界，这取决于系统管理员。配置完成后，应由应用程序来阻止DB“攻击”。