がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

「PHPで作る携帯サイト」ではどうやってセッション管理をすべきか

PHP セキュリティ

なんかご大層なタイトルにしてみましたが。
元ネタはこちらです。


携帯電話向けWebアプリのセッション管理はどうなっているか
http://d.hatena.ne.jp/ockeghem/20090714/p1


ちなみに、会話対象になっているのは、この書籍

PHP×携帯サイト 実践アプリケーション集

PHP×携帯サイト 実践アプリケーション集

最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。

えと…正直、PHPのセッション関連の関数は、あれはあれで色々と「如何なものか」とは思われるので。
個人的には大変に好んでいないのですが。
つまり、上述書籍が「PHPのセッション関数がちょっとアレゲで以下略なので、別途作成を考えてみます」的方向性であるならば、おいちゃんは一定の評価をさせていただきたい、と思うのです。


えぇもしソンな事があれば、ですがねぇ。
実際の所は、以下の通り、らしいです(えぇ伝聞形ですとも。読んでないし)。

そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。
* 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う
* 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する
* そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる

多いですねぇこの系列。


ただ…

これは、携帯電話向けWebアプリケーション開発の定石とは言えないだろう。

徳丸浩さんすみませんこれは多分「ダウト」です。
「定石」という言葉の定義にもよろうかとは思うのですが…定石を、本来の意味である「最善とされるもの」であるとするならば、まさしく正しいのですが。
一方で、もし定石を「一般に最善と考えられている方法・手順」であると捉える場合…「一般の、つまりは大多数のエンジニア」は、契約者固有IDに関して「原子の一欠片ほども問題意識がない」のが、現時点における、現場の実情だと思われます orz

まさに上記のような、『「セッションID」という概念を知らない』技術者、『契約者固有IDがないとWebアプリを作れない』技術者を量産するような内容になっているのだ。

えと…ここは笑うポイントですか？ 血の涙を流すポイントですか？ orz

<form action="deletediary.php?guid=ON" method="post">
<div style="text-align:right;">
<input type="hidden" name="exec" value="1" />
<input type="hidden" name="id" value="<?php varout($entry['id']) ?>" />
<input type="submit" value="削除実行" />
</div>
</form>

えと…IDが何を指し示すかにもよるのですが。もし「メッセージID」ではなくて「ユーザID」であるとするならば…あぁSSL想定ですかね？
ちといくつか思考が散らかるのですが。


SSLではない状態でユーザID(契約者固有ID)を引数で持ち回しているのだとすれば、純粋に「奇異」です。
SSLであるのならばやむを得ないのですが…おっしゃる通り、抱腹絶倒ものにシンプルで愚かな脆弱性を抱え込む事になります。
メッセージIDであるのなら…次へ。

一方、本書の姉妹書のような体裁のPHP×携帯サイト デベロッパーズバイブルの方は、かんたんログインによる認証結果をPHPのセッション管理機構で保持するという、定石的でまともな作りになっている。これであれば、ログイン部分を取り替えるだけで、別の認証方式（たとえばパスワード認証）に変更することも容易だ。このような一般的・汎用的な方法を広く普及させるべきだと思う。

見ていないのですが…その後のセッションIDは「どうやって持ち回ってる」んでしょうか？
えぇもちろん最近のDoCoMoさんを前提にさせていただいてよろしければ「Cookieに保存」で終了、となるわけですが。目出度い事に。

認証成功時にセッションIDの再生成をしていないので、セッションフィクセーションの脆弱性が生じる（参考 http://d.hatena.ne.jp/ockeghem/20090515/p1 ）。session_start();の後に、session_regenerate_id(); を追加する必要がある。携帯向けWebアプリの場合、URLにセッションIDを埋め込むので、CSRF脆弱性の余地がない代わりに、セッションフィクセーションの攻撃は受けやすくなる。忘れずに対策しておきたい。

とあるところを見ると埋め込み前提っぽいのですが。
まぁこのあたりは携帯っつより「PHPのセッション関数を使う時」の心構え、ですね。


いずれにしても…色々と厄介で問題で邪魔だったりする事の多い契約者固有IDですが。

このあたりも含めて、携帯電話向けWebアプリケーションのセッション管理をどのように書けばよいかは、近くまとめようと思っている。

とあるので、ちと期待しながら待ってみたいなぁとか思ってます。


尤も。
おいちゃんが、上述以上に気にしてるし心配しているのが。
http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/
あたりに書いてあるような「複数の、悪意ある業者達がやらかしてしまうエトセトラ」ではあるのですが orz