2015年1月22日木曜日

SQLインジェクション対策もれの責任を開発会社に問う判決

1月13日に、北大の町村教授による興味深いブログ記事が発表されました。
この記事によると、SQLインジェクション脆弱性が原因でクレジットカード情報が漏洩した事件につき、ショップ側が開発会社を相手取り損害賠償請求の裁判を起こし、ショップ側が勝訴したとのことです。

判決はこのURLで読むことができます。以下、判例時報2221号に掲載された判決文も参照しながらエントリを書くことにします。

事実および裁判所の判断

まずは、事実および東京地裁の判断を説明します。

登場人物は下記の通りです。
  • X株式会社: インテリア商材の通信販売を営む(原告)
  • Y株式会社: システム開発の会社(被告)

概要
X社が運営するECサイトに対して、外部からの不正アクセスにより、最大7316件のクレジットカード情報が漏洩した。X社は謝罪、対応、調査等の費用、売上減少による損害等に関して、Y社に対して、委託契約の債務不履行にもとづき1億円余りの損害賠償を請求、東京地裁に起訴した。結果、原告が勝訴し、東京地裁は約2262万円の損害賠償金を支払うよう被告に命じた(確定)。

時系列まとめ:
日時事実
2009年1月30日X社とY社が業務委託基本契約書を締結
2009年2月4日X社がY社にウェブサイト向け商品受注システムを発注(889万円余)
2009年4月15日ウェブサイト稼働開始。この時点ではクレジットカード情報はサーバーに保存せず
2010年1月26日X社は顧客のクレジットカード情報をX社の基幹システムに転送する旨の仕様変更をY社に発注(31万5千円)
2010年1月29日同引き渡し、稼働(この時点からカード情報がサイトDBに保存される)
2011年4月20日カード会社から原告にカード情報漏洩の可能性を伝える
2011年4月21日ECサイトのサービスを停止
2011年4月30日セキュリティを強化してサービス再開。クレジットカード決済は停止
2011年5月26日情報漏洩の旨を告知(アーカイブ
2011年8月23日原告は別会社に委託した新サイトに移転
2011年10月14日原告が東京地裁に告訴
2011年12月22日原告がマザーズ上場
2014年1月23日判決(概ね原告の勝訴、確定)

ポイントは下記の通りです。
  • X社(原告)はセキュリティ対策について特に指示はしていなかった
  • 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった
  • 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった
  • X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日)
  • X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった
  • 以下の脆弱性その他が認められた
    • システム管理機能のIDとパスワードが admin/password であった
    • 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイル公開)
    • SQLインジェクション
    • クロスサイトスクリプティング
    • ログにカード情報が保存されていた
    • DBに保存されたカード情報にはセキュリティコードも含まれていた

これに対して、東京地裁の判決は下記の通りです。
  • クレジットカード情報が漏洩した原因は複数考えられるが、脆弱性やアクセスログ、不正利用の状況からSQLインジェクション攻撃によるものと断定
  • セキュリティ対策についてX社からの指示はなかったが、Y社は必要なセキュリティ対策を講じる義務(債務)があり、それを怠った債務不履行がある
  • Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた
  • 損害賠償責任制限について
    • 損害賠償責任制限自体については認める
    • 契約書に明記はないが、故意あるいは重過失に起因する損害については責任制限の範囲外とする
    • 仕様書に記載はないがSQLインジェクション対策を怠ったことは重過失である
    • よって今回の事案は損害賠償責任制限には該当しない
  • 原告からの損害賠償請求のうち、おわびのQUOカード代や梱包発送費などの損害は全額認められたが、売上減の機会損失は6041万4833円の要求に対して、400万円のみが認められ、システム委託契約費用約2074万円に対しては、他社システムに移行後の利用料等(約27万円)のみが認められた
  • Y社がカード情報をDBに保存しない方式をX社に提案したにも関わらずX社がそれを採用しなかった件をX社の過失と認め、過失相殺3割が認定された
  • 瑕疵担保期間(1年)を超えていたが、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効(2015/1/22 22:30追記)
  • 結果、3131万9568円の損害を認定し、その3割を控除して、2262万3697円の損害賠償をY社に命じた

SQLインジェクション対策がY社の債務である理由を判決文より引用します。
そこで検討するに,証拠(甲14,25,29)によれば,経済産業省は,平成18年2月20日,「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において,SQLインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから,独立行政法人情報処理推進機構(以下「IPA」という。)が紹介するSQLインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと,IPAは,平成19年4月,「大企業・中堅企業の情報システムのセキュリティ対策~脅威と対策」と題する文書において,ウェブアプリケーションに対する代表的な攻撃手法としてSQLインジェクション攻撃を挙げ,SQL文の組み立てにバインド機構を使用し,又はSQL文を構成する全ての変数に対しエスケープ処理を行うこと等により,SQLインジェクション対策をすることが必要である旨を明示していたことが認められ,これらの事実に照らすと,被告は,平成21年2月4日の本件システム発注契約締結時点において,本件データベースから顧客の個人情報が漏洩することを防止するために,SQLインジェクション対策として,バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていたということができる。
感想は以下の通り
  • 発注者(原告)および受注者(被告)ともにグダグダの状況であった
  • 原告は発注者としての責務を果たしておらず、(ほぼ)すべての責任が被告にあるとの判断は、被告に厳しすぎると思う
  • とはいえ、被告もなんら「専門家としての責務」を果たしておらず、裁判所はこの点を重視した
  • 経産省およびIPAからの注意喚起が「専門家として当然はたすべき責務」の基準と判断された点に注目したい
  • 管理機能のID/パスワードが admin/password であった箇所を読んで、しばらく余韻にひたっていた
    ※ただし、被告はシステム引き渡し後に原告がパスワードを変更すると想定していたと主張

考察とまとめ

従来筆者は、経産省の「モデル取引・契約書」などを根拠として、「仕様書に明記されないWebアプリケーションの脆弱性に対する責任は発注者にある」との見解を持っておりましたが、同時に「判例があるわけではないので要注意」としていました(例: PHPカンファレンス2009の講演資料)。今回の東京地裁の判断は、開発会社の「専門家としての暗黙の責務」として、セキュリティ対策の責務(契約上の債務)があると認定した点で画期的なものと言えます。判例時報の記事によると、この判決は「確定」とありますが、下級審判決ですので、今後の事案でどのような判決となるかは分かりません。
また、SQLインジェクション脆弱性が(要求仕様に明記されていないにもかからわず)受注者の重過失であると認定した点にも注目する必要があります。今後は、開発会社は自衛のため、せめて「安全なウェブサイトの作り方」に載っている脆弱性くらいは、顧客から要求がなくても、対策しておくべきでしょう。
発注者の立場に話を戻すと、今回紹介したような判例があったとしても、脆弱性対策を発注仕様に盛り込むべきです。そもそも脆弱性がなく、侵入もされないことが望ましいことは言うまでもないからです。
また、原告は、20万円の追加対策を指示しなかったことを過失と認定され、過失相殺として損害賠償金額を3割減額されました。20万円ケチったために、1,000万円近く損したことになります。
このことから、開発会社側は、採用される見込みが薄くても、自衛策としてセキュリティ対策の提案はどんどんした方が良いということになります。提案した上で発注側が拒否すれば、責任を発注側に転嫁できる(可能性がある)からです。さらに、よくある損害賠償の制限条項が「重過失による場合は無効」と判断されましたので、法務的な対策もあわせて考える必要があるでしょう。

