PHP セキュリティ - SQL インジェクション

SQLインジェクション

SQL インジェクションは、PHP アプリケーションで最も一般的な脆弱性の 1 つです。実際、開発者が SQL インジェクションの脆弱性を引き起こすために、同時に 2 つの間違いを犯す必要があるということは驚くべきことです。1 つは入力データのフィルター処理を行わないこと (入力のフィルター処理)、もう 1 つはデータベースに送信されるデータのフィルター処理を行わないことです。 . エスケープ (エスケープ出力)。これら 2 つの重要な手順は不可欠であり、プログラム エラーを減らすために特別な注意が必要です。

攻撃者にとって、SQL インジェクション攻撃を実行するには、思考と実験が必要です。データベース ソリューションについて十分に根拠のある推論を行うことが非常に必要です (もちろん、攻撃者がソース プログラムとデータベース ソリューションを参照できないことを前提としています)。次のような単純なログイン フォームを考えてみましょう。

CODE:

<form action="/login.php" method="POST">
<p>Username: <input type="text"
name="username" /></p>
<p>Password: <input type="password"
name="password" /></p>
<p><input type="submit" value="Log In"
/></p>
</form>

図 3-1 は、ブラウザでのフォームの表示を示しています。

攻撃者として、彼はユーザー名とパスワードを検証するためのクエリを推測することから始めます。ソースファイルを見ることで、彼はあなたの習慣を推測し始めることができます。

図 3-1. ブラウザーでのログイン フォームの表示

命名規則。通常、フォーム内のフィールド名はデータ テーブル内のフィールド名と同じであると想定されます。もちろん、それらが異なることを保証することが、必ずしも信頼できるセキュリティ対策であるとは限りません。

通常、最初の推測は次の例のクエリを使用することです:

CODE:

<?php
 
