利用者重視の設計でセキュリティ要件が抜けがちになる一方で、セキュリティばかりに目を向けて利用者の利便性をないがしろにしてしまうケースもよくある。特にセキュリティ強化が主目的のプロジェクトで、セキュリティ設計が独立して実施されたときに起こりやすい間違いである。
運用を見落とさない
こんなときにセキュリティ設計を担当する専門エンジニアの意見をうのみにしてはいけない。利便性にも十分に配慮する必要がある。
実際にECサイトの脆弱性を修正するというプロジェクトで、利便性の確保を図ったのがゴルフダイジェスト・オンライン（GDO）の渡邉氏だ。渡邉氏は不正アクセス事件を機に、基本設計フェーズからセキュリティベンダーのレビューを受けるようにした。しかしセキュリティベンダーが提案してくる“安全性が最も高い方式”をそのまま採用はしないようにしている。
脆弱性を修正するプロジェクトで焦点になったのは、CSRF（Cross Site Request Forgeries）と呼ぶ脆弱性への対処である（図4）。CSRFは、利用者が悪意のあるサイトにアクセスしてしまったとき、それ以前にログインしていたECサイトなどに対して意図しない操作を強要されるもの。ECサイトに登録した個人情報を変更されたり、身に覚えのない買い物をされたりする恐れがある。
CSRFの対策として、二つの方式を検討した。一つ目は、重要な操作をする画面で、再度利用者にログインを要求する方式。二つ目が、個人情報の変更といった重要な操作をする際、それまでの画面遷移をチェックして不正利用を識別する方式である。
セキュリティベンダーが推してきたのは、一つ目の再ログインを求める方式だった。再ログインを求めれば、万が一、クロスサイトスクリプティングなどの脆弱性が存在した場合でも、なりすましなどの不正アクセスを防げるため、より安全だからである。
しかし渡邉氏は「それでは当社の利用者の理解は得られない」と判断した。GDOのサイトでは、1回ログインすれば再びサイトを訪れたときにもログイン状態を継続できる「自動ログイン」機能を提供している。その機能を使い続けている利用者が多いため、再ログインを求めるとパスワードを覚えていなくてサイトの利用を諦めてしまう可能性が高かった。この運用時の問題を重視して、画面遷移をチェックする方式でCSRFに対処することにした。
Webアプリケーションの脆弱性には、CSRFのようにシステムの使い勝手や機能要件にまで影響を与えるものがある。要件定義や設計の時点で対策を練っておく必要がある（3ページ目の「機能要件にも影響する脆弱性対策」参照）。