先にも書いたように、今回の判決は「開発会社には厳しいもの」と受け取りましたが、それは私は開発の現場に長くいたからであり、世間一般の常識からすれば、「専門家なのだからそれくらいやって当たり前」ということではないでしょうか。
契約論的な責任の所在は別として、SQLインジェクション対策は今や「やって当たり前」なのですから、開発サイドとしては、要求仕様にあってもなくても淡々とSQLインジェクションが混入しない作り方を実践すべきであると考えます。

追記(2015/1/22 22:30)

はてブコメントに瑕疵担保期間に関する言及がありましたので追記します。
東京地裁の判断は、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効としました。以下、判決文の該当箇所を引用します。
本件基本契約は,「乙は,委託業務の完了の後その成果物に瑕疵が発見されたとき,乙の責任において無償で速やかに補修のうえ納入を行うものとする。」(26条1項),「乙の保証期間は,特に定めるものを除き委託業務の完了の後1年間とする。ただし,乙の責に帰すべきものでない場合はこの限りではない。」(26条2項)と定めている。
以上の規定からすれば,本件基本契約26条2項は,被告による無償補修を定めた本件基本契約26条1項を前提とした規定であり,被告が無償補修する義務を負う期間を原則として委託業務の完了後1年間とすることを定めたものと解することができ,原告の被告に対する損害賠償請求権の期間制限を定めたものと解することはできない
これに対し,被告は,本件基本契約に基づく個別契約は請負契約としての性質を有し,請負契約では債務不履行責任の特則として瑕疵担保責任の規定が適用される以上,原告の本件請求も瑕疵担保責任の規定に従った請求というべきであるから,本件請求についても本件基本契約26条2項が適用される旨主張する。しかし,本件基本契約26条2項は,その文言上被告による無償補修期間を定めたものと解釈できることは前記説示のとおりであり,本件個別契約の性質が請負契約に当たるか,原告の請求が瑕疵担保責任に基づく請求といえるかといった点は,上記解釈に影響を与えるものではないから,被告の上記主張は採用できない。

2014年12月22日月曜日

『例えば、PHPを避ける』以降PHPはどれだけ安全になったか

この記事はPHPアドベントカレンダー2014の22日目の記事です 。

2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。
(1) プログラミング言語の選択
1) 例えば、PHPを避ける
短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。
セキュアプログラミング講座(アーカイブ)より引用
「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。

本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化してきたかを説明したいと思います。以下の二点について触れます。
  • PHPの安全でない機能の削除
  • PHPの安全性を高める機能の追加
一方、PHPの単純な脆弱性改修については原則として触れないことにします。
それでは、はじめましょう。

1.htmlspecialchars 文字エンコーディングチェックの改善(PHP5.2.5 2007/11/8)

2007年6月当時のhtmlspecialcharsは第3引数で指定した文字エンコーディングについて、ほとんど何もチェックしていない状態でしたが、PHP5.2.5になって、一部文字エンコーディングのチェックが追加されました。このあたりの詳しい状況は、私のエントリhtmlspecialcharsは不正な文字エンコーディングをどこまでチェックするかを参照ください。PHP5.2.5での対応は、なんとも中途半端なもので、「しないよりはマシだが抜けもあった(参照)」という、なんかPHPの悪いイメージに沿った対応でありました。
しかし、私のエントリが引き金となり、こちらで紹介したような議論が巻き起こり、最終的にはmoriyoshiさんによるとてもきっちりした文字エンコーディングのチェックがなされるようになりました(PHP-5.2.12 2009/12/17 )。
また、PHP-5.3までのhtmlspecialcharsの第3引数のデフォルト値はISO-8859-1(Latin-1)でしたので、文字エンコーディング指定を省略した場合は結局なにもチェックしないのと同じだったのですが、PHP-5.4(2012/3/1)でなんとこれが突然UTF-8に変更されます。これにより、「日本語等マルチバイト環境では第3引数を適切に指定しないと文字が表示されない(参照)」という荒業により、一挙に第3引数の指定が普及したものと思われます。
なんか、昔のPHPのゆるーい感じから、PHP-5.4のこの変更はスパルタンな感じがするほどであります。htmlspecialcharsに関する変遷を下記にまとめます。
  • PHP4.1.0  (2001/12/10) htmlspecialcharsに第3引数追加。ほとんど何もしていないに等しい文字エンコーディングチェック
  • PHP-5.2.5 (2007/11/8) 文字エンコーディングのチェックを強化…したけど抜けがたくさん
  • PHP-5.2.12 (2009/12/17) moriyoshiの神対応による厳格なチェックに
  • PHP-5.4.0 (2012/3/1) 第3引数のデフォルトが UTF-8 に変更

2. register_globalsが非推奨に(PHP-5.3.0 2009/6/30)

PHPの安全でない機能の筆頭格であったregister_globalsは、PHP-4.2.0(2002/4/22)ではデフォルトはオフになったものの、php.iniに指定すれば普通に使える状態でした。PHP-5.3に至り非推奨、すなわち使うと警告エラーとなり、PHP-5.4.0(2012/3/1)にて機能自体が削除されました。

register_globalsの危険な例を紹介します。
session_start();
if (isset($_SESSION['user'])) {
  $islogin = TRUE;
}
ご覧のように、セッション変数userにログインユーザ名を保存することで、ログイン中か否かを保持しています。
ここで、ログイン状態でなくても、クエリ文字列に islogin=1 と指定することでログイン状態になることができます。register_globalの機能により、変数 $islogin の初期値が "1" になるからです。

しかし、この脆弱性は、そもそもログイン状態を保持する変数 $islogin を初期化していないことが原因です。なので、「一見問題ないスクリプト」がregister_globalsのせいで脆弱になる例はないかと探してみました。
仮にスーパーグローバル変数$_SESSIONがregister_globalsによって外部から変更できるとすさまじく危険ですが、それはできないように保護されています。しかし、$_SESSIONが出来る前に使われていた session_register() 関数を使う仕組みだと、セッション変数を外部から設定できる場合があります。そのような例を示します。
session_start();
session_register('user'); // $user をセッション変数として宣言
if (! isset($user)) {
  die('ログインしていません');
}
// 以下ログイン中として処理
コメントにあるように、session_register('user'); は、$userがセッション変数である($_SESSION['user']に相当)と宣言するものです。
しかし、register_globalsが有効だと、新規のセッションの場合に限り、クエリ文字列 user=yamada 等とすることで、セッション変数 $user が外部から変更されてしまいます。PHP-4.1の頃だと、色々大変だったのでしょうね。