$password_hash = md5($_POST[&#39;password&#39;]);
 
$sql = "SELECT count(*)
      FROM   users
      WHERE  username = &#39;{$_POST[&#39;username&#39;]}&#39;
      AND    password = &#39;$password_hash&#39;";
 
?>

ユーザーパスワードの MD5 値を使用することがわかります。は一般的な方法ですが、現在は特に安全というわけではありません。最近の研究では、MD5 アルゴリズムには欠陥があり、多数の MD5 データベースによって MD5 逆クラッキングの難易度が低下していることが示されています。 http://www.php.cn/ にアクセスしてください。 デモをチェックしてください。

翻訳注釈: これは原文です。山東大学の教授、Wang Xiaoyun による研究では、MD5 の「衝突」、つまり同じ MD5 値を生成する可能性のある 2 つの異なるファイルと文字列をすぐに見つけることができることが示されています。 MD5 は情報ダイジェスト アルゴリズムであり、暗号化アルゴリズムではないため、逆クラッキングは問題外です。ただし、この結果によると、上記の特殊なケースでは、md5 を直接使用するのは危険です。

最善の保護方法は、独自に定義した文字列をパスワードに追加することです。たとえば、次のようになります。

もちろん、攻撃者は最初から正しく理解できない可能性があり、多くの場合、いくつかの実験を行う必要があります。実験するより良い方法は、ユーザー名として一重引用符を入力することです。これにより、重要な情報が公開される可能性があります。多くの開発者は、Mysql ステートメントの実行中にエラーが発生した場合、関数 mysql_error() を呼び出してエラーを報告します。以下の例を参照してください:

CODE:

<?php
 
$salt = &#39;SHIFLETT&#39;;
$password_hash = md5($salt . md5($_POST[&#39;password&#39;]
. $salt));
 
?>

この方法は開発には役立ちますが、重要な情報が攻撃者に公開される可能性があります。攻撃者がユーザー名として一重引用符を使用し、パスワードとして mypass を使用した場合、クエリ ステートメントは次のようになります。

CODE:

<?php
 
mysql_query($sql) or exit(mysql_error());
 
?>

ステートメントが MySQL に送信されると、システムは次のエラー メッセージを表示します:

<?php
 
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;&#39;&#39;
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
 
?>

何もしなくても、攻撃者は 2 つのフィールド名 (ユーザー名とパスワード) と、それらがクエリ内で出現する順序をすでに知っています。さらに、攻撃者は、データが正しくフィルタリングされず (プログラムが不正なユーザー名を要求しません)、エスケープされ (データベース エラーが発生します)、WHERE 条件全体の形式も公開されていることも知っています。操作を試みてください クエリに一致するレコードがあります。

この時点で、攻撃者には多くの選択肢があります。 1 つは、ユーザー名とパスワードが一致するかどうかに関係なく、クエリで一致を取得できるように、特別なユーザー名を入力しようとすることです:

myuser' or 'foo' = 'foo' --

假定将mypass作为密码，整个查询就会变成：

CODE:

<?php
 
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;myuser&#39; or &#39;foo&#39; = &#39;foo&#39;
--
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
 
?>

由于中间插入了一个SQL注释标记，所以查询语句会在此中断。这就允许了一个攻击者在不知道任何合法用户名和密码的情况下登录。

如果知道合法的用户名，攻击者就可以该用户(如chris)身份登录：

chris' --

只要chris是合法的用户名，攻击者就可以控制该帐号。原因是查询变成了下面的样子：

CODE:

<?php
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;chris&#39; --
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
?>

幸运的是，SQL注入是很容易避免的。正如第一章所提及的，你必须坚持过滤输入和转义输出。

虽然两个步骤都不能省略，但只要实现其中的一个就能消除大多数的SQL注入风险。如果你只是过滤输入而没有转义输出，你很可能会遇到数据库错误（合法的数据也可能影响SQL查询的正确格式），但这也不可靠，合法的数据还可能改变SQL语句的行为。另一方面，如果你转义了输出，而没有过滤输入，就能保证数据不会影响SQL语句的格式，同时也防止了多种常见SQL注入攻击的方法。

当然，还是要坚持同时使用这两个步骤。过滤输入的方式完全取决于输入数据的类型（见第一章的示例），但转义用于向数据库发送的输出数据只要使用同一个函数即可。对于MySQL用户，可以使用函数mysql_real_escape_string( )：

CODE:

<?php
 
$clean = array();
$mysql = array();
 
$clean[&#39;last_name&#39;] = "O&#39;Reilly";
$mysql[&#39;last_name&#39;] =
mysql_real_escape_string($clean[&#39;last_name&#39;]);
 
$sql = "INSERT
      INTO   user (last_name)
      VALUES (&#39;{$mysql[&#39;last_name&#39;]}&#39;)";
 
?>

尽量使用为你的数据库设计的转义函数。如果没有，使用函数addslashes( )是最终的比较好的方法。

当所有用于建立一个SQL语句的数据被正确过滤和转义时，实际上也就避免了SQL注入的风险。

CODE:

如果你正在使用支持参数化查询语句和占位符的数据库操作类（如PEAR::DB, PDO等），你就会多得到一层保护。见下面的使用PEAR::DB的例子：

CODE:

<?php
$sql = &#39;INSERT
      INTO   user (last_name)
      VALUES (?)&#39;;
$dbh->query($sql,
array($clean[&#39;last_name&#39;]));
?>

CODE:

 

由于在上例中数据不能直接影响查询语句的格式，SQL注入的风险就降低了。PEAR::DB会自动根据你的数据库的要求进行转义，所以你只需要过滤输出即可。

如果你正在使用参数化查询语句，输入的内容就只会作为数据来处理。这样就没有必要进行转义了，尽管你可能认为这是必要的一步（如果你希望坚持转义输出习惯的话）。实际上，这时是否转义基本上不会产生影响，因为这时没有特殊字符需要转换。在防止SQL注入这一点上，参数化查询语句为你的程序提供了强大的保护。

 

  译注：关于SQL注入，不得不说的是现在大多虚拟主机都会把magic_quotes_gpc选项打开，在这种情况下所有的客户端GET和POST的数据都会自动进行addslashes处理，所以此时对字符串值的SQL注入是不可行的，但要防止对数字值的SQL注入，如用intval()等函数进行处理。但如果你编写的是通用软件，则需要读取服务器的magic_quotes_gpc后进行相应处理。

 以上就是PHP安全-SQL 注入的内容，更多相关内容请关注PHP中文网（www.php.cn）！