「Web 2.0はセキュリティ上の危険が高い。そのリスクを回避するためには，技術面やコスト面から現実的な対策を考えるべきだ」---。不正なWebアクセス/DBアクセスを防御する機器「SecureSphere」の開発会社，米ImpervaでCTO（最高技術責任者）を務めるAmichai Schulman氏は2007年4月27日，東京エレクトロンデバイスが開催したユーザー・セミナー「Web 2.0のセキュリティ･リスクと回避法」で講演した。
Amichai Schulman氏: “Web 2.0”という次世代のWeb利用方法が広まっている。Web 2.0は情報システムを便利にしてくれるが，その半面，セキュリティ上のリスクも広がってしまうという側面がある。情報システム部門は，Web 2.0によって引き起こされるリスクを知るとともに，このリスクを回避しなければならない。リスクの姿と対処方法を示そう。
Web 2.0は，大きく3つの要素で成り立つ。1つは，従来のWebブラウザ画面とは異なる豪華な操作感覚である。FLASHなどのリッチ・クライアント・アプリケーションを使う方法もあるが，Web 2.0では主にAjax（Asynchronous JavaScript + XML）が主流である。もう1つは，SNSやWiki，ブログといったコラボレーション（共同作業）。最後の1つは，RSSやマッシュアップなどのシンジケーション（コンテンツ供給）である。
いまやWeb 2.0の技術は，米Yahoo!や米GoogleなどのWeb 2.0企業だけではなく，一般的な企業や組織においても当たり前に使われるようになった。例えば，米国にある退職者のための協会「AARP（American Association of Retired Persons）」はその一例である。すなわち，私の祖母はWeb 2.0の使い手であるということだ。
確実に言えるのは，現在Web 2.0を使っていない企業でも，近い将来にWeb 2.0を使うようになる，ということ。例えば，CRM（顧客関係管理）やERP（統合業務パッケージ）といったパッケージ・ソフトは，すでにAjaxが使える。チェコ共和国のJetBrainsが開発したJava統合開発環境であるIntelliJ IDEAは，米Googleが開発したAjax開発フレームワークであるGoogle Web Toolkitをバンドルしている。
Ajaxはクロスサイト・スクリプティングの温床
ただし，こうしたWeb 2.0は便利であると同時に，セキュリティ・リスクを抱えている。まず，Ajaxはクロスサイト・スクリプティング（XSS）の温床になりやすい。また，ウイルスに感染したり，攻撃コードを含むURLを踏んだりする危険が高まるなど，コラボレーションとシンジケーションのリスクも拡大する。
Ajaxとは，Webブラウザを使うユーザーが明示的に本人の意思でリロードすることなく，バックエンドでリアルタイムに情報が更新されるようにする工夫のことだ。Ajaxの代表例に，Google Mapsがある。いまいる場所の地図が表示されるアプリケーションだが，バックグラウンドでWebサーバーにアクセスしてデータを取得しておくことで，見たい場所の上下左右の移動やズーム・イン/アウトの際に，リアルタイムに新しい地図が表示されるようにする。
Ajaxを実現させる個々の要素技術は，決して新しいものではない。例えば，XmlHttpRequest APIを使ってバックグラウンドでWebサーバーに接続する，XMLとXMLの木構造データベースに対するアクセス手順であるDOM（Document Object Model）を用いてWebブラウザ上に操作画面を作り出す，JavaScriptやVBScriptなどブラウザ上で稼働するインタープリタ言語を用いてWebサーバーへのアクセスやブラウザの操作インタフェースを司る，といった具合だ。これらは枯れた技術だが，個々の技術を組み合わせた新しい利用方法を提案している点が，Ajaxの革新性である。
Ajaxは，サーバーとは無関係なクライアント側のプログラミング技術であるため，Ajaxのセキュリティ・リスクについて語るべきことは少ない。しかしながら，XSSの温床になりやすいなど，クライアント側技術であるが故の問題もはらんでいる。従来のWebアプリケーションでは，WebサーバーはWebブラウザにHTMLを送り込んでいたが，AjaxではJavaScriptを送り込むため，XSSと相性が良いのである。
XSSとは，QUERY_STRINGを含んだURLに対して何らかの方法でアクセスさせ，アクセスに対するレスポンスとして攻撃コードをクライアントに送り込んで実行させる，という攻撃を指す。例えば，電子商取引サイトなど金銭のやり取りが発生するサイトにXSSの脆弱性があった場合，こうしたサイトに攻撃用コードを置いておき，URLを広くばらまいてコードにアクセスさせる。ID/パスワードを登録しているユーザーがURLにアクセスすることで，うまくいけばサイトのセッションCookieを奪うことが可能になる。この攻撃は非常にシンプルであり，実際によく起きている。
XSSは，WebサーバーによるWebブラウザに対する信用を悪用するというものだが，反対に，WebブラウザによるWebサーバーに対する信用を悪用するのがCSRF（Cross Site Request Forgery）である。CSRF攻撃を受けたWebブラウザのユーザーは，知らないうちに，勝手に電子商取引サイトなどにリクエストを発行してしまう。パスワードの設定を変えられてしまったり，購入していない物品を購入してしまったりするのだ。CSRFもまた，XSS同様に，Ajaxによって使われやすくなる攻撃手法である。
XSSなどの攻撃を軽減する方法は，シンプルである。より良いアプリケーションを書く，つまり，コードとデータを分離すればよい。これは，JavaScriptを返すモジュールと，データをXML形式で返すモジュールを分けるということだ。これにより問題を回避できる。というのも，単一のモジュールがデータとコードをJavaScriptで返す場合に問題が起こるからである。問題解決策としてはこのほかに，JavaScriptコードを用いてユーザーにデータを入力させない，特殊文字をXMLエンコーディングする，データのレンダリングの際にevalメソッドを使わない，入力の確認を逐次実施する，などの工夫もある。
AjaxによるWebサーバー側の問題は，モジュールが増えることによって，モジュール間の関係などを管理することが難しくなることである。例えば，1つ目に入力内容を確認するモジュール，2つ目に入力を処理するモジュール，3つ目に結果を返すモジュールがあったとき，1つ目のモジュールをバイパスして2つ目のモジュールに直接アクセスできる脆弱性があるかも知れない。つまり，Ajaxにおいて重要なのは，ステートのトラッキングと，モジュール間で共有するパラメータの確認なのだ。
Ajaxサイトでは，入力データの確認やセッション管理，アクセス制御といった一連のセキュリティ・コードをWebブラウザ側に任せてしまっているケースが多々ある。こうしたアプリケーションは脆弱である。何故なら，すでに述べたように，Webブラウザにコードを送り込んで実行させることができてしまうからだ。セキュリティ・コードはWebサーバー側で実行しなければ意味がない。Webサーバー側で入力データの確認とアクセス制御をしっかりやる必要がある，ということだ。
情報システムから脆弱性を排除するのは非現実的
Web 2.0が抱えるセキュリティ・リスクに対抗する実践的な方法は，WAF（Web Application Firewall）の導入である。何故なら，Webアプリケーションから脆弱性を排除することは，難しいからである。そもそも，購入してきた業務パッケージの場合は，ユーザー企業がプログラムを変更することは難しい。また，個々の開発者がミスを犯す可能性もあるし，潜在するコーディング・ミスを改善するためのコストは膨大である。
一方，WAFは，Webサーバーの前段に位置し，Webサーバーに対するアクセスを検証/制御するセキュリティ機器である。URL，メソッド，Hiddenフィールド，クッキー，XMLの要素などを調べ，不正なアクセスと判断した場合はWebサーバーにリクエストを渡さない。シグネチャ・ベースの検証のほか，日ごろのアクセスのトレンドを学習し，文字列の種類や長さなどが通常とは異なるURLアクセスを排除できる。（談）
