■ WASF Times版「サニタイズ言うな！」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ？ Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか？ 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの？プログラムの内容からして必要のないことなのに？ そう

水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更

■ WinnyのDownフォルダをインターネットゾーンにする いくつかの国々では、貧困層に薬物乱用が蔓延し、注射器の回し打ちで悪性の感染症が広がっているとき、無料で注射セットを配布するのが正義なのだという。 ニートにWinny乱用が蔓延し、Downフォルダのダブルクリックで悪性のトロイの被害が広がっているとき、私達にできることといえば、せめて安全なファイルの開き方だけは伝えていくことではないだろうか。どうしてもWinnyを使いたいならDownフォルダをインターネットゾーンにして使え、と。 Vector Softライブラリに、「ZoneFolder.VBS」というVBスクリプトのパッケージがある。 この中にある「インターネットフォルダ.VBS」を実行すると、作成するフォルダ名を入力するよう求められるので、できるだけランダムな名前を入力する。

■ 「ファーミング」さえ理解していないフィッシング対策協議会 昨日の話もひどかったが、よく見てみれば、他にも杜撰なところだらけだ。 全く気付かなかったが、フィッシング対策協議会は、今年の1月に初のレポートを発表していた。この内容がひどい。2006年1月12日に公表された「2005/11 国内フィッシング情報届出状況」と題された文書*1には次の記述がある。 1.5. フィッシングサイトの動向 11 月度に報告のあったフィッシングサイト2 件に関してはURL の偽装や紛らわしいURL の使用などは認められませんでしたが、今月発見されたYahoo!オークションのフィッシングサイトに関してはメールと共に、ブログやSNS にIP アドレスのリンクが記載されており、ファーミングの手法も取り入れられていることが確認されました。 （略） 1.8. 総括 11 月度は7 月度以来の日本企業のフィッシングサイ

■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

■ SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。 Webサイトはログイン画面からSSLを使い，利用者はログイン時に鍵マークを確認するのが常識。 阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日 正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。 SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由

■ 攻撃者視点ではなく開発者視点での解説を 8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ？ 英文 の直訳か何かか？ その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。 この例では、「userid=-20298745283」がクエリストリング にあたる。クエリストリングはURL内に含まれているため、誰でも見ることが できる。従って、ユーザーのちょっとした出来心やいたずら（例えば 「この数字の最後を1つだけずらせばどうなるかなー？」） によって、脆弱性が露見することも多い。 この例であれば、誰が見ても明らかなように、「userid」のパラメー タがユーザー管理

■ SSL 2.0でないと接続できないサイトにアクセスするとどうなるか 昨日の日記は、 必要もないのにSSL 2.0を有効にせよと指示しているサイトの例だったが、 本当にSSL 2.0でないとアクセスできないサイトというのは、どうやら非常に 珍しいようで、探してもそうそう見つかるものでもない。 次のサイトがひとつ見つかったので、SSL 2.0をオフにしてここにアクセスし てみると、どんな結果になるか体験できる。 https://www.hellowork.go.jp/ FirefoxでSSL 2.0をオフにして上のURLにアクセスすると下の図の警告が出る。 OpenSSLのdebugモードで接続してみたところ次のようになった。 $ openssl s_client -debug -connect www.hellowork.go.jp:443 CONNECTED(00000003) wri