高木浩光＠自宅の日記

■ 攻撃者視点ではなく開発者視点での解説を

8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ？ 英文 の直訳か何かか？

その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。

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

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

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

いいかげんなことを言ってもらっては困る。URLに「userid=1234」と書かれて いるからといって、その値がセッション追跡（ユーザのログイン状態の管理） に使われているとは限らない。

たとえば、表示するページのIDを指定するパラメタとして処理されている場合 だってある。blogやSNSのWebアプリケーションなどがまさにそうだ。具体的に は、

http://d.hatena.ne.jp/?userid=HiromitsuTakagi

というURLがあるときに、「HiromitsuTakagi」以外のIDでログイン中の人（も しくはログインしていないゲスト）がこのページにアクセスした場合には、 「HiromitsuTakagi」の日記ページが普通に表示され、「HiromitsuTakagi」の IDでログインしている人がアクセスした場合には、編集権限付きの画面として 表示されるというのは、ごく普通のことだ。

URLパラメタにユーザIDらしきものがあるとき、直ちにそれが脆弱性であると 推定してよいのは、ログイン時にcookieが発行されていない場合である。にも かかわらず、記事の続きを見ると、

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

このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。

とあり、cookieでセッション管理されている場合を想定しているようだ。わけ がわからない。

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

1. Webブラウザのキャッシュ
2. リファラ（Referer）
3. プロキシやファイアウォール

この話題を出すなら、「URLにユーザID」というストーリーではなく、URLにセッ ションIDの例で説明するのがよい。

記事の2ページ目も微妙におかしい。

まず、「Cookieポイズニング（Cookie Poisoning）」という用語がおかしい。 Cookieであろうが、POSTのhiddenパラメタであろうが、URLパラメタであろう が、それはパラメタの部位が異なるだけであって、ブラウザが勝手な値を送信 してくるという脆弱性の理屈は全く同一であり、それぞれを、poisoningだの、 manipulationだの、tamperingだのと呼び分けるのがくだらない。（いずれも manipulationで統一すればよい*1。）

そもそも、Cookie Poisoningとは本来別の意味で用いられる用語だった。たと えば、2000年2月に発表された CERT Advisory CA-2000-02 を見よ。次のよう に書かれている。

Attacks May Be Persistent Through Poisoned Cookies

Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.

CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests

これはクロスサイトスクリプティング脆弱性について最初に発表された文献だ が、その様々な脅威を列挙する中で、この部分は、cookieをセットする JavaScriptが埋め込まれたときに、ユーザのブラウザに悪意あるcookieがセッ トされて、それが永続的に当該サイトへの攻撃となる場合があることを述べて いる。

このように、poisoningとは本来、被害者のコンピュータに攻撃者が毒を盛る ことを指す用語だろう。「DNS Cache Poisoning」だってそうだ。 自分のブラウザのcookieの値を変更して脆弱サイトに攻撃を仕掛ける行為を、 「Cookie Poisoning」と呼ぶのは臍で茶が沸いてしまう。

どうにもこう、攻撃者視点の人達（つまり「ハッカー」）は、問題の本質を理 解していないことが多い。「こうやればああなる（場合がある）」ということ をただ知っているだけなのだろう。おどろおどろしい言葉を無駄に使いたがる 傾向もある。

続いて、ページの最後に、

この後、sendボタンをクリックすればあらゆる商品を自分の好きな金額で購入することができる。ここでは商品1から3まですべて100円に書き換えている。

この攻撃からサイトを守るには以下の方法がある。

• 金額など、改ざんによる誤った処理がされる可能性のある内容をCookie として格納しないようサーバプログラムの仕組みを変える
• サーバなどでCookieを暗号化し、人間が判読できないようにする

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

とあるが、正統な解決方法である次が抜けている。

• アクションを実行する（注文を確定させる）最後のページで、再度デー タベースから商品番号で単価を検索して使用する。

