前回は、文字集合と文字エンコーディングについて説明し、文字コードとセキュリティの関係についてまとめた。ここでは、ガラケー向けWebアプリケーションの脆弱性対策についてまとめる。
１ 技術的特徴
ゲートウェイの役割
ゲートウェイはHTTPプロキシとして動作し、Webサーバーから見えるクライアントのリモートIPアドレスは、ゲートウェイのIPアドレスとなる。このHTTPの中継以外にも、以下のような役割がある。
- 携帯電話網からインターネットへの橋渡し（プロキシ）
- 携帯IDの付与（iモード、Yahoo!ケータイ）
- クッキー保持（EZwebのみ）
- 絵文字の変換
- SSL処理（現在は廃止）
- 言語変換（XHTML→HDMLなど。意識する必要はない）
ブラウザの機能的特徴
- クッキーが使えない端末の存在：iモードは1999年のサービス開始から2009年5月までクッキーをサポートしていなかった
- JavaScriptが使えない端末が大半：同上
- Refererなどリクエストヘッダの制限
- HTTPレスポンスの容量制限
携帯IDの存在
携帯電話のブラウザのリクエストヘッダには、携帯IDと呼ばれる識別子がつく場合がある（URLにguid=ONを指定すると送信される）。その利用目的は、IDとパスワードの代わりに認証用の識別子として、クッキーの代わりにセッション保持のために使用されることが多い。架空請求詐欺など犯罪に悪用される懸念もある。
２ 携帯ブラウザ
JavaScriptの仕様
ソフトバンクの端末
2010年夏モデル以降の正式対応版と、それ以前の非公式対応版では仕様が異なる（省略）。
NTTドコモの端末
iモードブラウザ2.0端末で使用できるJavaScriptには、以下の制限が確認されている。
- alert、prompt、confirmメソッドの無効化
- XMLHttpRequestオブジェクトのリクエスト先ディレクトリの制限
- setRequestHeader
au/KDDIの端末
EZwebのブラウザではサポート外。
JavaScriptサポートによるセキュリティ上の影響
XSSやCSRFなど。
クッキーの仕様
EZwebの端末のみゲートウェイによるクッキー保持を行う場合がある。例えば、HTTPの状態でSet-Cookieされたクッキーは事業者のゲートウェイが保持する。
３ かんたんログインの問題
かんたんログインとは、IDとパスワードの代わりに携帯IDのみを用いた認証の手法。一般的には以下のような方法で実装されている。
- 携帯電話からのアクセスであることを確認する
- 利用者登録の際に携帯IDを記録しておく
- ログイン時には携帯IDを調べ、登録済み利用者が見つかれば認証成功とする
攻撃例
必須事項を守らない場合のPCからの攻撃の例として、大手ソーシャルブックマークサイトの脆弱性や宅急便大手サイトの事故などがある。さらに、以下にIPアドレス制限下でのかんたんログインに対する攻撃手法を挙げる。
- 携帯電話をモデムとしてゲートウェイを経由する方法
- リクエストヘッダを書き換える（能動的攻撃）：携帯IDの識別方法に不備がある場合やHTTPSでかんたんログインを利用できる場合など
- DNSリバインディング攻撃（受動的攻撃） ：DNSが返すIPアドレスを短時間のうちに変化させることにより、同一生成元ポリシーを破る手法。対策は以下のいずれか。かんたんログインを受け付ける際にHostヘッダの正当性を確認する。名前ベースのバーチャルホストを設定する
対策
- 携帯電話事業者のゲートウェイからのアクセスのみを受け付ける（IPアドレスチェック）
- リモートIPアドレスを基に事業者判定する
- 携帯IDとしてはiモードID、EZ番号、ユーザID（ソフトバンク）のみを用いる
- HTTPSではかんたんログインを受け付けない
- Hostヘッダのチェックまたは名前ベースのバーチャルホストの設定を行う
- ソフトバンクの非公式JavaScript対応端末への何らかの対処を行う
４ URL埋め込みのセッションIDによる問題
URL埋め込みのセッションIDの影響
- セッションIDの固定化が起こりやすい：セッションIDの固定化による別人問題、検索サイトにセッションIDつきで登録される、利用者がセッションIDつきのURLを教えてしまう
対策
- クッキーが使える場合はクッキーを使う
- 外部ドメインに極力リンクしない
- 外部リンクにはクッションページをはさむ
- ログイン後にセッションを開始する
- 検索エンジン対策：根本的対策（認証前にはセッションを有効にしない）、保険的対策（認証前のセッションには個人情報など重要情報を入力させない、検索エンジンのクローラアクセスに対してはセッションIDを出さない）
５ その他の問題
脆弱性対策が必要。
最後に
現在ではスマートフォンが主流になっているため、こういった対策は不要になってきている。しかし、クッキーへの対応・未対応によって対処が煩雑になっていたことは理解しておくとよいだろう。原則、認証（ログイン）後にセッションを有効にし、クッキーによるセッション管理に移行することが重要である。
次回は、Webサイトの安全性を高める施策についてまとめる。
 |
