Question

我一直在阅读关于SQL注入攻击以及如何避免它们的问题，尽管我似乎永远不会在工作中做出“糟糕”的例子，例如：的 see this post

我在数据库中创建了一个PHP文件和一个表，通过$_GET传递了一个值，并尝试通过bob'); drop table students; --删除该表，但它不起作用。 PHP自动转义\'并且查询有错误，没有造成任何损害。尝试复制AND WHERE 1=1等登录“攻击”时的相同问题

示例代码：

<?php
$id = $_GET['id'];

$sql = "INSERT INTO Users (Username) VALUES ($id)";
echo $sql;
mysql_query($sql) or die(mysql_error());

我会通过sql.php?id=1); delete from Users; --

这是一个过时的东西，曾经在PHP3或其他什么时候应用，现在甚至新手都受到保护，不受魔法引号之类的影响？

我在Ubuntu上使用PHP5。

Answer 1

恰恰相反。 魔术引号在PHP5中已弃用，将在PHP 5.4中完全删除，因为它们给编程世界带来了比他们做得更好的混乱。检查魔法引号是否有效，并在必要时严格逃避任何SQL输入仍然是非常非常重要的......虽然没有理由感觉不好，但我们都在那里，而且我的不知不觉的屁股已被无数的魔法报价所拯救时代:)

关于魔术引号的 PHP manual 解释了所有内容。

Answer 2

不，这仍然非常重要。

XSS和CSRF也是如此。永远不要低估正确输入过滤的重要性。

Answer 3

嘿，在这种情况下，magic_quotes_gpc设置为“on”就可以保存。

You'll be screwed soon

Answer 4

历史上最大的身份盗用是通过利用SQL注入漏洞在2007年实现的：参见“SQL injection attacks led to Heartland, Hannaford breaches”（ComputerWorld，8/18/2009）。

OWASP reported in 2007注入攻击（其中SQL注入就是一个例子）仍然是最常见的软件安全问题之一。

您还可以搜索最近的 SQL injection News ，并查找每个月报告的很多案例。

然而，XKCD漫画中的示例不一定是最常见的漏洞利用类型。通过在一个请求中执行第二个SQL语句来删除表可能不会使攻击者获得有价值的数据，这只会是故意破坏。

此外，默认情况下，某些查询界面仍然禁用multi-query。也就是说，无论分号如何，数据库客户端API都只执行给定SQL字符串的单个语句。这打败了卡通片中的例子。

注意：默认情况下，支持多查询已知PDO的query()方法。因此易受XKCD式攻击。

正如其他人所指出的那样，更有可能的风险是SQL注入会改变SQL表达式的逻辑，并将查询应用于除了你想要的那些之外的额外行。

例如：

$sql = "UPDATE Users SET PASSWORD = MD5('" . $_POST["password"] . "'||salt) " . 
       "WHERE user_id = " . $_POST["userid"];

当我将参数userid设置为字符串123 OR userid=456的请求发送时会发生什么？我会重置我自己的密码（用户ID 123）以及用户ID 456的密码。即使用每用户盐哈希密码也无法防止这种情况发生。现在我可以登录任一帐户。

可以通过多种方式进行SQL注入。

Answer 5

魔术引号不考虑字符编码，因此容易受到基于multi-byte个字符的攻击。</ p>

至于今天的风险，谷歌搜索会出现无数易受攻击的网站。在9月10日左右报告了Bugzilla的SQL注入漏洞。所以，是的，网站仍处于危险之中。他们应该吗？这些工具可以防止注射，所以没有。

Answer 6

该特定攻击不起作用，因为mysql_query只会执行一个语句。

我仍然可以滥用您的代码，例如如果我安排id为SELECT password FROM Users WHERE Username='admin'我可能有机会让你的系统暴露一些内部信息。

基本上，如果您允许未经过滤的输入到您的SQL中，那么将会有一些非常有创意的方法来创建您不期望的数据，并公开您不想要的数据！

Answer 7

哦，我的.. SQL注入不是风险，它是一个差距安全漏洞。它主要存在于php中，因为API使您希望将任何旧数据插入到SQL查询中。

当我看到用PHP或ASP编写的网站时，我可以闻到他们喜欢的SQL注入向量。人们尝试使用mysql_real_escape_string()和intval()保护他们的PHP应用，并在其他语言中做同样的事情。这是个错误。这就像用C编写代码而不是Java或Python，在前者中，你犯了一个错误而你已经死了，但在后者中，只存在语义缺陷。

我强烈建议人们使用mysqli和预先准备好的语句，或其他任何参数化，将文本替换为代码，然后解释它只是首先恕我直言的坏习惯。

另一方面，PHP的神奇报价很愚蠢，谢天谢地，不赞成使用。它只会造成弊大于利。如果您依赖魔术引号，则表示您的应用将在禁用魔术引号时拥有。同样，它可能会破坏其他不期望输入字符串转义的应用程序。

