知人の娘さんが Apple Inc.（米国本社）勤務だと聞いて興奮した。

Web アプリケーションには「さまざまな場所から呼び出されることを想定しているもの」と「特定の場所からのみのアクセスを想定しているもの」の 2 種類が存在する。例えば、サーチエンジンの検索フォームなどは前者であり、パスワード変更フォームなどは後者である。

特定の場所から呼び出されることを想定しているのであれば、その呼び出し元をコントロールする責任は Web アプリケーション側にある... と言うよりも、そのようにするのが自然な発想であろう（これは、高木氏の「サニタイズ言うなキャンペーン」における「（外部から入力された任意の）値」と「（出力に応じた適切な）エスケープ」の関係に似ている）。これを行わないのは開発者の怠慢であり、その結果が CSRF 脆弱性となる。

さまざまな場所から呼び出されることを想定している Web アプリケーションを除いても、サイトを跨いで（acceptable な）リクエストを送信することのできる Web アプリケーションはどこにでも存在する。例えばこの blog のコメントフォームでは「記事ページからのアクセスを想定している」にも関わらず、ワンタイムトークンや Captcha といった技術を使用していないため、クロスサイトでコメントを投稿することは可能である。私がそのような状態でコメントフォームを運用しているのは、（その作業時間が実情にペイしないという理由もあるが）このシステムが CSRF 脆弱性を持つとは認識していないからである（本来的に「脆弱性」とは第三者のユーザに対して被害がある場合に生じるもので、Web アプリケーションの運営者のみが被害を蒙る場合を含まない、という考えに基づく）。

　＊

なぜこのようなことを書くのかと言うと、このような記事を読んだからだ。記事長の制限もあろうが、CSRF 対策について書いた記事としては内容がいい加減過ぎる。

例えばパスワード変更の処理要求を受け付けた後に確認画面を設ける方法。ユーザーが確認ボタンを押さなければパスワードは変更されない。

本人は分かって書いているのだろうが、これでは対策として不十分（確認フォームの次の画面に対して CSRF を仕掛けられる）。また、ユーザの対策として

（1）スパム・メールに記載されているリンクや掲示板に記載される不審なリンクなど，信頼のおけないリンクを不用意にクリックしないように日常から意識する
（2）ブラウザが記憶するクッキーなどのデータを可能な限り無効化する
といった基本の順守しかない。

と書いているが、(1) 信頼できないリンクをクリックしないだけでは攻撃は防げない（例えば、Web メールで HTML 形式のメールを開くと、メール中の img 要素によって自動的にリクエストが発生する場合がある。また、信頼している Web サイトに XSS 脆弱性などが存在する場合は、その Web サイトを開いただけで攻撃を受ける可能性がある）。(2) に至っては、ユーザにとっての「基本」でさえないだろう。貴方は本当に Cookie を無効にして Web を使っているのか？と問いたい。しかも「など」とは何を指すのか？意味不明。
正しい（ユーザ側の）対策としては、

(1) Web サイトの「次回からログインを省略」機能を使わない
(2) Web サイトを使い終えたら直ぐにログアウトし、ログアウト前は他の Web サイトに移動しない（特にインターネットバンキングなど、重要なサービスを利用している間）

等が挙げられよう。

引き続き、ちょろちょろと Perl スクリプトを書く。
例の自宅サーバで cron に入れたりして。

レンタルサーバ（で動かす CGI）と違って、system で外部コマンドをガシガシ呼び出しても怒られないのは快適(笑)。

色々な事情で Perl で数十行程度のスクリプトを書いた。
のだけど、ファイルの読み込み while(<IN>) で $_ に改行コードが含まれているということをすっかり忘れていて、ちょっと悩んでしまった...
chomp; しなきゃイカンのでした。

最近 Java ばっかり触ってるからなぁ。
（こっちはこっちで、BufferedReader.readLine() に改行が含まれないことを忘れたりしますが）

EZwebブラウザの「お気に入り登録」は偽サイトを見分ける手段にならない

この件は自分も随分前から気になっていて、この記事（初出はスラド。こんなに話題になるならアカウント取って書けばよかった）を書いたのだけど、私が指摘するよりも遥か昔から高木氏は問題を認識されていて、丁度 IPA に届出をされていたのだそうです。

で、結局 KDDI の対応は FAQ での告知に終わってしまったようです。IPA の「情報セキュリティ早期警戒パートナーシップガイドライン」の最後の方を見れば、これが「典型的な悪い対応」なのは明らかなのに。

　＊

（以下、au しか使ったことが無いので他キャリアでは事情が違うかも：）
携帯用 Web アプリケーションって、よく見ると脆弱性だらけで泣けてきます。

そもそもプラットフォームの設計自体が駄目で、例えば著作権の付加（ダウンロードの可否）を端末側で（XHTML の属性値で）コントロールしていたりする。著作権保護は「URL がユーザに判らないこと」によってのみ担保されている、なんて PC では信じられない状況。

自分の見てきた例としては、

1. URI が判ればコンテンツの持ち逃げ可能：コンテンツファイル自体は static なファイルとして配置されていて、購入プロセスを通過した人だけにそのファイルの URI を提供する、というのが一般的なのです、恐ろしいことに。
2. PC から携帯サイトにアクセスできる（＝URI 丸見え）：IP アドレスとか、制限の掛けようは幾らでもあるのに、何故かしていない。若しくは UA のみの制限。
3. 本番サーバにバックアップファイルが（！）：自社開発なのか駄目ベンダーなのか知りませんが、hoge.php.20071209 とか。ソース丸見え。

などなど。1 と 2 が同時に起これば（これは実際に２箇所ほど目にしましたが）、コンテンツが PC から丸ごとゴッソリ持っていかれてしまう。

　＊

ということで、高木氏は上の記事で

無断リンク禁止のような話なのか。

と書かれていましたが、個人的には「とりあえず URL 隠しときゃクラッキング（含・コンテンツの無料持ち逃げ）防げるんじゃね？」という自己中心的かつ安易な考えではないかと思ったりしました。


※「ケータイ Web」の安全性があまり考慮されていないのは、設計当初の状況（kiosk 端末的、主として待受画面や着メロのダウンロードに使用、トップメニューから公式サイトのみを利用することを想定）と今日の状況（インターネットバンキングの普及など）があまりに違うためかも知れません。何れにせよ、携帯電話会社は今一度セキュリティについて考え直す必要があるでしょう。（とうまくまとめてみる）


追記(18:34)
上記の高木氏の日記の脚注に...

*4 ちなみに、スラッシュドットの7月11日のコメントにこれと同じ話題が書かれているがこれは私が書いたものではない。

あー...