また、register_globalsではありませんが、parse_strという関数でregister_globals同等のことを実現しようとすると、$_SESSIONの上書きができてしまいます。詳しくはこちらを参照ください。
register_globalsについてまとめると以下のようになります。
  • PHP-4.2.0 (2002/4/22) register_globalsがデフォルトで off になる
  • PHP-5.3.0 (2009/6/30) register_globalsを有効にすると警告エラーになる
  • PHP-5.4.0 (2012/3/1) register_globalsが廃止される

3. マジッククォートが非推奨に(PHP-5.3.0 2009/6/30)

昔のPHPには、入力値を自動的にSQLエスケープするという機能(マジッククォート)がありましたが、PHP-5.3で非推奨になり、PHP-5.4で廃止されました。
マジッククォートに関しては、PHPの公式マニュアルに妥当な説明があるので参照してください。
上に付け加えることはあまりありませんが、敢えて言えば、
  • マジッククォートは入力時にエスケープ処理を自動的行う仕組みだが、エスケープ処理は文字列を使う時に都度すべきという考え方が一般化した
  • マジッククォートはMySQLに特化したエスケープ方式であり、かつMySQLのオプションや文字エンコーディングを考慮しない不完全なエスケープだった
ということで、廃止になったのは妥当な判断だと考えます。
  • PHP-5.3.0 (2009/6/30) マジッククォートを有効にすると警告エラーになる
  • PHP-5.4.0 (2012/3/1) マジッククォートが廃止される

4.暗号学的に安全な擬似乱数生成器のサポート(PHP-5.3.0 2009/6/30)

昔はPHPに暗号学的に安全な乱数生成関数がサポートされておらず、以下の関数でトークンやらセッションIDなどが生成されるという状況でした。
  • uniqid()
  • rand()
  • mt_rand()
これらは暗号学的に安全な乱数生成器ではないので、セキュリティ用途に使ってはいけません。中でも、uniqid()は乱数ですらなく基本的には時刻を元にしたIDですが、これを追加オプションなしでセッションID生成に使っている実装を見たことがあります。

PHP-5.3.0から、openssl_random_pseudo_bytes という、とても長い名前の関数により安全な擬似乱数が生成できるようになりました。但し、使用にあたっては以下の条件があります。
  • PHP-5.3.0以降であること かつ
  • OpenSSLが導入されていること
どちらか一方でも上記を満たさない場合は、安全な乱数のソースとして/dev/urandom等を使うことになります。

5.セッションID生成の安全性強化(PHP-5.3.2 2010/3/4)

PHPのセッションID生成は、元々暗号的な根拠を持っておらず、PHP-5.3.2で一応の改善があったものの、計算の複雑性を増すことで推測を少し難しくしたというレベルであり、暗号学的な根拠があるものではありませんでした。拙著を書くときにも扱いに苦労した記憶があります。結果として、拙著P163に以下のように書きました。
(PHPのセッションID生成は)図4-51で示したありがちなセッションIDの生成方法に該当します。ロジックの複雑性が高いため解読方法が判明しているわけではありませんが、理論的には安全性が保証されていない設計ということになります。
上記には「解読方法が判明しているわけではありませんが」とありますが、これを調べた人がいて、hnwさんが素晴らしい翻訳で紹介してくださっています。
現実的なリスクは低いものの、ちょっと心配ですよね。このため、(執筆当時は上記論文は知らなかったものの)私は以下のように推奨しました。
しかし、php.iniの設定を追加することで、安全な乱数を元にセッションIDを生成するよう改善できます。そのためには、php.iniに以下を設定します。
[Session]
;; entropy_file は Windowsでは設定不要
session.entropy_file = /dev/urandom
session.entropy_length = 32
そして、PHP-5.4.0からは上記設定が標準のデフォルト値となりました。まさか私の本を読んで、ということはないと思いますが、結果として取り入れてくださると嬉しいですよね。
  • PHP-5.3.2 (2010/3/4) セッションIDの生成方法を複雑化したが不完全
  • PHP-5.4.0 (2012/3/1) セッションIDのシードに安全な乱数を使うように改善

6.ヌルバイト攻撃の防御機能の追加(PHP-5.3.4 2010/12/9)

よく知らているように、PHPの機能・関数にはバイナリセーフのものとそうでないものが混在しているため、ヌルバイト攻撃という攻撃手法が成立していました。
典型的には、ディレクトリトラバーサル攻撃の際に、プログラム側で拡張子を付加してい場合でも任意の拡張子ファイルのアクセスができるようにする方法です。具体的には、../../.../../../etc/passwd%00というファイル名を指定することで、%00(ヌルバイト)が文字列の終端になり、それ以降の拡張子(.txt等)が無視されるというものです(bloggerの制限のため%を全角で書いていますが、実際には半角です)。
PHP-5.3.4では、言語構造及び関数の一部で、ファイル名にヌルバイトがあるとエラーになるように改良されました。詳しくは以下の素晴らしいエントリを参照ください。
ヌルバイト攻撃ができなくなっても、ディレクトリトラバーサル攻撃やファイルインクルード攻撃の対策は引き続き必要ですが、万一対策が漏れていた際の保険的な対策になります。

7.PDOのDB接続時の文字エンコーディング指定が可能に(PHP-5.3.6 2011/3/17)

昔は、PDOを用いる際にDB接続の文字エンコーディングを簡単には指定できないため、SQLインジェクション脆弱性の可能性がありました。具体的には、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)で指摘したように、Shift_JISでMySQLに接続している場合に、エスケープ処理やプレースホルダを使っていても、SQLインジェクション脆弱性が混入する場合がありました。
PHP-5.3.6以降にて、DB接続時に下図のように文字エンコーディングを指定できるようになりまた。
 $dbh = new PDO('mysql:host=DBHOST;dbname=test;charset=utf8', USERNAME, PASSWORD);
詳しくは以下のエントリを参照ください。
なお、Windows版のPHP-5.3.6には初歩的なバグがあり、PHP-5.3.7で修正されました。
ところが、このPHP-5.3.7には重大な脆弱性が混入してしまいました。次項に続きます。

8. crypt関数の重大な脆弱性混入とXFAILの運用(PHP-5.3.8 2011/8/23)

