ここで，Webアプリケーションが抱えるセキュリティの問題をいくつか考えてみよう。問題を整理するに当たり，想定される被害，脅威，すなわちリスクから整理する方法と，実装にかかわる要所で整理する方法があるだろう。前者の場合，Webサイトがさらされている脅威は毎日のように増え続けており，それゆえすべてをキャッチ・アップするのは不可能とはいわないまでも，気の遠くなるような作業が待ち受けている。実際に対策を検討する観点では，後者のほうが分かりやすい。

　以下では，Webアプリケーションのセキュリティに関係する問題を大きく3つに分け，それぞれを技術的問題，論理的問題，そして環境的問題として解説したいと思う。

　「技術」といえばすべてを包含してしまいかねないのだが，ここではWebアプリケーション構築に注目し，主にWebプログラムの実装技術の問題をいうことにする。開発に用いるプログラミング言語，フレームワーク，ミドルウエア，使用ライブラリをどのように実装するか。また，データの入出力の問題，すなわち，フォーム，クッキー，環境変数，URL，連携するXMLデータの取り扱いの問題。データベースやメールなどのほかのサーバー・プログラムとの連携もこの領域であるから，XSS，SQLインジェクション，パラメータ・インジェクション，セッション関連の脆弱性には，この分野での強化が関係している。システム関連エラーのハンドリングを設計し，システムエラーがブラウザに表示されないように注意すべきである。

　ログイン機能が実装されているサイトにおいては，セッションの取扱いに注意しなければならない。JPCERT/CC®の報告では詳しく触れられていないが，セッション・フィグゼーションというセッション乗っ取り攻撃について知っておいてもらいたい。セッション・キーを類推してなりすますのではなく，特定の状況がそろうと，そのサイトが実際に発行するセッション・キーを用いてユーザーになりすますことが可能となる。

　その状況とは，（1）Webサイトがログイン認証前にセッション・クッキーを発行しており，（2）ログイン認証前後でその値が変化しない，(3)GETリクエストなどでユーザーから自発的にセッション・キーが与えられると，それを受け入れてしまうアーキテクチャを使用している場合である。PHPやJavaのStrutsのセッション機構にもこの危険が潜在している。

　仕組みをざっと説明しよう。攻撃者は（1）のところでそのサイトで有効なセッション・キーを入手しておき，悪意のあるサイトでそのセッション・キーをパラメータとして付したリンクかリダイレクトを設置する。それにより，正規のユーザーがログイン認証した後には，ターゲットサイトでそのユーザーになりすますことが可能なのだ。

　その対策としては，ログイン後も有効であり得るセッション・キーを外部に漏らさないようにすることだ。ログイン認証後に，それまでに有効とされているかもしれないセッション・クッキーを明示的に一度破棄して無効化し，新たなセッション・キーを発行することが挙げられる。多くのプログラミング参考書のサンプル・コードはこのような実装をきちんと示していないので注意が必要である。

　Webアプリケーションは仕様どおりに完璧に動作し，しかもXSSやSQLインジェクションなどの不具合も起きないものの，その機構を悪用することが可能な場合がある。例えば，メールニュースの退会機能やパスワード・リマインド機能を取り上げてみよう。この機能のリスクには「個人情報の漏えい」がある。自分のメールアドレスではなく，他人のメールアドレスを入力した場合，「そのメールアドレスでは入会されていません」といった表示が出ることが少なくない。この表示機能によって，特定の他人がそのサイトに入会しているかどうかを検証することできるのは問題である。語るに落ちることのないように，注意深く設計しなければならない。

　「クロスサイト・リクエスト・フォージェリー（CSRF）」という脆弱性は，技術的問題でもあるが，論理的問題の側面もある。この問題について，JPCERT/CC®の報告書の中では「ユーザーを罠のページに誘導することで，そのユーザーが登録済みのサイトにひそかにアクセスさせ，登録情報の変更や商品の購入をさせることができる」と解説されており，想定される脅威としては，「データの改ざん，消去」となっている。これは，ほぼすべての機能を網羅していることを意味する。不本意なデータの登録すなわち，商品の購入，コメントや日記の投稿，プロフィールの変更，サイトの退会など，広範囲の被害が予想される。

　ログイン機構のあるサイトでは，ユーザーが一度ログインしたら，ログイン状態を保存することが多いが，そういった場合に発生しやすい。ログアウト機能がわかりにくい場合やユーザーのリクエストによっては深刻な影響を及ぼすような場合，確認の仕組み（例えば，再度のログインを促す，リファラチェックやワンタイムハッシュによる直接リクエスト防止）がないことが観察される場合は，技術的な問題だけでなく論理的な問題も関係していると言えよう。

　Webアプリケーションそのものの問題ではないものの，そのセキュリティに大きな影響を及ぼすのがこの環境的問題だ。実際の利用状況に対してサーバーの負荷耐力が低いと，Webアプリケーションは容易に落ちてしまう。ワーム，ポートスキャンなど過負荷を誘発する攻撃はWebアプリケーション・レイヤーよりもずっと低いところで対応すべき問題だ。ほかにもWebサーバーの設定ひとつで，パストラバーサルなどのシステムファイル漏えい問題は回避することができる。

　加えて，運用ツールの問題もこの環境的問題に含めたい。Webのコンテンツ・マネジメント・システムやデータベース・マネージメント・システムがある。また前述の通り，最近はあらゆるソフトウエアの管理機能がWebアプリケーションになっており，いろいろなポートがそのために用いられている。ルーター，ファイアウォール，Webアプリケーション・ファイアウォールの設定までもがWebベースとなっているのだ。Webアプリケーションそのものがセキュアに作られていても，そのような管理ツールを介して漏えいが起こる可能性を見過ごしてはならない。