徳丸浩の日記[PR]EGセキュアソリューションズ株式会社はエンジニアを募集しています2009年3月27日金曜日JETエンジンにおいてパイプ記号「|」は今でも「危険」なのか補足この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブ、はてなブックマーク)。備忘のため転載いたしますが、この記事は2009年3月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。補足終わりSQLインジェクション対策の続きで、セキュア・プログラミング講座には、2種類の文字を不受理にせよと書いてある。「;」(セミコロン)と「|」(パイプ記号)だ。このうち、セミコロンについては不受理にする必要はなく、はっきり間違いといってよいだろう。『3)セミコロン「;」の拒否』の項ではセミコロンを用いた攻撃例も出ているが、脆弱性の原因はセミコロンではなく、シングルクォートをエスケープしていないところにある。バインド機構を用いるか、シングルクォートをエスケープすれば、セミコロンを恐れる必要は全くない。Serverの場合は、セミコロンなしでも複文を記述できることは前述した。原理的にも、現実的にもセミコロンの拒否は意味がない。パイプ記号の方はどうだろうか。長いが該当箇所を引用する。Jetエンジン)またMicrosoftのJetエンジンでは、次の文字も機能をもつ特殊記号として扱われる。Basicサブセット言語)のステートメントとして解釈し実行する。文の中の「'...'」で囲まれた文字列の中に書かれていても起こる。これを悪用すると外部からの任意のシステムコマンドの投入が可能となり、最悪の場合、システムが乗っ取られるおそれがある。このパイプ記号「|」をエスケープする方法は提供されていないため、パイプ記号「|」が含まれている入力パラメータは受理しないようにする必要がある。利用しているつもりがなくても、拡張子「.MDB」をもつデータベースファイルにアクセスする際に使われることになるので注意が必要である。[SQL組み立て時の引数チェック(アーカイブ)より引用]この内容は他の文書類ではあまり見かけない。私はACCESSおよびJetエンジンの実務での開発経験がなく、また脆弱性診断などでもお目に掛からないので、今までこの問題を検証しないできたのだが、念のため確認してみた。NTサーバ上におけるJetセキュリティ問題」がある。ODBCドライバ問題)の影響を受ける可能性がある。このセキュリティ問題の影響を受けるサーバプログラムに対し、悪意を持ったユーザが不正な入力を行なうことにより、サーバマシン上で任意のコマンドが起動する危険性が生じる。NTサーバ上におけるJetセキュリティ問題より引用]脆弱なサンプルと検証用文字列は以下のようになっている。2003を用いて、上記を検証してみたが再現しなかった。パイプ記号は特に不都合なく挿入も検索もできる。塩月氏のレポートから9年も経っているので、Microsoft社が対策したのだろうか。サブスクリプションを使用)。構成する方法などを参考にレジストリをいじったりしたが、やはり現象は再現しない。このように、現在の環境では「Jetセキュリティ問題」を再現するのは難しいようだが、過去このような問題があったことは確実なので、現在においても「いかなる環境でも絶対に安全」とは断言できない。このような状況下でセキュリティコンサルタントとしてどのようにアドバイスすべきだろうか。私がJetエンジンを今まで無視してきた理由は、同時に多数が利用するWebアプリケーション構築にJetのようなファイル共有タイプのデータベースエンジンを使用するのは好ましくないと考えるからだ。その方向で技術資料を探してみると、ぴったりそのままの文書が見つかった。アプリケーションで使用されることを考慮して設計されていません。等のセキュリティ、常時運用の可用性・信頼性、および拡張性を備えたデータベースの使用を推奨しています。引用]上記のようにMicrosoft自身がWebシステムでのJetの使用を推奨していないのだ。要求を行うと、予期せぬ動作が引き起こされる場合があり、システムの安定性に影響を及ぼす可能性があります。使用を弊社では推奨しています。スレッド環境を実装することはできません。使用した場合でも、応答がなくなるなど予期せぬ動作が引き起こされる可能性があります。スレッドセーフでない」という箇所が重要だ。このことから、Jetを使用したWebアプリケーションでは「別人問題」のように、他ユーザの情報が漏洩する可能性などが考えられる。「Jetセキュリティ問題」は過去の問題とは言い切れないかもしれないが、少なくとも現在では非常にトリビア的な問題だ。JetをWebシステムでは使うべきでないとMicrosoft自身が明記しているのだ。あれば、セキュア・プログラミング講座で説明すべきことは、「パイプ記号を受理しない」ではなく、こうだろう。本エントリを書いた後、セキュアプログラミング講座の内容は大きく改訂されたようで、ここで指摘した問題はすべて解消されている。関係者の皆様、ありがとうございました。