PHP-5.3.7にはcrypt関数に重大な脆弱性があり、MD5ハッシュを選択した際に肝心のハッシュ値が出力されないという問題が混入してしまいました。バグの詳細と混入の経緯については以下の記事を参照してください。
バグ混入の背景は以下の記事が参考になります。
上記の記事にもありますが、PHPの開発では、バグが採択された場合まずテストを書くことから始めるため、未対応のバグについて、大量のFAILが残ったままになり、対処が必要なFAILが埋もれて見落としてしまったようです。
これに対して、「将来修正するけど今はFAILを容認している」バグについては、FAILとは別に、XFAIL(eXpected FAIL)とすることで、見落としをなくそうということになりました。実際にはXFAILの機能自体は当時から既に組み込んであったようですが、XFAILの運用をきちんとやろうという意味でしょう。
実は、PHP-5.3.7の前にも、PHP-5.2.7にも重大なやらかしがあって、PHP-5.2.7は欠番になっています。そのため、PHP-5.x.7は地雷?ということで、PHP-5.4.7やPHP-5.5.7が出る際にも「また何かあるのではないかと期待不安」があったのですが、さすがにそういうことはありませんでした。PHP-5.3.7の失敗以降、大きなヤラカシはなくなったのではないでしょうか? これは良かったと思いますし、PHP-5.3.7のcryptのバグも幸い大きな実害にはつながらなかったようです。

9. header関数のバグ修正(PHP-5.4.0 2012/3/1)

PHPのヘッダ関数は、5.1.2(2006/1/12)でHTTPヘッダインジェクション対策として以下の修正がありました。
この関数は一度に複数のヘッダを送信できないようになりました。 これは、ヘッダインジェクション攻撃への対策です。
header関数マニュアルより引用
しかしこの修正に抜けがあり、改行を構成する2種類の文字キャリッジリターン(0x0D)とラインフィード(0x0A)のうちラインフィードの方しかチェックしておらず、キャリッジリターンのみでHTTPヘッダインジェクション攻撃ができてしまう状態でした。
その旨を私の本にも書いていたところ、PHP-5.4.0にて廣川類さんが修正してくださいました。
PHPスクリプトに対してHTTPヘッダインジェクション攻撃を掛ける経路としては、header関数のほか、setcookieとsetrawcookieを使う可能性が考えられますが、この修正でいずれの関数でもHTTPヘッダインジェクションはできなくなったはずです。

10. 安全なパスワード保存が簡単にできるようになった(PHP-5.5.0 2013/6/20)

password_hash関数の新設により安全なパスワード保存が楽に行えるようになりました。以下のように使用します。
$password = ...
$hash = password_hash($password, PASSWORD_DEFAULT);
生成されるハッシュ値の例は下記のとおりです。パスワードが同じでもソルトが毎回変わるので、呼び出しの度に異なるハッシュ値になります。
$2y$10$KDeRvOFZVPtVVm/Qo8DhA.XZ85u9mPmIqj3CHXCD2QZxeop617Wy2
上記の呼び出し例では指定していませんが、ストレッチングの強度を指定することもできます。デフォルトは10(ストレッチ回数ではありません)です。
パスワードの悪用が問題になっている昨今の状況を考えると、password_hashの採用はぜひ検討したいものです。

11. Session Adoption Bugの修正(PHP-5.5.2 2013/8/15)

PHPには従来からセッションIDとして勝手な値(例: PHPSESSID=ABC)をつけてもそれを受け入れてしまうという問題(Session Adoption)が指摘されていました。PHP開発陣はSession Adoptionはない方がいいが重大な問題ではないと認識していたようで長らく放置されていましたが、PHP-5.5.2にて修正されました。ただし、デフォルトは従来通りで、php.iniにて session.use_strict_mode = On を指定する(strict sessions)と、PHP側で用意したセッションIDのみを使うようになります。
詳しくは以下のエントリを参照ください。
また、Session Adoptionに関連して、セッションIDの固定化攻撃にどう対処するかについては、以下を御覧ください。

まとめ

IPAから『例えば、PHPを避ける』と書かれた2007年6月以降、PHPの安全性がどの程度強化されたかを調べました。思い返すと色々あったなぁとは思うものの、PHP-5.3.7のcryptの以降は、(PHP-5.5.2のStrict Sessionsはご愛嬌として)大きな「やらかし」は発生していないように思います。
また、PHP-5.3以降では、明確に過去の悪い習慣と決別する姿勢を示しているように思えます。昔のイメージだけで「PHPは危険」と言われてしまうのは、ちとかわいそうな気がします。
ということで、最近のPHPの安全性はかなり向上していると言えますが、むしろ、現在のPHPのセキュリティ運用上の問題は、バージョンアップが頻繁なために追随することが難しいことではないでしょうか? これを避けるためには、CentOS等のLinuxディストリビューションのパッケージとしてPHPを導入して、適切にパッチ適用する方法などが考えられます。

2014年11月7日金曜日

自宅の鍵を定期的に取り替える佐藤君(仮名)の話

パスワードの定期的変更について元々違和感を持っています。今まで、理詰めでその違和感を解明しようとしてきましたが、それでも私の頭のなかのもやもやをうまく説明できたわけではありません。そこで、パスワードの定期的変更を「自宅の鍵を定期的に変更する比喩」を用いて、そのもやもやを説明したと思います。比喩によって精密な議論ができるとは思っておりませんので、あくまでも主観的な「もやもや」を説明する方便として読んでいただければ幸いです。ここに登場する佐藤は架空の人物です。

徳丸: 佐藤君は自宅の鍵を定期的に取り替えていると聞いたんだけど、本当?

佐藤: 本当ですよ。毎年に替えています。毎年年末に鍵を取り替えて、安心な気持ちで新年を迎えるんです。徳丸さんは替えてないんですか?

徳丸: 替えないよ。鍵を落としたりしたらまた別だけど、そういうのでもなければ替えないよね。佐藤君はなぜ毎年替えるの?

佐藤: だって心配じゃないですか。

徳丸: 何が?

佐藤: 僕の知らないうちに合鍵が作られているかもしれないじゃないですか?

徳丸: 証拠でもあるの?

佐藤: 証拠はありません。でも、たとえば彼女が部屋に来るのに僕が留守だなんて場合に、郵便受けに鍵を入れておいたりするんで、誰かがこっそり鍵をとって合鍵を作っているかもしれません。

徳丸: そんな運用しなければいい。

佐藤: たとえば、ですよ。リスクをゼロにはできません。

徳丸: で、誰かが合鍵で部屋に入った兆候でもあるの?

佐藤: 今のところありません。

徳丸: だったら、そういう兆候が見つかったら替えたら?

佐藤: 徳丸さん、そんな意識でいいんですか? 万一の場合にも備えないとダメです。

徳丸: そうはいうけど、一年に1回変えるのでは、最悪ケースだと約一年間は合鍵で部屋に入られるわけでしょ。

佐藤: それはそうですが、永遠に入られ続けるよりましです。

徳丸: 悪い奴は、部屋に侵入されたら即座に部屋のものを盗んでいくんじゃないの?

