"ケータイ"サイトを作成する前に知っておきたいこと (システム基盤編)

スマートフォンの利用者が多くなった昨今でも、まだまだ需要があり要求される”ケータイ”サイト。 スマートフォンサイトの制作やHTML5/CSS3の制作をしているウチに、”ケータイ”サイト特有の制約が頭からボロボロ抜けてしまわぬよう、まとめておきます。

セッション管理

セッションIDをページ間で引き継ぐには、Cookieを利用する方法と、セッションIDをURLに埋め込む方法があります。

Cookieに対応していない古い端末に対応した”ケータイ”サイトを作成する場合は、セキュリティの観点から好ましくありませんがURLにセッションIDを埋め込むしか方法がありません。 その場合、お客様にはしっかりとセッションハイジャックの危険性を説明しておく必要があります。 もちろん、どのようにそのリスクを回避(許容)するかの説明をお忘れなく。 (例：HTTPSのサイトなのでURLは暗号化されている、セッションの有効期限を○○分にしてリスクを許容する、アクセスできる端末をIPアドレス等をもとに限定している 等)

最近の端末であれば Cookie に対応していますのでセッションIDを Cookie で引き継ぐ方法もあります。 但し、お客様にはアクセスできる端末が限定されてしまうことを説明することをお忘れなく。 Cookie を利用する場合は secure 属性についても意識したいですね。

“ケータイ”サイトでセッションを利用する際に参考にしたいサイトは以下の通りです。

第3回 実は厄介、ケータイWebのセッション管理
http://www.atmarkit.co.jp/fsecurity/rensai/keitaiweb03/keitaiweb01.html

リダイレクト

画面遷移をリダイレクトで実現する場合にも注意が必要です。 docomo, au, softbank の各キャリアごとにリダイレクト回数に制限があるからです。 制限が一番厳しいSoftbankの場合3回 までとされています。 とりあえず、画面を表示するまでのリダイレクト回数は少ないに越した事はありません。 私はプログラマ寄りの人間なのでアプリの作りだけに意識が集中してしまうことがありますが、Apacheなどのミドルウェア、更にはネットワークレイヤでもリダイレクトの設定がされていないかを意識することを心がけましょう。

この項については、別途「ケータイサイトのリダイレクト回数制限について」という記事を書きましたので、参考にしてください。

SSL通信 (サーバー証明書)

“ケータイ”サイトをSSLで保護されたサイトにする場合にも、多くの落とし穴があります。

本番環境にリリースする前には検証環境で実機検証をすると思いますが、「SSL証明書？ 自己証明書でいいんじゃない？」はダメです。 Softbank, au の端末ではSSL証明書が自己証明のサイトは閲覧することができません。 検証環境でもSSL証明書をしっかりと取得してください。

文字コード

“ケータイ”サイトの文字コードは Shift_JIS で実装することが良いです。 docomo, SoftBank は UTF-8 の実装でも良いですが、au は Shift_JIS である必要があるからです。 尚実装の際には、機種依存文字に気をつけてください。 Windows-31Jを敢えて指定する必要がある場合もあります。 詳しくは以下のサイトなどが参考になります。

JSPで特殊文字が文字化けする場合の対処方法
http://www.atmarkit.co.jp/fjava/rensai3/mojibake02/mojibake02.html

事件事例

簡単そうで難しい”ケータイ”サイトの作成。 その特徴の影響範囲の見極め漏れによる事故・事件を知っておく事も必要です。 「以前○○社のシステムでこういう事件がありました、私達はそれを知っていますし対応策も知っていますのでご安心ください」とお客様に安心して頂くためのネタにもなります。

かんたんログイン方式で漏洩事故が発生 – 高木浩光＠自宅の日記
http://takagi-hiromitsu.jp/diary/20101025.html

まとめ

簡単にまとめて来ましたが、上記以外にもまとめている方や記事が多々ありますので、以下のサイトも参考にしてみると良いと思います。

再考・ケータイWebのセキュリティ
http://www.atmarkit.co.jp/fsecurity/index/index_keitaiweb.html

ガラケー×SSL 開発Tips
http://www.slideshare.net/T2J/ssl-tips