PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。
はじめに
本を書いています。SQLインジェクションの節から書き始めて、初稿はレビュアーの方々にお送りしましたところ、さっそく有意義なコメントを多数頂戴しています。ありがとうございます。
その原稿の中で、DBアクセスに使用するPHPのライブラリとしてMDB2を紹介していたところ、PDOを紹介すべきではという意見を複数頂戴しました。そこで、現時点でPDOを採用していない理由を報告したいと思います。これは、「安全なSQLの呼び出し方」でPDOを取り上げていない理由でもあります。
PDOは接続時に文字エンコーディングを指定できない（指定しても無視される）ので、データベースへの接続時の文字エンコーディングはLatin1が暗黙に指定されます。すると、日本語の読み書きで文字化けが生じるため、「SET NAMES SJIS」により、文字エンコーディングを接続後に指定するようなプログラミングがなされているようです（MySQLの場合）。
そのようなプログラム例を示します。このプログラムでは、内部文字エンコーディングとしてShift_JISを利用しているという想定です。PHP5.3.0とMySQL5.1.37の組み合わせで確認しました。
<?php
$dbh = new PDO('mysql:host=localhost;dbname=test;charset=sjis', 'username', 'password');
$dbh->query("SET NAMES sjis");
$sth = $dbh->prepare("select * from test WHERE name=?");
$sth->setFetchMode(PDO::FETCH_NUM);
$name = ...
$sth->execute(array($name));
while ($data = $sth->fetch()) {
var_dump($data);
}
PDO+MySQLの場合、プレースホルダは「動的プレースホルダ」あるいは、俗に「クライアントサイドのプリペアードステートメント」などと呼ばれる実装になっています*1。
このため、$nameとして「ソ' OR 1=1#」という文字列を指定した場合、MySQLに対して以下のようなクエリが送信されます（Wiresharkによるダンプ）。
0x83は「ソ」の先頭バイトです。これをPDOではLatin1(ISO-8859-1)として扱うので、0x83はNBHという制御文字を意味し、1バイト文字になります。PDOは、続く「\'」を「\\\'」とエスケープします。
一方、MySQLサーバー側では、受け取ったSQLをShift_JISと想定しているので「ソ\\'」という並びと解釈します。「\\」は「\」をエスケープしたものなので、後続の「'」は文字列リテラルの終端に使われ、残りの「 OR 1=1#'」はSQL文の一部とみなされます。SQL文が注入できたので、SQLインジェクション脆弱性があるということになります。ここまでの説明を下図にまとめました。
my.cnfの修正でもダメ
「set names」がセキュリティ上問題があることが広く知られるようになったせいか、PDOの文字化けを別の方法で対処するようにすすめているエントリもあります。たとえばこのエントリでは、my.cnf(my.ini)の修正でPDOの文字化けに対応しているのですが、Shift_JISを使う場合はこれもダメです*2。その理由は、「PDOはLatin1として処理したものを、MySQLはShift_JISとして解釈する」状態には変わらないからです。
まとめ
- PDO+MySQLでは、動的プレースホルダ（なんちゃってプリペアード・ステートメント）が使われる
- PDOでは文字エンコーディングが指定できない
- PDO+MySQL+Shift_JISでは、プレースホルダを使ってもSQLインジェクション脆弱性となる
解決策・回避策
PDOの文字化け問題とSQLインジェクション脆弱性問題を解決するにはどうすればよいでしょうか。私が思いつくのは以下の2つの方法です。
- PDOではなくMDB2など文字エンコーディングを正しく扱えるライブラリを使用する(根本的対策)
- アプリケーションからDBまで一貫してUTF-8で処理し、set names utf8により文字化けを回避する(回避策)
2.で具体的な問題が起こるかどうかは分かりませんが、文字エンコーディングを正しく扱えないことで潜在的なリスクがあると考えます。そのため、書いている本の中では1.を採用したという訳です。
しかし、私自身PHPを熟知しているわけではないので、ひょっとすると、PDOの使い方などでもっとよい方法があるかもしれません。識者のご指摘をいただければ幸いです。
追記(2010/07/01 21:30)
id:nihenさんが、PDOに対して文字エンコーディングを設定する方法を調べてくださいました。nihenさん、どうもありがとうございます。以下に引用します。
PDOからよばれるreal_escape_stringで文字コードを考慮させたい場合は
$dbh = new PDO('mysql:host=localhost;dbname=sandbox;charset=cp932', 'sandbox', 'sandbox', array(
PDO::MYSQL_ATTR_READ_DEFAULT_FILE => '/etc/mysql/my.cnf',
PDO::MYSQL_ATTR_READ_DEFAULT_GROUP => 'client',
));
もしくはserver-side-prepareを使う場合(文字コード気にしなくておｋ)
$dbh = new PDO('mysql:host=localhost;dbname=sandbox;charset=cp932', 'sandbox', 'sandbox', array(
PDO::ATTR_EMULATE_PREPARES => false,
));
ちなむと前者は接続時に使われるオプションなのでnew PDOしたあとにあとから
$dbh->setAttribute
しても、ダメ。後者はおｋ。
ご覧のように、MySQLサーバーへの接続時に、MySQL APIに渡すパラメータとして、my.cnfのファイル名を指定しています。上記の例ではGROUPを「client」に設定していますので、my.cnfに以下の設定を追加することになります。
[client] default-character-set=sjis
ただし、Windows版のPHPでは、PDO::MYSQL_ATTR_READ_DEFAULT_FILEが使えないようです。このため、サーバー接続時に文字エンコーディングを指定する方法がありません。このため、Windows版のPHPを使う場合は、PDO::ATTR_EMULATE_PREPARESをfalseにする(真のプリペアード・ステートメントを使う)ことで対策することになります。
*1 高木浩光氏のいわれる「なんちゃってプリペアド・ステートメント」
*2 元エントリはUTF-8なので問題はおきませんが、逆に言えば、set names utf8でも問題ないことになります
私自身も携帯電話でいくつかのサイトを巡回しており、その一つにtwitter.comの日本の携帯電話向けフロントエンドであるtwtr.jpも含まれる。ご存じのように、twitterは政府要人や有名人も数多く使っているし、twitter.comの画面で確認する限り、
一般ユーザ（被害者）からリクエストあり
①DNS情報書き換え → これ以降、ワナサイトは twtr.jpのIPアドレスを指す
・以下はIFRAME内の処理
②ログイン画面を要求 → 認証成功
③トークン取り出し → ログイン画面のINPUTにセット（写真2）
④ログイン実行 → セッションIDがCookieにセットされる（写真3）
・以下はIFRAME外の処理
⑤CookieをINPUTにセット
⑥Cookie値を情報収集サーバにPOST
以下は、攻撃者の立場
・セッションID受信を確認
・別の携帯電話にCookieをセット
・twtr.jpにアクセス → なりすましを確認
・書き込みをしてみる → 成功（写真4、写真5）
twtr.jpの脆弱性を悪用された書き込みなどは、私の知る限りは公表されていないようだが、脆弱性が修正された今でも油断はできない。仮に、攻撃者がなりすましを成功させていた場合、後から書き込みをする手段があるからだ。それは前述の「メールでツイート」機能を利用する方法だ。これは、その名の通りメール経由でtwitterの投稿をするもので、ユーザ毎の専用メールアドレスに文章を送信すると、その内容がtwitterに投稿される。右の写真は、私の「専用の投稿先メールアドレス」を表示させたものである。このメールアドレスはいつでも変更できるので、twtr.jpユーザは念のため変更しておいた方が良いだろう。
