脆弱性が悪用される前に

Webアプリの入力検証不備──4つの実例とその対策

Webアプリケーションの入力検証に不備があると、セキュリティ上の深刻な弱点になる恐れがある。しかもこうした不備は、問題が起こるまで気付かれないことが多いものだ。

公開 2009年11月16日 07時30分

更新 2012年09月04日 17時39分

著者

Kevin Beaver

[TechTarget]

印刷する

　Webアプリケーションの入力検証に不備があると、セキュリティ上の深刻な弱点になる恐れがある。しかし、こうした不備は、得てして問題が起こるまで気付かれない。本稿では、わたしがWebアプリケーションのセキュリティ評価を行った際に見つかった入力検証の不備の例を幾つか紹介しよう。

ログインIDが含まれたURL

　これまでで最も興味深い入力検証の問題を見つけたのは、自分のさまざまな機密情報を保存していたWebサイトだった。ある日、そのサイトを眺めていて、自分専用のログインIDがURLに含まれていることに気付いた。これはWebサイトの最も基本的な、しかし危険な欠陥の1つだ。わたしは「彼らは分かっていないに違いない」と考えた。そこでサイトの管理者に電話で連絡を取り、問題を報告した。彼女は最初は平然としていた。彼女の態度が変わったのは、彼女がそのシステムの自分専用のIDをわたしに教えた後で、わたしが彼女の住所、誕生日、子どもたちの社会保障番号などの個人情報を次々に挙げてからだ。沈黙の後、彼女は「どうして分かったんですか」と尋ねてきた。わたしは、とても簡単なことだと話し、システムのどのユーザーも、アプリケーションへの入力を操作するだけで、ほかのユーザーの機密情報を見ることができる状態になっていることを説明した。彼女はあぜんとしたが、問題が悪用される前に見つかって感謝していると話した。「悪用される前」であったと願いたいものだ。

教訓

　ユーザーセッションを追跡し、ユーザーの再認証を経なければ、変数を変更するだけの入力操作を許さないこと。もっと良いのは、システム変数をURLに一切入れないことだ。

不正なURLの受け付け

　上の例のように、Webアプリケーションが不正なURLを受け付けて処理してしまう問題は、ほかにも見掛けたことがある。これは厄介なトラブルに直結しかねない問題だ。例えば、ユーザーが以下のようなリクエストにより、ローカルOSのコマンドをURLの一部として指定すると、ディレクトリの一覧を入手したり、UNIXやLinuxのパスワードファイルなど、機密情報を含むOSファイルをダウンロードしたり、URLやサイトをリダイレクトしたりできてしまう場合がある。

www.example.com/folder/?D=|dir
www.example.com/folder/whatever.cgi?I=/../..//..//etc/passwd
www.example.com/exit.asp?URL=http://www.example.net

　こうした不正なURLが処理された場合、結果はご想像の通り。ビジネスにダメージを与えてしまう。

教訓

　URLパラメータを含めて入力が適切に検証、フィルタリングされ、アプリケーションが想定内の入力のみを受け付けるようにすること。

連絡フォームの不備

　Webでの入力検証のよく見掛けるもう1つの欠陥は、連絡フォームに関連している。前述の問題とは異なり、この欠陥は、アプリケーションに関連する機密情報を脅かしはしない。しかし、アプリケーションやサーバ、電子メールボックスに対するサービス妨害（DoS）攻撃を招いてしまう恐れがある。わたしが評価を行うサイトやアプリケーションの9割に対しては、自動化されたWeb脆弱性スキャナを使って、連絡フォームによる問い合わせを膨大に送信できるだろう。送信されたフォームには通常、でたらめな内容と電子メールアドレスが記入されており、しかもこれらのフォームのために、システムログファイルが満杯になってしまう。こんなことはあなたの環境で起こってほしくないだろう。

教訓

　提出されるフォームをフィルタリングするか、あるいは絞り込むこと。セッション管理やWAFなどによりそうする方法はいろいろある。シンプルさを優先するのであれば、この課題は、CAPTCHAを利用して解決するのが一番簡単だ。

クロスサイトスクリプティングとSQLインジェクション

　最後に、入力検証について考える上で外せないクロスサイトスクリプティングとSQLインジェクションについて見よう。

　攻撃者がクロスサイトスクリプティングの欠陥を悪用するには、入力データをフィルタリングしないフォームが使われている必要がある。Webセキュリティ評価プロジェクトで、こうしたフォームを含む幾つかのページを発見しないことはほとんどない。わたしの経験では、これらの欠陥は、コードに関連しているものもあれば、Webサーバ側の仕掛けに由来するものもある。後者の欠陥が特に目立つWebサーバが「Apache」だ。欠陥が悪用される場合、基本的に、ユーザーは攻撃者に誘導され、攻撃者が作ったスクリプトコードを含むリクエストを、欠陥のあるWebアプリケーションに送る。アプリケーションはリクエストを処理し、このスクリプトコードを含んだHTMLをユーザーのブラウザに返す。ブラウザはこれを実行してしまう。こうしてクロスサイトスクリプティングが行われる。

　SQLインジェクションは、SQL文がフォームやURLに入力され、サーバがそれを処理し、抽出されたデータをユーザーに返すという点でクロスサイトスクリプティングに似ている。幸い、最近では、直接悪用可能なSQLインジェクションの脆弱性はめったに見ない。だが残念ながら、SQLインジェクションはいまだに多発しており、対策が十分に進んでいない。SQLインジェクションは、固有の注意点があるものの、入力検証の問題であることに変わりはない。

　クロスサイトスクリプティングとSQLインジェクションは、信頼できるWeb脆弱性スキャンツールでテストすることによってのみ、（少なくとも、現実的に）発見できるWebのセキュリティ上の重大な欠陥だ。修正するには、想定されている入力だけを受け付け、それ以外は一切受け付けないようにアプリケーションをコーディングしなければならない。簡単そうだが、アプリケーションによっては明らかに複雑な作業になる。いずれにしても、取り組んでいかなければならない。

編注：2009年11月20日

本記事に関して読者から問題があるとのご指摘をいただきました。以下のように補足いたします。

クロスサイトスクリプティング対策としては、出力時に特殊文字の置換などのエスケープ処理を行うことが有効です。必ずしも入力チェックだけで防ぐことはできません。

本稿筆者のケビン・ビーバー氏は、米アトランタにあるPrinciple Logicを経営する独立系情報セキュリティコンサルタントで、執筆、講演も手掛ける。専門は独立した立場からのセキュリティ評価。情報セキュリティに関する7冊の著書および共著書がある。ブログではIT専門家向けにセキュリティ関連の知識を提供している。

印刷する