そもそも、単価をcookieに入れるというこの種の作り方は、セッション追跡機 構のないWebアプリケーション構築手法をとらざるを得ない場合（ユーザ登録 機能がなく、単発で住所入力をして注文するタイプのサイト）によく使われ るものであって、注文画面の途中経過ページにおいて、必要な情報を前のペー ジから引き継いで画面表示させることで、ページ毎にデータベースを検索する というコストを削減するためにやっていることだ。だから、その前提があると きに、「cookieとして格納しないよう」というのは解決策ではない。

さらに記事の3ページも問題が多い。

クロスサイトスクリプティング（Cross Site Scripting）

（略）

この攻撃は性質上、広範囲に広がりやすい。非常に大きな 被害を出した複合型ワーム「Nimda」もクロスサイトスクリプティングを感染手段の1つとして採用していた。感染するとNimdaはHTMLファイルを書き 換え、JavaScriptと攻撃プ ログラムを挿入する。そしてほかのユーザーが、そのWeb サーバ上のページを 閲覧するだけでNimdaに感染してしまうのだ。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、Nimdaがクロスサイトスクリプティング脆弱性を突いて広がったな どというのは初耳だ。それは全く事実でない。

これは二重に間違っている。まず第一に、Nimdaワームに感染したWebページと いうのは、ページコンテンツが改竄されたことによって発生した。改竄される 原因は、IISの脆弱性を突かれた場合と、サイト内部のネットワークでNimda感 染が広がってローカルにファイルが改竄されたものだった。これらはいずれも、 クロスサイトスクリプティング脆弱性と関係がない。第二に、そもそもNimda 騒動の原因は、JavaScriptを使用せずとも攻撃できるところに本質があった。 Nimdaは、.eml形式のファイルに攻撃コードを仕込んで、それをWebサイトに置 き、そこへのインラインリンクを設けておくことにより、そこを閲覧した者が 感染してしまうというものだった（半年前の脆弱性パッチを適用していなかっ たブラウザは）。たしかにJavaScriptも使われてはいたが、これは、感染して いく様子を見えにくくするために、画面外にポップアップウィンドウを出して そこで実行させるという攻撃者のちょっとした工夫にすぎず、それは問題の本 質ではない。

クロスサイトスクリプティング脆弱性の脅威を大袈裟に表現したいあまりに、 「この攻撃は性質上、広範囲に広がりやすい」などと言おうとして無理が生じ たのだろう。説明すべきは、cookieを盗まれると何が起きるかという点なのに、 その説明がない。

続く4ページ目はもっとひどい。

バッファオーバーフロー（Buffer Overflow）

（略）

Webアプリケーションにおけるバッファオーバーフローの脆弱性は、以下のよ うなページで発生しやすい。

<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="45"></td>
<form>

このソースでは、検索フィールド「search」に入力できる文字列は45文字まで に制限されているので、Webブラウザ上から46文字以上のタイプをしても入力 されない。しかし、このHTMLをダウンロードし、以下のように書き換える。

<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="1099511627776"></td>
<form>

これによって同じ検索フィールドに1GBの文字を入力することができ、バッファ オーバーフロー攻撃が可能になる。これはクライアント側のWebブラウザのチェッ ク機構に依存して、HTML上でデータ長の制限を行っているために発生し得る問 題点である。チェック機構をクライアント側に依存してはならない。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、size属性は画面表示上の入力欄の大きさを示すだけだよ。 maxlengthの間違いなのだろうが、「maxlength="1099511627776"」というのは あまりに滑稽だ。なぜなら、この属性は指定しなければデフォルト値は無限大 だからだ。

「ダウンロードして書き換える」などということも問題の本質では全くない。 バッファオーバーフロー攻撃を仕掛けるなら、直接HTTPポートにTCP接続して、 POSTでどんなデータでも送ればよい。