佐藤: それは分かりません。僕の大事な情報だけ盗んでいくかもしれません。

徳丸: でも、何回も盗みに来るかね? 鍵を変えた後には、もう盗むべき情報はないのでは?

佐藤: 毎日仕事をして、生活をしていれば、その間に秘密情報も増え続けるんですよ。

徳丸: それは犯人にとって価値のある情報かな?

佐藤: それは分かりませんが、ひょっとしたら価値があるかもしれないじゃないですか。

徳丸: まぁ、そうだね。じゃあ、兆候が見つけられないんだったら、誰かが部屋に入ったらセンサーが作動するようにしたら?

佐藤: そうか、センサーがあれば、別人が部屋に入ったらわかりますね。

徳丸: そうそう、そうしなよ。

佐藤: 分かりました。そうします。


佐藤は自宅に侵入検知のセンサーを取り付けて運用を開始した。それから2年が経った。

徳丸: やぁ、佐藤君、久し振りだね。その後どう?

佐藤: いやぁ、相変わらずですね。

徳丸: センサーの調子はどう? 誰か入ってきた?

佐藤: センサーはちゃんと動いているようです。別人が侵入した兆候はないですね。

徳丸: なら、鍵を取り替える必要もなくなったね。

佐藤: いや、念のため、昨年末に鍵を替えました。

徳丸: え゛っ、なぜ?

佐藤: だって、心配じゃないですか?

徳丸: センサーまでつけたのに?

佐藤: 徳丸さん、考えてみたんですよ。誰も侵入していないとしても、合鍵を作られていない証拠にはなりません。

徳丸: どうして?

佐藤: 犯人は合鍵を作ったけれども、すぐに使わずに侵入するタイミングを伺っているかもしれないじゃないですか。

徳丸: それはそうだけど、そんな悠長なことするかね?

佐藤: それは分かりません。私は悪い奴の気持ちはわからないですが、そうしないという証拠はありません。

徳丸: うーん、合鍵を作られたけどすぐには悪用しないというケースを想定するのであれば、鍵の取り替えで対応するには、一年に1回とかでは不十分だと思うよ。

佐藤: やはり、毎日鍵を替えないとだめでしょうか?

徳丸: そんなの現実的ではないよね。

佐藤: あー、心配だ。どうすればいいんだ。

徳丸: 合鍵が心配だったら、ICカードキーとか生体認証を併用して二要素にしたらいいのでは?

佐藤: 二要素にしたら費用が掛かるし、毎日の鍵の開け閉めが面倒くさいじゃないですか。

徳丸: いやいや、佐藤くんがそこまで心配するなら、そうすべきだと僕は思うけどね。

佐藤: …(徳丸と佐藤の会話はまだまだ続く)


「侵入検知センサー」はパスワードの場合はログインアラートに相当します(参照)。
心配症の佐藤君の考え方が、そのままパスワードの定期的変更に当てはまると主張しているわけでありません。そこは精密な議論が必要ですが、私の主観的なもやもやの中身の一部は、上記の対話の比喩で説明できるのではないかというお話です。

2014年11月4日火曜日

ログインアラートはパスワード定期的変更の代替となるか

パスワードの定期的的変更には実質的にはあまり意味がないのではないかという議論(疑問)から出発した議論を続けておりますが、こちらなどで表明しているように、パスワードの定期的変更が効果をもつ場合もあります。
そこで、本稿ではパスワードの定期的変更の代替手段としてログインアラートの運用に着目し、ログインアラートの運用がパスワードの定期的変更の代替となるのか、残る課題は何かについて検討します。

パスワード定期的変更の効果まとめ

まず前提条件について説明します。ウェブサイトAの利用者xが自身のパスワード voc3at を定期的変更として変更する(voc3atはあくまで例です)場合、これが効果を発揮する条件と効果は、以下と考えられます。条件1と条件2はAND条件です。
  • 条件1: パスワード voc3at が既に漏洩していて、今後悪用される可能性がある
  • 条件2: パスワード漏洩に利用者 x は気づいておらず(あるいは気づいたにも関わらず)、パスワードを(非定期には)変更していない
  • 効果: パスワードの定期的変更後、サイトAにおける パスワード voc3at の悪用はできなくなる
条件1のパスワード voc3at が漏洩する経路については制約はありませんが、以下の様なケースが考えられます。
  • サイトAからパスワード漏洩が起こった
  • 利用者 x がパスワード voc3at を別のサイトBでも利用していて、サイトBから漏洩した
  • 利用者 x 自身がパスワード voc3at を別人に教えてしまった
  • 利用者 x がフィッシング詐欺にあってしまい、パスワード voc3at が漏洩した
条件2に関して、利用者が気づく局面の例としては以下があります。利用者が気づかない状況とは、以下のいずれにも該当しないケースです。
  • LINEのアカウント乗っ取りのように、利用者 x 自身は利用できなくなったり、友人が教えてくれる
  • 不正送金被害にあい、銀行口座から預金がなくなってしまった
  • なりすまし投稿により自身のアカウントが炎上してしまった
  • サイトAがパスワード漏洩事件を公表し、パスワード変更を呼びかけた
  • ログイン履歴を見ていて気づいた

ログインアラートとは

ログインアラート(ログイン通知とも)とは、誰か(利用者自身も含むが第三者かもしれない)がサイトにログインした際に、その旨を登録済みメールアドレスに通知する機能です。多くのサイトではログインに成功した場合に通知しますが、LINEウェブストアに関しては、ログインに失敗しても通知します。
以下は、楽天のログインアラートのメール例です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【楽●天】ログインアラート通知(2014/10/20 09:53)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

xxxxxxxx 様

お客様が楽天のサービスにログインしましたので、お知らせいたします。
このメールはログインアラート設定を行っているお客様に
送信させて頂いております。

◆ログイン情報
・ログイン日時 :2014/10/20 09:53
・IPアドレス   :xxx.xxx.xxx.xxx

◆ログイン履歴
https://history.id.rakuten.co.jp/
よりログイン履歴がご確認いただけます。

◆心当たりのないログインの場合
お客様以外の第三者がお客様に成りすましてログインしている可能性があります。
その場合、次のURLより会員情報管理画面にてパスワードを
変更されることをおすすめします。
https://member.id.rakuten.co.jp/rms/nid/menufwd
利用者は、ログインしていないのにこのメールを受け取った場合、別人が自分のアカウントでログインしていることを疑い、IPアドレスを確認した上で必要に応じてパスワードを変更することになります。

※注: 楽天のログインアラートメールには、このパスワード変更のURLが記載されていますが、このURLにアクセスすると楽天のログイン画面になるわけで、ログインアラートがフィッシングに悪用される懸念を考えると、メールの文面は悩ましいところではあります。

ログインアラートの効果

