要件「利用者の成りすましを防ぐ」
利用者の成りすましを防ぐには，経路上でのIDとパスワードの盗聴防止，認証・権限管理，既知の脆弱性補正――を考慮します。セッション管理設計も重要ですが，実務上はAPサーバーのセッション管理機能を利用することが多いので，ここでは説明しません。
ネットワーク経路上の盗聴を防ぐには，HTTPで標準化されている「基本認証（Basic Authorization）」に経路暗号化（SSL）を併用するか，HTTP/1.1で追加された「ダイジェスト認証（Digest Authorization）」を使います。これらの認証技術ではなく，アプリケーションで独自の認証を利用する場合は，SSLを併用するのが一般的です。
基本認証は，利用者IDとパスワードをBase64という方式でエンコードし，HTTPリクエストのヘッダーに付加して送信する方式です。大半のWebブラウザで利用できますが，Base64によるエンコードは簡単にデコードできますので，SSLの併用が欠かせません。
ダイジェスト認証は，利用者IDやパスワード，IPアドレスなどを基に生成したハッシュをHTTPリクエストのAuthorizationヘッダーに格納してやり取りする方式です。ハッシュからは元データ（利用者IDやパスワード，IPアドレスなど）を再現できないので基本認証より安全です。ただしダイジェスト認証を使う場合も，ハッシュ以外は平文になりますので，クレジットカード番号や個人情報などを送受信する際は経路の暗号化を併用します。
経路上の盗聴防止策を固めたら，利用者本人であることを確認する「認証」と，アクセス可能か否かを管理する「権限管理」を設計します。この過程で注意したいのは，認証と権限管理の実装方法です。アプリケーション独自の認証の仕組みを使う場合は作り込みが必要になりますが，基本認証やダイジェスト認証を使う場合は，ミドルウエア（通常はAPサーバー）に備わる機能をたいてい利用できます（図1）。ただ，ミドルウエアの認証機能を使うと，認証情報やアクセス権限情報の格納先を制限されるので注意が必要です。
 |
| 図1●認証と権限管理の実装の例 認証と権限管理は，APサーバーとアプリケーションの両面から設計し，一貫した処理フローになるように実装する。設計手順（3）で，認証と権限管理をアプリケーションで実装するか，APサーバーに任せるかを決定するが，APサーバーに任せることを選んだ場合はAPサーバーの機能上の制約で認証情報の格納方式が限られる場合があるので，（4）の選択で注意が必要になる [画像のクリックで拡大表示] |
次に検討するのは，既知の脆弱性です。これを見逃すと「セッションの乗っ取り（セッション・ハイジャック）」「特権の不正取得」「認証の無効化」などの攻撃を受け，正規の利用者に成りすまされる恐れがあります。「XSS（クロスサイト・スクリプティング）」や「SQLインジェクション」などの攻撃でも，成りすましが発生します。
XSSの脆弱性があるアプリケーションを補正するには，データの入出力時に「<」を「<」に置き換えるなどの処理（HTMLエンコード）を徹底します。一般には，自動的にHTMLエンコードする共通基盤フレームワークを整備するか，コーディング規約を作ってメンバーに厳守させます。また，SQLインジェクションの脆弱性があるアプリケーションを補正するには，利用者やデータベースから入力されたデータのチェックを徹底し，かつ，データベースのバインド機構による事前解析済み（prepare）SQLをできるだけ使うように設計します。
脆弱性は上記以外にも多数ありますし，新手の攻撃方法も次々と登場します。従来はほとんど使われていなかった攻撃手法が，ツールの登場で急に多用されるケースもあります。セキュリティの専門家やIPA（情報処理推進機構）といった専門機関などが提供する情報を逐次参照し，常にセキュリティ対策を見直す姿勢が求められます。
◇ ◇ ◇
セキュリティ対策の要素技術はどれも重要なものばかりですが，取捨選択したりバランスよく使ったりするのは難しいことです。専任者を置いたほうが無難ですが，専任者以外も基本は押さえるべきでしょう。
|
|
