Header Manipulation: Cookies

未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。

Cookie Manipulation の脆弱性が発生するのは次の場合です。

1. 信頼されていないソース (多くの場合、HTTP リクエスト) からデータが Web アプリケーションに入り込んだ場合。

2. Web ユーザーに送信される HTTP クッキーにデータが検証せずに含まれている場合。

多くのソフトウェアセキュリティの脆弱性と同様、Cookie Manipulation は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は脆弱なアプリケーションに悪意あるデータを渡し、アプリケーションがそのデータを HTTP クッキーに含めます。

Cookie の不正操作: クロスサイト リクエスト フォージェリのような攻撃が同時に行われると、正規ユーザーの cookie が変更、追加、または上書きされる可能性があります。

HTTP レスポンスヘッダーでの、Cookie Manipulation 攻撃は、以下のような種類の攻撃にもつながります。

HTTP Response Splitting:
Header Manipulation 攻撃で一般的に発生する攻撃の 1 つは、HTTP Response Splitting です。HTTP Response Splitting の悪用が成功するためには、ヘッダーへの CR (キャリッジリターン、%0d または \r とも表記します) 文字や LF (ラインフィード、%0a または \n とも表記します) 文字を含む入力がアプリケーションで許容されている必要があります。これらの文字を利用して攻撃者は、アプリケーションが送信するレスポンスのヘッダーのそれ以降の部分とボディを制御できるだけでなく、追加のレスポンスを思うままに作成することが可能です。

最近のアプリケーションサーバーの多くは、HTTP ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例 1: 次のコードセグメントは、ブログのエントリの作成者名 author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

「Jane Smith」のような、標準的な英数字で構成されている文字列がリクエストで送信されたと仮定した場合、この cookie を含むHTTP レスポンスは次のような形式になります。

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

ただし、cookie の値は未検証のユーザー入力から形成されているので、レスポンスがこの形態を維持するのは、AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

2 番目のレスポンスは完全に攻撃者の支配下にあり、思うままのヘッダー内容やボディ内容で構成することができます。攻撃者は任意の HTTP レスポンスを構築できるため、クロスユーザー改竄、Web およびブラウザキャッシュポイズニング、Cross-Site Scripting およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

一部には、モバイルの世界では Header Manipulation や Cookie Manipulation のような古典的なアプリケーションの脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 2: 次のコードでは、Android プラットフォームにExample 1 を応用しています。

...
	CookieManager webCookieManager = CookieManager.getInstance();
        String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
	String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
        webCookieManager.setCookie(url, setCookie);

...

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、2 つのレスポンスを作成させる単一のリクエストを行います。その 2 番目のレスポンスは、別のリクエスト、おそらくはサーバーとの TCP 接続を共有している別のユーザーが行ったリクエストに対する回答と誤って解釈される可能性があります。この攻撃は、攻撃者とユーザーがサーバー (共通のプロキシサーバーなど) との TCP 接続を共有している状況で、悪意あるリクエストをユーザー自身で、またはリモートから送信するよう誘導します。最も良心的な場合でも、攻撃者はこの能力を活用して、ユーザーにアプリケーションがハッキングされていると思わせ、アプリケーションのセキュリティに対する信頼を失わせる可能性があります。最悪の場合、攻撃者はアプリケーションの動作を模倣し、口座番号やパスワードなどの個人情報を攻撃者にリダイレクトするよう設計されたコンテンツを用意しています。

キャッシュポイズニング: 悪意により構成されたレスポンスが、多数のユーザーが使用する Web キャッシュ、または 1 人のユーザーのブラウザキャッシュに保存されると、被害が拡大することがあります。レスポンスが、一般にプロキシサーバーに見られるような共有 Web キャッシュに保存されると、キャッシュエントリが消去されるまで、そのキャッシュを使用するすべてのユーザーが、悪意あるコンテンツを継続して受け取ります。同様に、個別のユーザーのブラウザキャッシュにレスポンスが保存される場合も、キャッシュエントリが消去されるまでそのユーザーは悪意あるコンテンツを継続して受け取り、ローカルのブラウザインスタンスのユーザーが被害に遭うことになります。

Cross-Site Scripting: アプリケーションから送信されるレスポンスを支配下に置いた攻撃者は、悪意あるさまざまなコンテンツをユーザーに提供できます。Cross-Site Scripting は一般的な攻撃形態で、レスポンスに含まれる悪意ある JavaScript などのコードがユーザーのブラウザーで実行されます。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。これは脆弱なアプリケーションのユーザーに対する最も一般的で危険な攻撃手段で、JavaScript を使用してセッション情報や Authentication 情報を攻撃者に送信し、攻撃対象のアカウントを完全に支配下に置きます。

ページ乗っ取り攻撃: 脆弱なアプリケーションを使用して悪意あるコンテンツをユーザーに送信するほか、このルート脆弱性を利用して、サーバーによって生成されたユーザー向けの機密性が高いコンテンツを攻撃者にリダイレクトすることもあります。攻撃者は、サーバーからの意図どおりのレスポンスと、攻撃者によって生成されたレスポンスの 2 つのレスポンスを生成させるリクエストを送信することで、サーバーにより生成されたレスポンスをユーザーではなく攻撃者に送信するよう共有プロキシ サーバーなどの中間ノードを操作する可能性があります。攻撃者により作成されたリクエストが 2 つのレスポンスを生成するため、最初のレスポンスは攻撃者のリクエストへのレスポンスとして解釈されますが、2 番目のレスポンスには行き先がありません。ユーザーが同一の TCP 接続を通して正しいリクエストをすると、待機していた攻撃者のリクエストが本来のユーザーのリクエストに対するレスポンスと解釈されます。続いて攻撃者は第 2 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。