Hatena::ブログ(Diary)

ockeghem(徳丸浩)の日記 このページをアンテナに追加 RSSフィード

[PR]WAFの導入はHASHコンサルティング
 | 

2009-07-14 「劣化するWeb開発技術者」を量産するテキスト

携帯電話向けWebアプリセッション管理はどうなっているか 携帯電話向けWebアプリのセッション管理はどうなっているかを含むブックマーク

 最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。

 そうは言っても、本書にはブログSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。

  • 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う
  • 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する
  • そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる

 つまり、全てのリンクやFORMのアクションに、「guid=ON」を指定しているのだ。

 これは、携帯電話向けWebアプリケーション開発の定石とは言えないだろう。本書を勉強して著しく実力をつけた開発者がいたとして、いざ本格的なサイトを開発しようとすると非常にとまどうのではないか。セッション管理は、Webアプリケーション開発の基本であるのだから、最初からその基本をきちんと教えるべきだろう。

 この手法の限界は多いのだが、たとえば以下のような問題がある

  • iモードIDはSSLの場合送信されないので、SSL対応のサイトは開発できない
  • セッション情報をすべてhiddenなどで引き回さないといけないので、複雑なアプリケーション開発は困難
  • PCサイトとの互換性がない。PCと携帯電話相互乗り入れするサイトも作れない(あるいは困難)
  • 標準的なセキュリテイ対策手法が使用できない

などなど。このように、一般のPC向けサイト開発とはまったく互換性のない手法を敢えて教える必要があるのか。

 このような事態を予見するような意見は既にあった。高木浩光氏のインターネットにおけるセキュリティとプライバシーの両立についてに出てくる「劣化するWeb開発技術者」(スライドP42から下記に引用)がそれだ。

f:id:ockeghem:20090714000348p:image

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

 この方法の欠点として、「標準的なセキュリテイ対策手法が使用できない」ことを指摘したが、実際問題として、本書のアプリケーションでは、クロスサイト・リクエストフォージェリ(CSRF)対策をまったく考慮していない。このため、正規ユーザの権限にてSNSの書き込みや削除などが行えるようだ。

 以下は、本書のSNSの日記削除ページから引用だ。日記を削除してよいか確認したのち、「削除実行」のボタンの部分のフォームだ。

<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>

 上記のように、CSRF対策のトークン類はとくに渡されていない。携帯電話の場合、Refererをチェックすることもできない(docomoの大多数の端末がRefererに対応していない)ので、CSRF脆弱性がある。

 通常のCSRFは、正規ユーザが「たまたまログイン状態だった」場合に被害を受けるものだが、本書の方法だと「自動的に勝手にログインされる」わけだから、CSRFの影響を受ける確率は高くなる。

 対策は容易ではない。元々セッション管理をしていないのだから、一般的なCSRF対策に用いられるトークン類を覚えておく場所がない。docomoの場合、Refererが送出されない端末が大多数なのでRefererをチェックするわけにも行かない。だからといって、個体識別番号などをトークンとして用いることもできない。個体識別番号は秘密情報ではなく、どのサイトにもばらまかれるものだからだ。個体識別番号を暗号化する、あるいは適当なSaltをつけてハッシュ値を求めるなどの方法が考えられるが、暗号アルゴリズムの選定や、鍵やSaltの管理などが大変で、そんな苦労をするくらいなら、あっさりPHPセッション管理機構を使う方が楽で安全だ。それに、携帯電話向けWebアプリ開発では、セッションIDをURLに埋め込むことが定石的に行われるが、この方法の場合、原理的にCSRF脆弱性は発生し得ない。最初から秘密情報をURLに埋め込んでいるためだ。このセッションIDは第三者は知り得ないので、CSRF攻撃を掛けようがないのだ。

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

 ただしこちらの方は、CSRF脆弱性は心配ないが、残念ながらセッションフィクセーションの問題がある。本書P270には以下のような認証プログラムがある(login.php)。

// 前略
// 【徳丸注】ここまでくれば認証OK
// 会員データをセッションに格納する
session_start();
$_SESSION['name'] = $name;

// 会員ページにリダイレクトする【後略】

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

 このようなセッション管理系の脆弱性のチェックリストとしては、ウェブ健康診断仕様の「(K) セッション管理の不備」が利用できる。以下に引用する。

(K)セッション管理の不備

検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他)
1ログインの前後でセッションID が変化するかセッションID が変わらない場合は指摘
2言語・ミドルウェアの備えるセッション管理機構を使用せず手作りのセッション管理機構を使っていないか手作りのセッション管理機構を使用している場合は指摘セッションID のパラメータ名等で、言語・ミドルウェアセッション管理機構を使用しているかを判断します。判断がつかない場合には、"手作りの疑いあり"として報告します。
3SSL を使用するサイトの場合、セッションID を保持するCookie にセキュア属性が付与されているかCookie のセキュア属性が付与されていない場合は指摘-
4Cookie をオフにしてアクセスした場合、セッションIDがURL 埋め込みにならないかセッションID がURL 埋め込みの場合は指摘リファラから漏洩するおそれがある場合にのみ、脆弱と判定します。(5 を参照)
5携帯電話向けサイト等でセッションID をURL 埋め込みにしている場合、外部リンクからReferer 経由でセッションID が漏洩しないかReferer からセッションID が漏洩する場合は指摘PC/携帯サイト両方が対象。外部へのリンク(検査対象とは異なるホスト上のページへのリンク)が存在する場合にのみ脆弱と判定します。セッションID の漏洩が問題とならない場合(認証等の機能が無いケースや、ワンタイムなセッションID を使用しているケース)は報告から除外します。

 携帯電話向けアプリケーションの場合、上記3項と4項は該当しない(Cookieを使っている場合は該当する)が、それ以外(1、2、5)は対策する必要がある。このあたりも含めて、携帯電話向けWebアプリケーションセッション管理をどのように書けばよいかは、近くまとめようと思っている。

追記(2009/11/02)

KCCSにて11月12日(木曜)、11月19日(木曜)、12月10日(木曜)の3回にわたり、ケータイWebセキュリティのセミナーを実施することになりました。ケータイWebのセキュリティですので、とくにセッション管理やかんたんログイン機能の問題を中心に説明します。興味のある方は、こちらのリンクから内容確認の上お申し込みください。

lilylily 2009/07/15 00:33 携帯web開発者のセキュリティ意識の皆無さに改めて気づかされます。
こういう基本的な情報をもっと広めていきたいですね。
脆弱性山盛りの携帯サイトは沢山ありますからね(笑)いや、笑えないか。

ただ、あなたはモバイルの常識を知らない。
あなたにはモバイルサイトの構築はできないでしょう。出来たとしても、セキュリティ意識が皆無の技術者が作る物にも遠く及ばないでしょう。
それぐらい、モバイルは一般のwebアプリの常識が通用しないものです。

逆も然りで、モバイルオンリーの開発者は一般の常識的なwebアプリは作れません。これは断言できます。
まとめ記事、期待しています!

なまえ なまえ  2009/07/17 22:53 >>lily
相手の経歴をよく知りも知らないくせに「あなたはモバイルの常識を知らない」だなんて、
よく言えるね。失礼じゃないか。経歴を調べればどういう人だかわかること。
いいかげんなコメントを書きちらした恥を知りたまえ。

 | 
Google