実は厄介、ケータイWebのセッション管理再考・ケータイWebのセキュリティ(3)(1/3 ページ)

“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます(編集部)

» 2011年05月26日 00時00分 公開
[徳丸浩京セラコミュニケーションシステム株式会社]

「Cookieを使えない端末」でセッションを管理する方法は?

 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。

 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション(ケータイWeb)のセッション管理は、かんたんログインよりも対策が難しく、厄介な問題なのです。

URLにセッションIDを埋め込んで解決?

 A社が「グダグダSNS」サイトを携帯電話に対応させるに当たり、かんたんログインに加えて、セッション管理の方法を決定する必要がありました。

 A社の開発者は「そういえば、ケータイではCookie使えないんだよね」ということに思い当たり、ケータイWeb向けのセッション管理方法をWebで検索して調べました。すると、次の2種類の方法が、ケータイ向けサイトにおけるセッション管理の主流のようでした。

  • 契約者固有IDをキーとしてセッション管理を行う
  • セッションIDをURLに埋め込む

 このうち、契約者固有IDをキーとする方法は少し難しそうだという理由から、A社はセッションIDをURLに埋め込む方法を採用することにしました。PHPを用いてURLにセッションIDを埋め込む方法を調べてみたところ、php.iniに以下の2行の設定を書くだけで実現できることが分かりました。

session.use_cookies = 0
session.use_trans_sid = 1

 これは、セッションIDの保存にクッキーを使わない(session.use_cookies = 0)設定と、URLにセッションIDを自動的に埋め込む(session.use_trans_sid = 1)設定を組み合わせたものです。

 A社のエンジニアは、念のため簡単なスクリプトを作成して動作を検証してみました。以下はセッションを開始した後、next.phpおよびhttp://www.atmarkit.co.jp/へのリンクを表示するだけの簡単なスクリプトです。

<?php
  session_start();
?>
<body>
  <a href="next.php">next</a><br>
  <a href="//www.atmarkit.co.jp/">@IT</a>
</body>
/m/index.php

 これを実行すると、以下のHTMLが生成されます(PHPSESSIDは異なる値になります)。

<body>
  <a href="next.php?PHPSESSID=g631b9am8036q0c6nf5h5v4b53">next</a><br>
  <a href="//www.atmarkit.co.jp/">@IT</a>
</body>

 内部のリンクについては自動的にセッションIDが付き、外部ドメインへのリンクにはセッションIDは付きません。これを見てA社のエンジニアは「URLにセッションIDを埋め込んでもセッションIDが漏えいすることはない」と判断し、実装しました(注意:この判断は間違っています)。

「RefererからセッションIDが漏えいするよ」

 「グダグダSNS」がケータイ対応してからしばらく経ったある日、外部のセキュリティ専門家から「セッションIDが外部に漏えいするので成りすましの危険性がある」と指摘されてしまいました。

 しかし、前述のようにA社のエンジニアは、外部サイトへのリンクにはセッションIDが付かないことを確認していたはずです。不思議ですが、指摘を読むと以下の理由であることが分かりました。

 「グダグダSNS」には日記の機能があり、日記中にURLが記載されている場合は、自動的にa要素に変換されます。これはSNSでは一般的な機能です。しかし、この機能を悪用した攻撃が可能です。以下、攻撃のシナリオを説明します。

 まず攻撃者はワナのサイトを用意して、「グダグダSNS」の日記に次のように書き込みます。

私のホームページを作りました。
見に来てね
http://trap.example.com/

 この日記をグダグダSNSに投稿すると、以下のHTMLに変換されます。

<p>私のホームページを作りました<br>
見に来てね</p>
<a href="http://trap.example.com/">http://trap.example.com/</a>

 ご覧のように、a要素のURLにはセッションIDは付いていません。

 しかし、この日記を利用者が閲覧すると、次のようなことが起こります。例えば、日記のURLがhttp://example.jp/435?PHPSESSID=8A4E13Bだとすると、このURLに付いているセッションIDが、遷移先のサーバにRefererヘッダとして送信されるのです(図1)。Refererヘッダとは、遷移元のURLを送信するもので、通常はサイトのアクセス解析に利用されます。

図1 外部のサイトに送信されるRefererヘッダの中にセッションIDが含まれる 図1 外部のサイトに送信されるRefererヘッダの中にセッションIDが含まれる

 このように、たとえ外部へのリンクURLに直接セッションIDが含まれていなくても、リンク元ページのURLにセッションIDが付いていると、Refererヘッダにより外部のサイトにセッションIDが漏えいすることが分かりました。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。