脆弱性 Archive

前回のエントリ “携帯サイト開発者のためのセキュリティ再入門” が割と広範囲にお読みいただけているようです。ありがとうございます。ただあの記事は単に列挙しただけなので「何をまずやればいいのか」具体的なものが見えてこない気がしますのでメモとして再構成してみました。前回書いたように「契約者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をつかわない形へともっていくモデルケースですが、あくまで一例ですので実際のプロジェクトへの適用は個々の事情にあわせて慎重に行ってください。

通勤電車で周囲を見渡せば大抵数台のスマートフォンを見つけられるようなご時世ですが、現実は日本の伝統的な携帯電話が多数派です。今もそんなガラケー向けWebサイトの開発案件は衰えることありません。

そんなガラケーサイトの開発者の間で話題になっている「セキュリティ対策」について、ガラケー界の現状をふまえた上でまとめてみます。

携帯電話のIPからのアクセスであることを前提としたセキュリティ対策はすでに無駄

• ソフトバンク3Gのプロクシ情報は検索すればすぐに出てきます
• イー・モバイルのEMnetに至っては公開情報です
• サイトのソースもFlashのswfも画像もPCから丸見えだと思うべきです

危険な「かんたんログイン」

• かんたんログインで使う契約者IDはあなたのサイトにも他のサイトにも同じものが送出されてます
• 悪意をもった人が他人の契約者IDをヘッダに乗せてかんたんログインのアクションを呼び出したらどうなりますか

iモードブラウザ1.0以外はPCと同じくcookieを使えばいい

• iモードブラウザ2.0、すべてのEZwebブラウザ、ほぼすべてのYahoo!ケータイブラウザはCookieが使えます。EMnetももちろん使えます。
  • Yahoo!ケータイだとSSLで https://secure.softbank.ne.jp/ がcookie食べるのでは？
    → リンクを <a href=”javascript:window.location:’https://example.com/’”> で作れば大丈夫 。https://secure.softbank.ne.jpに飛ばされません。
  • 幸いなことにP型とC型の旧Jスカイ端末は2010年3月末に停波したので滅びてます
• 旧iモードブラウザ以外は「かんたんログイン」をやめてPCのようにログイン操作をcookieにより省略できる「ログイン状態を記憶」機能をつけてあげましょう。

iモードブラウザ1.0 でのかんたんログイン機能の実装

• (まだ割とシェアの多い)旧iモードブラウザでどうしてもかんたんログイン機能が必要な場合は”iモードサーバーのIPアドレス帯”+”iモードID”で認証する。ドコモのiモードゲートウェイは他社にくらべだいぶ堅牢っぽいです。
• 携帯IPアドレス帯+iモードIDの認証は厳禁。例えばYahoo!ケータイのゲートウェイに自作のX-DCM-GUIDヘッダがあっても特別な対応はせずにそのままリクエストされます。
• 「取り返しのつかない行為」、例えば日記の投稿、商品の購入やポイントの消費、退会などでは他の認証手段を検討すべきですが、どうしても簡略化しないといけない場合は（例えばミニブログの投稿サービスなど）投稿初回のみutnを用いた認証をし、その後はセッションを引き回す方法もあります。
  • 現時点でドコモのプロクシからのアクセスでUser Agentを書き換えられたというケースがないこと、またutnの送信は明示的な操作が必要なので攻撃者が比較的取得しにくいことを基にしていますが、それでも危険なことは言うまでもありません。

携帯電話もJavaScriptが使えちゃいます！

• iモードブラウザ2.0だけでなく、ここ3〜4年ぐらいのソフトバンク端末 (NetFront 3.3以降か)もJavaScriptが使えます。
  • ちなみにiモードブラウザ2.0、ここ1〜2年ぐらいのソフトバンク端末(NetFront 3.4以降) はAjaxが使えたり
  • iモードブラウザ2.0、大多数のソフトバンク端末、WIN以降のau端末はiframeが使えます
• 従ってPCと同等のXSS/CSRF対策は必須。
  • XSS対策: 正しいエスケープを行う
  • CSRF対策: コミット操作を伴うアクションに[使い捨て/セッションIDとは別の]トークンの検証を加える
• 怠るとフォームを自動的に操作される、cookieが盗まれる、XMLHttpObjectが作成されてしまうなどのことが起きてしまいます

IP制限はやめるべき

• 冒頭で述べた通り、携帯のWAPプロクシにパソコンから入ることは容易です。そんなことで盗用やいたずらを防げると思ったら大間違いです
• IPブロックでよくある話: 検索エンジンにひっかからなくなる→Google BOTのIPアドレスだけ開ける→Google翻訳プロクシから入られてしまう→やっぱり意味ない
• IPアドレス帯の制限がセキュリティの砦のような設計は即刻見直すべきです
  • iモードブラウザ1.0+iモードIDでの認証をやりたいならしょうがないですが。
  • どうしてもIP制限をしたければ、取り返しのつかないアクション(掲示板への投稿や記事削除、ポイント消費など)でセッション検証とあわせてIPアドレスの正当性を検査すれば、一定レベルのいたずらアクセスからサイトを守ることは可能。
  • セキュリティの担保としてキャリアネットワークであることを検証したいならば FirstPassやSecurityPassなどの携帯電話のSIMカードをつかった公開鍵認証という方法があります。利用料は無料です。

まとめ

携帯サイトだからって安全が増すということはまったくないので、PCサイトと同じく正攻法のセキュリティ対策を行いましょう。

追記

携帯サイトセキュリティTODOリスト を書きました。 (5/3)

こんにちはこんにちは！

今日からピコピコmixiがはじまりました！

ボクもプレイしたかったんだけど、Flash Liteに対応した携帯電話がなかったので、パソコンでダウンロードしてきました。その後スコアを送信しようとしたんだけど、ドメインなんとかって言われてエラーが出たので送信機をつくったよ！
(12/22 03:55 一部削除)

こんな感じでパソコンから送れました！やった！

Continue reading