「1GB」というのも滑稽だ。バッファオーバーフローはなにも「巨大なデータ を送る」ことに本質があるわけではない。実際、Slammerワームはたった376 バイトのデータでバッファオーバーフロー攻撃を実現するものだった。

ようするに、なんとなくの感覚的イメージで脅威を伝えようとしているのだろ う。

バッファオーバーフロー攻撃からサイトを守るには以下の方法が有効である。

• Apacheにおける「LimitRequestBody」などを設定し、Webサーバであらかじめ 受け入れる送信データ量の制限を設定しておく

• 特定のサイズ以上のデータが送られてきたらクライアントにエラーを返すよう なコーディングを行う

という説明には危険性さえある。Slammerのように 376バイトで突けるバッファ オーバーフロー脆弱性があったらどうするのだ？ バッファサイズはなにも1024 バイト以上あるとは限らない。32バイトとかのバッファで境界を無視したプロ グラミングをしている例はいくらでもあるだろう。

SQLインジェクションもクライアントから送られる入力データを入念に検証していないWebアプリケーションにおいて発生する。攻撃者はメタキャラクタを入力データに挿入し、Webアプリケーションを経由して不正なクエリをデータベースに送信する。

べつに、「入念」とかそういう問題じゃない。インジェクション系の脆弱性は、 変数の出力時に、文脈を無視した文字列連結のコーディングをしているところ に原因があるのであって、セキュリティ以前に、正常系として、任意の入力に 対して正しく動作するプログラミングをしていれば、普通に解決するはず（だ が、できていない実態がある）というところに問題の本質がある。

SQLインジェクションも特殊文字を悪用することによって行われるので、ユーザー名やパスワードの文字種制限やサニタイジングが有効である。

パスワードに「'」を使わせないつもりなのか？ パスワードには強度確保のた めに記号を入れるのが常識なのに？

「サニタイジング」という便利な言葉は、問題の本質から目を背け、場当たり 的な対処方法という安易な説明を誘発してしまうので、有害だ。

これについては、「 サニタイズ言うなキャンペーン」実施中ということについて 説明しないといけないと思っているが、時間がないのでまだ書いていない。

この記事は冒頭で、次のように書かれいてた。

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

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

そりゃそうだろう。それは、記事が攻撃者視点で書かれているからだ。加えて、 正統で妥当な解決方法がないかのような書きっぷりだからだ。素人は問題の本 質が見えないままショックを受けてしまう。

この種の批判を浴びた攻撃者視点の人はこう弁明するに違いない。「攻撃方法 を知らずして対策ができますか？」と。それはその通りであるが（必要ではあ るが）、そのような態度に胡坐をかいていてはいけない（十分ではない）。よ り適切な説明方法があるのだということを理解してもらいたい。

もっとも、この記事は「Webアプリケーションファイアウォール」の宣伝であ るためこのような書き方になるのかもしれない。つまり、技術を理解する立場 にない対策担当者が相手であるために、怖いということさえ伝わればよいとい うのかもしれない。しかし、素人も直感的に何かおかしいということに気付く ものだ。いつまでも攻撃者視点でばかり煽っていると、業界全体の信用を損ね ることになりかねない。

ひと昔前なら攻撃者視点での解説にも意義があった。しかし、対策の必要性自 体は既に理解が広まった（が対策の方法が普及していない）現在では、もうそ ういうのはいらない。

私も時間がある限り書けるものは書いていくつもりだが、開発者視点で解説で きる執筆者がもっと増えてほしいと思う。セキュアな開発をちゃんとやってい る開発者はたくさんいるはずだ*2。

さてこの連載の次回は以下の内容になるのだそうだ。それはそれで重要な解説 なのでたいへん楽しみだ。本当にWebアプリケーションファイアウォールで対 策になるのかどうかが明らかになるかもしれない。

次回から、これらWebアプリケーションの脆弱性をセキュアプログラミングではなく、WAFのような外部機器にて防御していく手法について説明していく。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT