携帯電話向けWebアプリケーションのセッション管理手法
高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのかに、高木浩光氏が携帯電話向けWebアプリケーションの安全性についてコメントされておられる。
なぜ「URLにセッションIDが含まれる場合はセキュリティに注意する必要があり」なのかと言えば、Refererによってリンク先にセッションID入りのURLが流出し、流出先サイトの人にセッションハイジャックされてしまうからだ。
確かにそうなのだが、携帯電話向けWebアプリケーションでは、セッションIDをURLに埋め込むことが定石として用いられている。
その理由は、他に適当な方法がないからである。
携帯電話向けWebの代表例であるi-modeでは、Cookieをサポートしていない。そのため、セッションIDを埋められる場所というと、
- URLに埋め込む
- Hiddenフィールドに埋め込んでPOSTで送出する
くらいしか代替手段がない。ところが、携帯電話向けブラウザではJavaScriptをサポートしていないので、POSTにするということは、リンクをあきらめてフォームとボタンにしなければならない。リンクが使えず、すべてをボタンにしなければならないサイトデザインは、かなり制約を受けることになり、現実的ではない。また、POSTのHiddenフィールドにセッションIDを自動的に埋め込むような開発ツールは一般には普及していないと思う。
このような理由により、携帯電話向けWebアプリの開発には、URLにセッションIDを埋め込む方法が一般的である。もう一つの方法として、端末固有IDをセッション識別に使うという方法もあるが、開発ツール側が対応していないので、ECサイトのような大きなサイトではあまり用いられない方法だと思う。
ところで、セッションIDをURLに埋め込む手法が問題となるのは、Referrerによる漏洩が心配であるからだが、この点i-modeは仕様上はこの問題をクリアしている。i-modeでは、Referrerが送出されないことになっているからだ。
一方、au(EZweb)ではReferrerが送出される。EZwebではReferrerが送出される代わりに、Cookieをサポートしているから、CookieにセッションIDを埋め込めば安全なのだが、そのようなサイトはあまり多くない。これは、キャリアごとにセッションIDの保持場所を変えるのが煩雑になるからである。依然としてDocomoのシェアが圧倒的であるという現状では、サイトオーナーはまずi-modeに対応した携帯電話向けWebサイトを開発し、他のキャリアに対する「微調整」をほどこすような開発スタイルが一般的である。このような背景もあり、携帯電話向けWebアプリでは、Cookieを利用するケースは多くはない。
さらに、ソフトバンクの場合は、Cookie、Referrerとも機種依存であり、話がややこしい。
前述のように、理論的には、Cookie対応の端末ではCookieに、Cookie非対応の端末ではURLにセッションIDを保持することが望ましく、そのような開発は可能であるが、現実にはあまり行われない。
それに、Cookie非対応だがReferrerには対応するような端末もあるので、結局はそのような「最悪ケースの」端末を想定してアプリケーションを記述するしかないのが現状である。
すなわち、
- セッションIDはURLに埋め込む
- ReferrerによるセッションID漏洩対策にはリダイレクタを使用する
というような方法である。