Answer 8

这是一个非常活跃的风险，魔术报价试图给你一个解决方案，但我更喜欢总是用魔术报价开发。这样我必须确保自己实际上逃避输入。谁知道在实际部署脚本的服务器上是否会打开或关闭魔术引号。

Answer 9

这仍然是一个大问题。您不能假设在您可能使用的每个PHP安装中都启用了magic_quotes。

要查看是否已启用魔法引号并清除魔法引号中的混乱：

if ( get_magic_quotes_gpc() !== 0 ) { $foo = stripslashes( $foo ); }

然后稍微清理一下你的陈述：

$foo = mysql_real_escape_string( $foo );
$sql = "select * from foo where bar='{$foo}'";

等

事实上，如果你有能力这样做，你最好只是严格转向magic_quotes。

我希望能帮助你。

Answer 10

bobby表示例不适用于mysql接口，因为它不会在一次调用中执行多个查询。 mysqli界面容易受到多次查询攻击。 mysql接口更容易受到特权提升攻击的影响：

在您的表单中，我输入了帐户：admin密码：' or 1=1 --，以便您的典型登录信息：select * from users where user_name = '$admin' and password = '$password'。或者导致这是真的，让你登录。

Answer 11

PHP不能查询参数吗？如果可以的话（因为如果没有，我会感到惊讶），这是一种减轻所有SQL注入攻击的解决方案。

Answer 12

正如我之前曾多次提到过stackoverflow，我是PDO的坚定支持者，只是停止使用老式的mysql，自己和你的客户一个大忙，学习PDO（它是非常简单）并利用预处理语句和绑定参数。即使您不需要准备好的语句表现，您仍然可以获得安全性好处。

另外，如果魔术引号设置为on，我会建议在客户端面对整个应用程序崩溃。这只是为了保护愚蠢和惹恼智能的资源。（它使用更多的cpu而不是手动转义，因为它会对所有内容进行编码，即使您不需要它也是如此）

Answer 13

执行SQL注入有很多不同的方法，还有很多方法可以绕过基本的安全预防措施。

根据OWASP，这些攻击属于排名前10位的Web应用程序漏洞（排名第2位）。

有关详细信息，请参阅 Top 10 2007-Injection Flaws 。

Answer 14

最简单的经验法则是假设所有用户input都可能受到污染。检查数据类型是否符合预期，变量是您期望的长度/大小范围，文件是您允许的大小和类型等。可以保证对非外部数据的其他检查 - 在您调用某些重要的管理员之前级别功能，执行检查 - ($userlevel != ADMIN)?die():important_function();

总会有更大的鱼，或者比你更大的混蛋。避免对数据做出假设，你就有了先机。

Answer 15

从网页传递给sql查询的参数往往是数字ID。例如，假设您有一个网址http://foo.com/page.php?section=34，在这样的查询中使用部分ID：

SELECT content FROM sections WHERE section_id=$section;

在您的示例中没有要引用的引号，以及在URL中的数字之后放置的任何内容都将传递给查询...因此风险是真实的。

Answer 16

不，你对SQL注入的担心越少，就越有可能被它击中。

Answer 17

今天不是，但它只是20:34 UTC

Guardian jobs database attack demonstrates difficulties of database security, 06 Nov 2009

Guardian Jobs website hack may have been an SQL injection and not a 'sophisticated' attack, 27 Oct 2009

Answer 18

每当从字符串构建SQL时，SQL注入是一个真正的危险。

我还发现，尝试避免从字符串构建SQL是一种毫无意义的努力。迟早，必须在运行时生成完整形式的SQL（不仅仅是可能是参数的东西）。

Answer 19

我必须开发一台无法禁用magic_quotes的服务器！我在每个页面都包含这个以撤消魔术引号的效果，因此我可以在没有“双重转义”的情况下正确地逃避自己。即使我只是通过阅读这个来尝试呕吐，我还没有找到更好的解决方案。

if (get_magic_quotes_gpc()) {

    $process = array(&$_GET, &$_POST, &$_COOKIE, &$_REQUEST);

    while (list($key, $val) = each($process)) {

        foreach ($val as $k => $v) {

            unset($process[$key][$k]);

            if (is_array($v)) {

                $process[$key][stripslashes($k)] = $v;

                $process[] = &$process[$key][stripslashes($k)];

            } else {

                $process[$key][stripslashes($k)] = stripslashes($v);

            }

        }

    }

    unset($process);

}

Answer 20

根据OWASP 2017 Top 10，仍然是注射是最发生和最危险的攻击。

＆＃34; SQL注入始终是头号风险。这反映了有多少事件发生在那里，以及其他因素使它在那里保持很高的水平。特洛伊亨特 - 破坏网站的创始人hasibeenpwned.com

请记住，使用SQL注入我们可以转储整个数据库，通过上传Web shell等来控制Web服务器。

SQL注入今天是否存在风险？

20 个答案: