wasbook reading #11

「体系的に学ぶ安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践」読書会の第11回。
今回読んだのは以下の範囲。

7章携帯電話向けWebアプリケーションの脆弱性対策
- 7.1 携帯電話向けWebアプリケーションの技術的特徴
- 7.2 携帯ブラウザの技術仕様
- 7.3 かんたんログインの問題
- 7.4 URL埋め込みのセッションIDによる問題
- 7.5 その他の問題
- 7.6 まとめ

7章携帯電話向けWebアプリケーションの脆弱性対策

7.1 携帯電話向けWebアプリケーションの技術的特徴

携帯からのアクセスの場合、キャリアのゲートウェイからインターネットに接続される。ゲートウェイはプロキシのように動作し、WebサーバにはゲートウェイのIPアドレスが記録される。
ゲートウェイでは携帯IDの付与、クッキー保持、絵文字の変換などが行われる。
携帯のブラウザには機能制限がある。クッキーやJavaScriptが使えなかったり、いくつかのヘッダが制限されていたり。
携帯電話からのリクエストには、携帯ID(契約者固有ID、端末固有ID、個体識別ID、ケータイIDなどをまとめて携帯IDと記載する)が付く場合がある。

7.2 携帯ブラウザの技術仕様

キャリア毎にJavaScriptの制限が違っていて大変そう。
キャリア毎にCookieの制限が違っていて大変そう。

7.3 かんたんログインの問題

一定周期で話題になっているような気がする「かんたんログイン」。かんたんログインとは以下のような方法で実装されることが多いみたい。

携帯電話からのアクセスであることを確認する

利用者登録の際に携帯 ID を記録しておく

ログイン時には、携帯 ID を調べ、登録済み利用者が見つかれば認証成功とする

先に書いておくけど、携帯IDを利用したかんたんログインを安全に実装するのはすごく大変なので、やめたほうがいいと思う。

かんたんログインを安全に実現するには、「携帯電話からのアクセスであることを確認する」必要がある。これ、すごく難しい。
携帯IDを確認しても、それは偽装されているかもしれない。かんたんログインは携帯IDのみで認証成功とするので、携帯IDを偽装されるとなりすましができてしまう。
そのためにはリモートIPアドレスで確認する必要がある。
でもテザリング(携帯電話経由でのPCのインターネット利用など)している場合も携帯か判別する必要があるし、リクエストヘッダをJavaScript書き換えられる可能性もある。

じゃあどうするかというと、パスワードによる認証にして、ログイン状態の保持にはCookieを利用するのがよい。つまり普通の認証と同じように実装するということ。ユーザとしても、かんたんログインはなるべく利用しないようにしたい。

7.4 URL埋め込みのセッションIDによる問題

iモードではCookieが使えない時代がけっこう長かった。そんなわけで、URLにセッションIDを埋めこんだりすることもあったけど、これも危ない。
セッションIDの固定化や、セッションID付きのURLをだれかに教えてしまったりと。そうすると、意図せずなりすましになってしまうこともある。
対策としては、できる限りはCookieを使う、外部リンクにはクッションページをはさむ、ログイン後にセッションを開始する、といった方法がある。