「なりすまし」や「個人情報漏洩」――Webアプリケーションのぜい弱性を悪用した事件が後を絶たない。これらはアプリケーションの“作り”が問題であり，ファイアウォールやIDS（侵入検知システム）では防げない。筆者が実際に経験した事件を基に，対策の重要性を説明する。
クロスサイト・スクリプティング，SQLインジェクション，セッション・ハイジャック＊1――。最近，これらの用語をコンピュータ雑誌やインターネット・サイトなどで見かけるケースが増えてきた。いずれも，「Webアプリケーション・セキュリティ」と呼ばれるカテゴリに分類されるクラッキング技術である。
よく見かけるようになったとはいえ，これらが何を意味するのか，自分に関係することなのか，対策はどうすればいいのか，など全体像を正しく理解しているITエンジニアは少ない。そこで本記事では，Webアプリケーションがもたらす危険性ならびに対策方法を解説していくことにする。
まず，Webアプリケーションがなぜ危険なのか，対策の重要性を説明する。まずはどのような危険性があるのかというイメージをつかんでもらうため，筆者がセキュリティ監査などで体験した3つの事件を紹介することにしよう。なお，これらの事件はいずれも実話を基にしているが，監査者としての守秘義務があるため，細部は改変してある。
事件簿1 なりすましが簡単にできた
最初に紹介するのは，A社が運営する会員企業向け情報サイトで起きた事件である。A社ではもともとユーザーIDとパスワードで会員認証を行っていたが，認証の強度を高めるため，会員企業にデジタル証明書＊2を配布してクライアント認証を行うことにした。
情報サイト全体はJavaサーブレット＊3で開発されていたが，デジタル証明書を使ったクライアント認証機能に関しては，別のサブシステムで使っていたPerl＊4の既存資産があった。このため，Javaの情報サイト本体にPerlの認証機能を組み合わせて開発することになった。
 |
| 図1●認証情報をCookieで受け渡ししていた |
問題はここからである。Perlによる認証プログラムの結果を，Javaの情報サイトに引き継ぐ必要がある。A社は，これをCookie＊5で実現することにした。具体的にはこうだ。Perlの認証プログラムで認証に成功した場合は，CookieにユーザーIDをセットしてJavaの情報サイトにリダイレクトする。情報サイトではCookieの中身を確認し，ユーザーIDがセットしてあれば認証済みと判断して情報を表示する（図1[拡大表示]）。
一見良さそうに見えるが，これが大きなセキュリティ・ホールを作り込んでしまう結果となった。実は，Cookieの中身を改ざんすることはそれほど難しくない。Cookieに保存されたユーザーIDを適当なものに変えてJavaの情報サイトに直接アクセスすれば，パスワードもデジタル証明書もなしに任意の他社会員になりすますことができるようになってしまった。
例えばCookieに「ID=YAMADA」という値がセットされていたとすると，これを「ID=TANAKA」とするだけで，TANAKAの情報を閲覧できてしまう。セキュリティを高めるつもりが，かえって逆効果になってしまった。結局この問題に関しては，認証プログラムをJavaで作り直すことで解決した。