パスワードの定期的変更とログインアラートは、どちらもパスワードが漏洩してからの事後の緩和策と位置づけることができますが、効果については微妙に異なります。
ログインアラートの利点は以下の通りです。
  • 不正ログインの事実を確認できる
  • 不正ログインの際の日時やIPアドレス等から犯人追跡の情報が得られる
  • 不正ログインから速やかな対処が可能
  • 不必要なパスワード変更をする必要がないので利用者側の負担が少ない
  • 実装上のコストは比較的低い

一方、ログインアラートではカバーできない状況として下記があります。

  1. パスワード漏洩後、なんらかの理由で数ヶ月後に犯人が初めてログインした
  2. サイトBから漏洩したパスワードリストを犯人が購入し、漏洩から数ヶ月後にサイトAで試した。利用者はサイトAとサイトBで同じパスワードを設定していた
  3. 利用者のリテラシーが低く、ログインアラートに適切に対処できない

1.に関しては、パスワードを得て「数ヶ月放っておく」動機があるのが問題になります。
2.に関しては、あり得るシナリオではありますが、サイトAに重要情報がるのであれば、やはりパスワードの使い回しを避けるほうが安全で、その方が総合的には手間も掛からないと考えます。
3.に関しては、ログインアラートに適切に対処できない人が自発的にパスワードの定期的変更をするとは考えにくいので、パスワードの有効期限を定めて強制的に変更させないと実効性がないでしょう。ただし、私自身はパスワードの有効期限のあるサイトは、できれば使いたくないと感じます。

ログインアラートはパスワード定期的変更の代替になるか

ログインアラートについて紹介し、パスワードの定期的変更運用の代替になるか(ログインアラートを適切に運用すれば、パスワードの定期的変更をしなくてすむか)について検討しました。
前述のように、ログインアラートは完全にパスワードの定期的変更の代替にはならないものの、残るリスクは比較的軽微であり、実用上はログインアラートがあれば、パスワードの定期的変更はしなくてもよいケースが多いのではないかと考えます。
もちろん、利用者側で心配であれば、ログインアラートに加えてパスワードの定期的変更もすればよいと思います。しかし、そこまで心配するのであれば、二段階認証など、さらに強固な認証手段を提供しているサイトを選択する方が良いと考えます。二段階認証を設定していれば、パスワードの定期的変更は必要ないでしょう。
今回私が二段階認証ではなくログインアラートに着目した理由は、前述したように実装コストが低く、利用者・サイト提供者共に負担が軽いからです。このため、不正ログイン事件が多発している現状において、最低限度のセキュリティ施策として、ログインアラートの実装の検討をおすすめします。

2014年10月25日土曜日

New Class of Vulnerability in Perl Web Applicationsの紹介

Redditを眺めておりましたら以下の記事が目に止まりました。
New Class of Vulnerability in Perl Web Applications
ざっくりというと以下の様な内容です
  • CGI.pmのparamメソッドの返り値をハッシュに突っ込んでいる箇所がある
  • クエリ文字列に同名のパラメータを複数セットすると、配列値が返る
  • 配列をハッシュに突っ込むことにより、別のキーの値が変更される
私はこの内容に興味を持ちましたので、以下に詳しく説明します。

PoC

元エントリにもPoCが出ておりますが、少し手をいれたものを以下に示します。
#!/usr/bin/perl
use strict;
use CGI;

my $cgi = new CGI;

my $loginname = 'smith';
my $password  = 'a3k!sz9';

my %user = ('login' => $loginname,
            'realname' => $cgi->param('realname'),
            'password' => $password);
print <<END;
Content-Type: text/plain; charset=utf-8

login = $user{'login'}
realname = $user{'realname'}
password = $user{'password'}
END
ご覧のように、キーとしてlogin、realname、passwordを取るハッシュを作成しています。loginとpasswordは定数(セッション変数などから取得する想定)、realnameはクエリ文字列realnameから取得します。

このCGIプログラムをクエリ文字列 realname=John+Smith で呼び出すと結果は下記となります。
login = smith
realname = John Smith
password = a3k!sz9
次に、以下のクエリ文字列で呼び出します。
realname=hoge&realname=login&realname=yamada
結果は以下となります。
login = yamada
realname = hoge
password = a3k!sz9
なんと、定数で指定しているはずのloginがyamadaに化けています。なぜでしょうか?

CGI.pmは同名パラメータ指定により配列を受け取ることができる

CGI.pmのparamメソッドは、以下のようにすると、配列の形でパラメータを受け取ることができます。
my @foo = $cgi->param('foo');
例えば、以下のクエリ文字列を指定した場合、
foo=1&foo=2&foo=3
@fooは 1, 2, 3を値にもつ配列となります。

ハッシュ生成時に配列を混ぜることでハッシュの別キーをインジェクションできる

PoCの%user の部分は以下のように呼び出されることになります。
my %user = ('login' => 'smith',
            'realname' => ('hoge', 'login', 'yamada'),
            'password' => 'a3!sz9');
Perlの場合、=>とカンマ(,)はほぼ同じ意味だそうで、上記は以下のように展開されます。私はPerlの細かい文法には自信が無いため、以下の部分の説明に誤りがあればご指摘ください。
my %user = ('login', 'smith',
            'realname', 'hoge', 'login', 'yamada',
            'password', 'a3!sz9');
整形すると、以下と同等です。
my %user = ('login' => 'smith',
            'realname' => 'hoge', 
            'login' => 'yamada',
            'password' => 'a3!sz9');
右辺は配列定義ですが、'login' => が2箇所あります。したがって、配列をハッシュに変換する際に、キーloginに対する値は、'yamada'に上書きされます。すなわち、以下と同等です。
my %user = ('realname' => 'hoge', 
            'login' => 'yamada',
            'password' => 'a3!sz9');
以上の手順により、$user{'login'}が本来smithであるところ、外部からの入力により、yamadaに変更させられました。

このようなケースはありえるのか?

上記のPoCのようなことが現実にあり得るかというと、ちょっと微妙な気はするものの、ないこともないかなという印象です。
たとえば、Web APIなどで、入力はurlencodedだけど出力はJSONであって、そのJSONを作る際にいきなりハッシュ定義に入力値を放り込んでいるケースなどです。
元記事のコメント欄には、ふつーバリデーションするだろというツッコミに対して、著者は、realnameは任意の文字を受け取るのでバリデーションは必要ないと答えています。しかし、制御文字などは弾く必要があるため、アプリケーション要件としても、最低限度のバリデーションは必要と考えます。

対策

この問題を避ける簡便な方法として、元エントリではrealnameの値をスカラーに変換する方法が紹介されています。
my %user = ('login' => $loginname,
            'realname' => scalar $cgi->param('realname'),
            'password' => $password);
あるいは、値をいったんスカラー変数で受けるという方法があります。これにより、realnameがスカラであることが保証されます。
my $realname = $cgi->param('realname');
my %user = ('login' => $loginname,
            'realname' => $realname,
            'password' => $password);

