PHP_PHP チュートリアルでの SQL インジェクション攻撃の包括的な防止

　　一、 注入式攻击的类型

　　可能存在许多不同类型的攻击动机，但是乍看上去，似乎存在更多的类型。这是非常真实的-如果恶意用户发现了一个能够执行多个查询的办法的话。

　　如果你的脚本正在执行一个SELECT指令，那么，攻击者可以强迫显示一个表格中的每一行记录-通过把一个例如"1=1"这样的条件注入到WHERE子句中，如下所示(其中，注入部分以粗体显示)：

SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'

　　正如我们在前面所讨论的，这本身可能是很有用的信息，因为它揭示了该表格的一般结构(这是一条普通的记录所不能实现的)，以及潜在地显示包含机密信息的记录。

　　一条更新指令潜在地具有更直接的威胁。通过把其它属性放到SET子句中，一名攻击者可以修改当前被更新的记录中的任何字段，例如下面的例子（其中，注入部分以粗体显示）：

UPDATE wines SET type='red'，'vintage'='9999' WHERE variety = 'lagrein'

　　通过把一个例如1=1这样的恒真条件添加到一条更新指令的WHERE子句中，这种修改范围可以扩展到每一条记录，例如下面的例子（其中，注入部分以粗体显示）：

UPDATE wines SET type='red'，'vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'

　　最危险的指令可能是DELETE-这是不难想像的。其注入技术与我们已经看到的相同-通过修改WHERE子句来扩展受影响的记录的范围，例如下面的例子（其中，注入部分以粗体显示）：

DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'

　　二、 多个查询注入

　　多个查询注入将会加剧一个攻击者可能引起的潜在的损坏-通过允许多条破坏性指令包括在一个查询中。在使用MySQL数据库时，攻击者通过把一个出乎意料之外的终止符插入到查询中即可很容易实现这一点-此时一个注入的引号(单引号或双引号)标记期望变量的结尾；然后使用一个分号终止该指令。现在，一个另外的攻击指令可能被添加到现在终止的原始指令的结尾。最终的破坏性查询可能看起来如下所示：

SELECT * FROM wines WHERE variety = 'lagrein';GRANT ALL ON *.* TO 'BadGuy@%' IDENTIFIED BY 'gotcha';'

　　这个注入将创建一个新的用户BadGuy并赋予其网络特权（在所有的表格上具有所有的特权）；其中，还有一个"不祥"的口令被加入到这个简单的 SELECT语句中。如果你遵循我们在以前文章中的建议－严格限制该过程用户的特权，那么，这应该无法工作，因为Web服务器守护程序不再拥有你撤回的 GRANT特权。但是从理论上讲，这样的一个攻击可能给予BadGuy自由权力来实现他对你的数据库的任何操作。

　　至于这样的一个多查询是否会被MySQL服务器处理，结论并不唯一。这其中的一些原因可能是由于不同版本的MySQL所致，但是大多数情况却是由于多查询存在的方式所致。 MySQL的监视程序完全允许这样的一个查询。常用的MySQL GUI-phpMyAdmin，在最终查询之前会复制出以前所有的内容，并且仅仅这样做。

　　但是，大多数的在一个注入上下文中的多查询都是由PHP的mysql扩展负责管理的。幸好，默认情况下，它是不允许在一个查询中执行多个指令的；试图执行两个指令(例如上面所示的注入)将会简单地导致失败-不设置任何错误，并且没有生成任何输出信息。在这种情况下，尽管PHP也只是"规规矩矩"地实现其缺省行为，但是确实能够保护你免于大多数简单的注入式攻击。

　　PHP5中的新的mysqli扩展(参考http://php.net/mysqli)，就象mysql一样，内在地也不支持多个查询，不过却提供了一个mysqli_multi_query()函数以支持你实现多查询-如果你确实想这样做的话。

　　然而，对于SQLite-与PHP5绑定到一起的可嵌入的SQL数据库引擎(参考http://sqlite.org/和http: //php.net/sqlite)情况更为可怕，由于其易于使用而吸引了大量用户的关注。在有些情况下，SQLite缺省地允许这样的多指令查询，因为该数据库可以优化批查询，特别是非常有效的批INSERT语句处理。然而，如果查询的结果为你的脚本所使用的话（例如在使用一个SELECT语句检索记录的情况下），sqlite_query()函数却不会允许执行多个查询。

　　三、 INVISION Power BOARD SQL注入脆弱性

　　Invision Power Board是一个著名的论坛系统。2005年五月6号，在登录代码中发现了一处SQL注入脆弱性。其发现者为GulfTech Security Research的James Bercegay。

このログインクエリは次のとおりです:

$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");

このうち、メンバーID変数$midとパスワード ID 変数 $pid は、次の 2 行のコードを使用して my_cookie() 関数から取得されます:

$mid = intval($std->my_getcookie('member_id'));$pid = $std->my_getcookie ('pass_hash' );

ここで、my_cookie() 関数は次のステートメントを使用して Cookie から要求された変数を取得します:

return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name] ); 注: この Cookie から返される値はまったく処理されません。 $mid はクエリで使用される前に整数に強制されますが、$pid は変更されません。したがって、前述した種類のインジェクション攻撃に対して脆弱です。

したがって、次の方法で my_cookie() 関数を変更すると、この脆弱性が公開されます:

if ( ! in_array( $name, array('topicsread', 'forum_read', 'collapseprefs') ) )

{

return $this->

clean_value(urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]));

}

else

{

return urldecode( $_COOKIE [$ibforums->vars['cookie_id'].$name]);

}

そのような修正の後、キー変数はグローバル clean_value() 関数を「通過」した後に返されますが、他の変数は検査が行われていません。

SQL インジェクションとは何か、どのように機能するか、そしてこのインジェクションがどれほど脆弱であるかについて一般的に理解できたので、効果的に防止する方法を見てみましょう。幸いなことに、PHP は豊富なリソースを提供するため、推奨する手法を使用して注意深く徹底的に構築されたアプリケーションによって、スクリプトから SQL がインジェクションされる可能性が基本的に排除されると確信を持って予測できます。これは、ユーザーのデータを「クリーンアップ」することによって実現されます。損害が発生する前に。

http://www.bkjia.com/PHPjc/446978.html

www.bkjia.com本当http://www.bkjia.com/PHPjc/446978.html技術記事 1. インジェクション攻撃の種類 攻撃の動機にはさまざまな種類があると思われますが、一見すると、さらに種類があるように見えます。それは非常に現実的です - 悪意のあるユーザーが...