前回のエントリ “携帯サイト開発者のためのセキュリティ再入門” が割と広範囲にお読みいただけているようです。ありがとうございます。ただあの記事は単に列挙しただけなので「何をまずやればいいのか」具体的なものが見えてこない気がしますのでメモとして再構成してみました。前回書いたように「契約者IDによるかんたんログイン機能を撤廃しよう」がすぐにできるのであればいいですが、なかなかできないのが現実でしょうから、「緊急度の高い対策」から順に扱っていこうと思います。

契約者ID(UID)で認証しているサイトはすぐにやろう

• キャリアのIP帯、User Agent、UIDのペアを確実に検証するようにする
  • 例えばドコモのIP帯 + ドコモのUser Agent + X-DCMGUID でのみ認証できるようにします。
  • もし [携帯電話のIP帯 (各キャリアのリストをマージしたもの) + ドコモの User Agent + X-DCMGUID] で認証するととても大変なことになります。
    例えばイー・モバイルのWAPゲートウェイはUser Agentや追加ヘッダを自由にセットできるので、携帯電話のIP帯であるかをファイアウォールやhtaccessだけで確認し、以後はUser Agentで分岐するような処理を書いている場合は、イー・モバイルのソースIPでファイアウォールを突破し、プログラム中でドコモのUser Agentを検出してドコモの処理に遷移、勝手につけられたX-DCM-GUIDでセッションを獲得されてしまいます。
• Hostヘッダのついていないリクエストには答えないように。
  • あなたのサイト http://www.example.com/ に http://aaa.bbb.ccc.ddd/ などのIPアドレス直打ちでアクセスできるようならばすぐに止めましょう。
  • iモードブラウザ2.0のDNS Rebinding脆弱性への対策。ezweb以外の他ブラウザもJavaScriptに対応しているので、報じられていませんが同様の脆弱性を持つものと思われます。
• キャリアからの通信であってもUIDが信用できないケースではUIDを使わない
  • iモード: SSL時 (SSL時はX-DCMGUIDは付与されない) – 代わりにutnを用いるようにします。
  • Yahoo!ケータイ・EMnet: SSL時 (secure.softbank.ne.jp経由の通信ではUIDは信用できますが、End to End通信をしている場合は偽装可能。見分ける方法は現時点で不明)

点検と改善

• ドメイン内に信頼できないコードがないか
  • 最近の携帯電話はJavaScriptやCookieを実行できますので、同一ドメイン内に信頼できないコードがある場合はJavaScriptやcookieによるアクセスが可能です。
  • ドメインを他のサービスと共有している場合、あるいは共有SSL (共有SSLドメインを使用し、ディレクトリ単位で個別のユーザが利用しているケース) は特に危険です！
• XSS脆弱性対策
  • 適切なエスケープ処理を講じましょう。
  • auや古いドコモの携帯は大丈夫？ → FlashではActionScriptが動きます。外部からの引数をもって起動するFlashをもっている場合はこれも脆弱性の対象です。 (Flashからの通信でもUIDを送出します)
• CSRF対策
  • コミット系アクションにはPOSTを使いましょう。 (GETでは動作しないようにする)
  • 重要度の高いコミット系アクションではセッションIDやUIDから類推できないトークンを受渡し、アクション時にトークンを検証しましょう。

UIDからの卒業

• まずUIDをそのままセッションIDとして使うのをやめます。UID送出によるかんたんログインで都度生成されるセッションIDによりセッションががスタートするようにしましょう
• 続いてログイン後にcookieを付与するようにします。cookieがついている場合はUIDを無視してセッションを復元するようにします。
• ドコモの場合はUIDに加えてutnの送出をするようにします。前回のutnと異なる場合はメールバックによる認証など、他の認証をあわせて実施するようにしましょう。
• cookieによるセッション管理が正しく動作するようになったら、EZweb / Yahoo!ケータイ / EMnet でのUIDかんたんログイン機能を廃止します。
• あとは旧iモードブラウザが滅びるのを待つだけです。。。

さらに高度なセキュリティ、スマートフォン時代への対応

• キャリアシステム (課金、ダウンロードコンテンツなど) に依存するアクションと、そうでないものを分離。
  • キャリアシステムであることを強く確認したいときには必要な確認処理を行う。メールによる確認のほか、FirstPassやSecurity Passなども無料で使えます。
  • 確認処理はできるかぎり単一のフィルタで実装し、キャリアによる仕様変更やセキュリティ上のトピックに対して単一の変更で適用が可能なようにしましょう。
• 逆に言うと、上記以外ではIPアドレスによる確認やUIDの確認は一切不要。
  • キャリア依存を解消していくことで、今後のスマートフォン時代でも容易にサイトを対応させられるようになりますしね！

UIDを認証目的で使うために可能な限り安全な対策をとりつつ、段階的にUIDをつかわない形へともっていくモデルケースですが、あくまで一例ですので実際のプロジェクトへの適用は個々の事情にあわせて慎重に行ってください。