まとめ

前回のエントリでも説明したように、スカラ値を想定している入力が、実は配列やハッシュになっている可能性を想定して、スカラであることのチェック、あるいはスカラに変換する等の処理が必要な場合があります。
入力値のバリデーションをすれば脆弱性が顕在化することはありませんが、脆弱性が混入するその箇所で対策することを考えると、ハッシュに突っ込む箇所で、当該変数がスカラーであることが一目瞭然になっているのがよいでしょう。
そういう意味で、バリデーションによる対策をとらず、脆弱性の発生箇所での対策を主張されている元エントリの著者Gerv(Gervase Markham)さんとは、一緒に旨い酒が飲めそうだと感じましたw

2014年10月20日月曜日

DrupalのSQLインジェクションCVE-2014-3704について調べてみた

既に日本でも報道されているように、著名なCMSであるDrupalのバージョン7系にはSQLインジェクション脆弱性があります(CVE-2014-3704)。この脆弱性について調査した内容を報告します。

ログイン時のSQL文を調べてみる

MySQLのクエリログを有効にして、Drupaのログイン時に呼び出されるSQL文を調べてみます。リクエストメッセージは以下となります(一部のヘッダを省略)。
POST /?q=node&destination=node HTTP/1.1
Host: xxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Cookie: has_js=1; Drupal.toolbar.collapsed=0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 122

name=admin&pass=xxxxxxxx&form_build_id=form-xQZ7X78LULvs6SyB9MvufbZh5KXjQYRHS05Jl2uD9Kc&form_id=user_login_block&op=Log+in
ログイン時には複数のSQL文が呼び出されますが、以下のSQL文に注目します。
SELECT * FROM users WHERE name = 'admin' AND status = 1
次に、name=adminの部分を以下のように変更してみます。
name[]=user1&name[]=user2
生成されるSQL文は以下の通りです。
SELECT * FROM users WHERE name = 'user1', 'user2' AND status = 1
あれ、配列として渡したuserが、SQL文では、'user1', 'user2'とカンマ区切りで列挙されています。これはSQL文法違反となっていますが、DrupalのSQL文ジェネレータの機能で、配列のパラメータを自動的にSQLのプレースホルダに展開する機能があるのです。以下、こちらの記事のサンプルをお借りして説明します。

以下のようなdrupal APIの呼び出しを題材に用います。
<?php
db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2')));
?>
上記IN句に対して、プレースホルダは :name 一つだけ、バインドする値は2個あります。この場合、SQL文は以下のように自動的に改変されます。
SELECT * from users where name IN (:name_0, :name_1)
なんて便利なんでしょう! SQLインジェクション対策としてプレースホルダを使えと呼びかける際に決まって問題となる IN句の展開をやってくれていますね。つまり、バインド値を配列にする呼び出し方は主に IN句を想定したものであり、最初に見たname[]を複数指定する呼び出し方は、想定外といってよく、その結果として生成されるSQL文が文法違反となりました。
文法違反というだけでかなり嫌な予感がしますが、この予感は不幸にも的中します。

連想配列のキーを指定したらどうなるか

ここで元のログイン時のSQL文に戻り、今度はname配列にキー文字列をつけて呼び出してみましょう。以下のname[]配列を用います。
name[id1]=user1&name[id2]=user2
生成されるSQL文は以下の通りです。
SELECT * FROM {users} WHERE name = :name_id1, :name_id2 AND status = 1
一見筋の通った処理に思えますが、キーに空白があったらどうなるでしょうか?
name[1 xxxxx]=user1&name[2]=user2
生成されるSQL文は下記となります。
SELECT * FROM {users} WHERE name = :name_1 xxxxx, :name_2 AND status = 1
あれあれ、プレースホルダがちぎれて、:name1と xxxxx に分かれてしまいました。これはもちろん文法違反ですが、実は呼び出す前にエラーになります。
この際のバインド値は以下の通りです。
array(2) {
  [":name_1 xxxxx"] => "user1"
  [":name_2"] =>  "user2"
}
SQL文中には :name_1 というプレースホルダがありますが、バインド値の配列には :name_1がありません。このため、PDOの動的プレースホルダが値をバインドできず、呼び出す前にエラーになるわけです。
それでは、エラーにならない方法はあるでしょうか? あります。:name_2 はあるわけですから、最初のプレースホルダ側でも :name_2 を使ってしまえばよいのです。
今度は、以下のname[]値で呼び出してみます。user1は使われないので削除しました。
name[2 xxxxx]=&name[2]=user2
生成されるSQL文
SELECT * FROM {users} WHERE name = :name_2 xxxxx, :name_2 AND status = 1
SQL文の中で使われているプレースホルダは :name_2 のみとなりました。この際のバインド値は以下の通りです。
array(2) {
  [":name_2 xxxxx"] => ""
  [":name_2"]=> "user2"
}
キー :name_2 はあるので、SQL文は呼び出されるはずです。ログを見ると、以下のSQL文がみつかります。
SELECT * FROM users WHERE name = 'user2' xxxxx, 'user2' AND status = 1
呼び出されていますね。ただし、xxxxxの部分でSQL文法違反となっているので、MySQL側でエラーになり、実行はされません。このxxxxxを文法違反にならないように辻褄をあわせてやると、SQLインジェクション攻撃ができます。

SQLインジェクションを試す

いよいよSQLインジェクションです…が、まだ発表されたばかりの脆弱性ですので、実害のあるものは避けて、10秒待つだけのSQLを実行してみましょう。ということで、SELECT sleep(10) というSQL文を実行してみましょう。POSTパラメータは以下となります。
name[2 ;SELECT sleep(10) -- ]=&name[2]=user2
Burp SuiteのRepeater機能で実行した例を下図に示します。


図の右下に 10,079millisとあることから、10,079ミリ秒、すなわち約10秒待っていることがわかります。この際に呼び出されているSQL文は下記の通りです。
SELECT * FROM users WHERE name = 'user2' ;SELECT sleep(10) -- , 'user2' AND status = 1
実験に使用した環境はMySQLを使っていますが、SQLの複文が実行できていることになります。これは、DrupalがPDOを使っているためで、詳しくは以下のエントリを参照ください。

ソース上の脆弱性箇所

