多様化するWebアプリケーションへの攻撃：Webアプリケーションファイアウォールの必要性（2）（1/4 ページ）

» 2005年11月22日 00時00分公開

[草薙伸, 伴崇博，F5ネットワークスジャパン株式会社]

　第１回「機密情報に合法的に近づけるWebアプリケーションを守れ」では、「Unvalidated Input（許可されていない入力）」における「Hiddenフィールドマニピュレーション」の手法について説明した。いままでアプリケーションセキュリティに携わらなかった方にも、Webサイトが攻撃されるメカニズムが、意外に単純なものであることが理解してもらえたと思う。

　前回の内容に対して、周囲からいくつか質問をもらった。「こんなこと書いていいのか？」というものである。つまり、誰もが簡単に攻撃を行えることを示すことによって、かえって被害を増加させるのではないか、という懸念を持たれたわけだ。今回の記事では、より多くの攻撃手法を説明していくため、本論に移る前にこういった質問に回答しておきたい。

　私たちはすでに本連載で記しているような脅威の中にいる。それは、Webアプリケーションセキュリティに携わったことのある関係者各位にとっては周知の事実であろう。また、実際に攻撃を試みる者たちは、間違いなくこういった攻撃手法をすでに知っている。ここで紹介するような内容は、巧みに、複雑に組み合わせて実行される実際の攻撃手法から見れば「初歩の初歩」といってよい。

　事実、被害はすでにあらゆるところで発生している。だからこそ必要となるのは、まだWebアプリケーションの脅威に関して無知な人々に対する啓もう活動であり、防御方法の周知だと考える。この記事はWebアプリケーションの脆弱性に関する啓もうと、その防御に主眼を置く。

　今回取り上げるWebアプリケーションの脆弱性の一覧である。

パラメータタンパリング
Cookieポイズニング
Brokenアクセスコントロール
クロスサイトスクリプティング
バッファオーバーフロー
SQLインジェクション

自分の管理下にないWebアプリケーションに対して検査パターンを入力してはいけません。不正アクセス禁止法に抵触する恐れがあります。

本稿を利用した行為による問題に関しましては、筆者ならびにF5ネットワークスジャパン株式会社およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。

パラメータタンパリング（Parameter Tampering）

　今回、最初に取り上げるのは、Hiddenフィールドマニピュレーションと同じくパラメータの検証を十分に行わないことによって発生する「パラメータタンパリング」である。タンパリングとは“いたずらする”“勝手に変える”という意味だ。前回紹介したHiddenフィールドマニピュレーションもHidden属性で送られたパラメータ値を変更してしまうものであったが、こちらはURL内に埋め込まれたパラメータ値を改ざんする場合に使用される言葉である。

　GETメソッドを使用した場合、パラメータはURL内のクエリストリング（URLの「?」以降の部分）に埋め込まれる。クエリストリングはHTMLページ間で簡単にパラメータを受け渡しできるものとして、よく使用されるものだ。このクエリストリングに重要な情報を無防備に埋め込んでしまうことで脆弱性は発生する。以下のパラメータタンパリングの例を見てもらいたい。

図1 クエリストリングの末尾1桁を改ざんした例

　この例では、「userid=-20298745283」がクエリストリングにあたる。クエリストリングはURL内に含まれているため、誰でも見ることができる。従って、ユーザーのちょっとした出来心やいたずら（例えば「この数字の最後を1つだけずらせばどうなるかなー？」）によって、脆弱性が露見することも多い。

　この例であれば、誰が見ても明らかなように、「userid」のパラメータがユーザー管理に使用されており、数字を変えればほかのユーザーになりすませるのではないかと想定できるのだ。このクエリストリング内の情報を任意に書き換え、Webサイト管理者にとって想定外の結果を引き起こすのが、パラメータタンパリングである。

　パラメータタンパリングに併せて、クエリストリングに関する危険性についても触れておきたい。この例におけるパラメータが、ユーザー認証が行われた後、ユーザーが送信するURLのクエリストリングに付与されており、何度ログオンし直しても同じ値であった場合、ほぼ間違いなく固定のユーザーIDとして使用されている。こういう場合、通常Webアプリケーションは、ログオンごとに動的に生成されるセッションCookieを併用した設計となっている。

　このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。もっとも、クエリストリングに重要な情報を入れてしまうこと自体、以下の危険性が指摘できる。

Webブラウザのキャッシュ
Webブラウザの「戻るボタン」や「履歴」を使用すれば、そのPCを使用するユーザーの専用ページ内に認証なしでたどり着ける
リファラ（Referer）
Webブラウザが送るHTTPヘッダ内のリファラには、Webブラウザがリンクをクリックしたとき、それまで表示していたURLの情報が含まれている。つまり、次に表示するWebサーバに、それまで見ていたサイトのURLが知らぬうちに送られており、そこにはuseridが含まれている
プロキシやファイアウォール
Webブラウザと先方のサーバの経路上にあるプロキシサーバやファイアウォールなどのログにクエリストリングが残ってしまう

　このようにクエリストリングは極めて外部に露出しやすいものであり、クエリストリングにおける機密情報の受け渡しは慎重にならなければならない。外部への情報露出が、パラメータタンパリング発生の契機となる。

　アプリケーションの仕組み自体を変えることが可能であれば、POSTメソッドを使用することや、情報をCookieに埋め込むことにより、クエリストリングによる情報露出を防ぐ方法がある。しかしながら、利便性からクエリストリングは広く使用されている。アプリケーションの設計を変えることができず、WAF（Webアプリケーションファイアウォール）のような外付けの製品で防御を行う場合、以下の方法を取る。