この脆弱性の発生原因は、ソース上では以下のexpandArgumentsメソッドにあります。
// includes/database/database.inc
protected function expandArguments(&$query, &$args) {
  $modified = FALSE;
  // $argsの要素から配列のみ処理対象として foreach
  foreach (array_filter($args, 'is_array') as $key => $data) {
    $new_keys = array();
    // $dataは配列であるはずなので、foreach 可能。 $i(キー)に注目
    foreach ($data as $i => $value) {
      $new_keys[$key . '_' . $i] = $value;
    }
    // $queryを改変 $new_keysのキーをarray_kesyでSQL文に混ぜていることが問題
    $query = preg_replace('#' . $key . '\b#', implode(', ', array_keys($new_keys)), $query);
    unset($args[$key]);
    $args += $new_keys;

    $modified = TRUE;
  }
  return $modified;
}
元のコメントはすべて削除して、簡単な説明をコメントとして追加しました。
先のPoCから呼び出される場合、$args['name'] に配列値が入っている場合、配列のキーが変数 $i 経由でなんのチェックもなくSQL文に流し込まれることが問題です。
この脆弱性が対策されたDrupal7.32では、内側のforeachは以下のように修正されています。
foreach (array_values($data) as $i => $value) {
$dataにarray_values関数を通すことで、キーを取り除くことにより対策しています。
これで一応脆弱性は対処されていると思いますが、最初の方で指摘したようにクエリ文字列nameを配列とした場合に、文法違反のSQL文が生成される問題は直っていません。
Drupalは必要最小限のバリデーションのみをしているように見えますが、クエリ文字列が(配列ではなくスカラの)文字列であることのチェックくらいはした方がよいと思います。これはアプリケーション要件として必要なチェックだと考えます。

この脆弱性による影響

SQLインジェクションによる一般的な影響はすべて可能性がありますが、とくにデータベースの改変による攻撃経路が重要であると考えます。詳細は伏せますが、管理者権限をうばったり、管理者権限のあるユーザを登録できることを実験で確認しています。
DrupalはCMSですので、管理者権限が得られた後は、ファイルをアップロードするなどして任意のPHPスクリプト実行なども可能になると考えます。既にさまざまな攻撃が実際に来ているようですので、早急の対策をおすすめします。

影響を受けるバージョンと対策

Drupal 7.xのみが影響を受けます。Drupal 7.32にて対策されているので、該当バージョンを利用の場合、早急のアップグレードを推奨します。
すぐにアップグレードできない場合は、WAFによる攻撃緩和も有効と考えられます。Drupal対応のシグネチャがなくても、既存のシグネチャによる防御が期待できます。ただし、シングルクォートを使わなくても攻撃は可能なので、WAFの性能次第というところはあります。

まとめ

Drupal 7.xのSQLインジェクション脆弱性について説明しました。このSQLインジェクション脆弱性は、SQL文を動的生成する際に、プレースホルダ中に誤って配列パラメータ中のキー値をなんのチェックもせずに混入させてしまったことによるものです。
配列パラメータのキーによる攻撃は結構あるパターンでして、以下のエントリでも説明しています。
O/RマッパーやSQLジェネレータを開発する場合は、パラメータが配列である場合や、配列のキーが指定された場合についもテストをしておくとよいでしょう。

2014年10月16日木曜日

パスワードの定期的変更はパスワードリスト攻撃対策として有効か

パスワードリスト攻撃の対策として、パスワードの定期的変更に意味があるのかという議論があります。私は(利用者側施策としては)実質意味がないと思っていますが、まったく意味がないというわけでもありません。
このエントリでは、パスワードの定期的変更がパスワードリスト攻撃に対してどの程度有効かを検討してみます。

前提条件

パスワードリスト攻撃を以下のように定義します。
別のサイトから漏洩したアカウント情報(ログインIDとパスワードの組み合わせ)の一覧表(パスワードリスト)があり、そのログインIDとパスワードの組をそのまま、攻撃対象に対してログイン試行する攻撃
パスワードの定期的変更の一例として以下の条件を前提とします
  • 利用者は、すべてのサイトのパスワードを90日毎に変更する
  • 利用者はすべてのサイトで同じログインIDを用いている
  • 変更後のパスワードはすべてのサイトで同じとする
    ※ サイト毎にパスワードを別にすれば、それ以降はパスワードをまったく変更しなくてもパスワードリスト攻撃はできなくなるためこの条件を設定

攻撃条件(1)

攻撃者はサイトAから窃取したアカウント情報を直ちにサイトBに対して試行する場合

この場合、サィトAに登録されたIDとパスワードはサイトBでも有効なので、パスワードリスト攻撃が成功する。すなわち、パスワードの定期的変更に効果はない。

攻撃条件(2)

攻撃者はサイトAから窃取したアカウント情報を用いてサイトBを攻撃するが、アカウント情報は古いものであるとする。

※ アカウント情報が古いシナリオとしては、サイトAのパスワードがハッシュ値で保存してあったために解読に時間がかかった、あるいは攻撃者がパスワードリストを購入したが、最新ではなく古いものであった、などの可能性があります。

この場合、パスワードが漏洩してから攻撃があるまでの間に、パスワードが変更されていれば、パスワードリスト攻撃は成立しません。パスワードが変更される前であれば、攻撃は成立します。

評価

パスワードの定期的変更を実施していると、仮に全サイトで同じパスワードを設定していても、パスワードリストが古いものである場合、攻撃のタイミングによってはパスワードリスト攻撃を防ぐことが出来ることができます。パスワードリストの売買の報道例についてはこちらを参照ください。
それにも関わらず私が「実質意味がない」と思う理由は、どうせパスワードを変更するのであれば、そのタイミングで、サイト毎に異なるパスワードを設定すればいいじゃないかと思うからです。いったんサイト毎に異なるパスワードを設定しておけば、その後はパスワードを変更しなくても、パスワードリスト攻撃に関しては完全に防御することができます。

一方、パスワードの定期的変更では、「運が良ければ防げるが、防げない可能性も高い」という性質のものなので、利用者側の立場としてのパスワードリスト攻撃対策は以下の一点でよいと考えます。
  • サイト毎に異なるパスワードを設定する
他の攻撃に関しては、別の対策も併用する必要があります。
また、パスワードの定期的変更の、リスト型攻撃以外に対する効用については、以下のエントリを参照ください。

追記(2014/10/16 15:30)

@machuさんからコメントをいただきました。
『管理者側は違うパスワードは強制できないけど、定期変更は強制できる』という指摘は鋭い着眼ですね。そういえば、総務省の公表した『リスト型アカウントハッキングによる不正ログインへの対応方策について』では、「利用者にパスワードの定期的変更を求める」という表現ではなく、「パスワードの有効期間設定」となっていました。総務省の資料は、「サイト管理者などインターネットサービス提供事業者向け対策集」ということなので、このような表現になっているのだと思います。これに対する評価は以下の通りです。

  • パスワードの定期的変更は強制できる
  • 結果としてパスワードリスト攻撃への効果は限定的(ないわけではない)

ですが、パスワードの管理は本来は利用者側の責任であるわけで、そこにサイト運営者が介入する方向性としては、できるだけ利用者の負担増が少なく、かつ効果の高いものであるべきだと考えます。この点、「パスワードの有効期間設定」は、利用者の負担が大きく、かつ効果が限定的であるという点で、よくない施策であると考えます。













フォロワー