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 ヘッダーを設定するときには、注意が必要となります。

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

...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。

cookie 不正操作脆弱性が発生するのは次の場合です。

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



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



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

cookie 不正操作: Cross-Site Request Forgery のような攻撃が同時に行われると、正規ユーザーの cookie が攻撃者によって変更、追加、上書きまでもされることがあります。

HTTP レスポンス ヘッダーでの cookie 不正操作攻撃は、次のようなタイプの攻撃にもつながります。

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 ヘッダーに設定します。

...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...

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

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

ただし、cookie の値は未検証のユーザー入力から形成されているので、レスポンスがこの形式を維持するのは、author として送信された値に 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、ページ乗っ取り攻撃などの様々な攻撃が許容されることになります。

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

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

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

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

Open Redirect: リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。

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

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

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

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

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 ヘッダーを設定するときには、注意が必要となります。

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

protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 を未検証の入力で制御することができる場合、フィッシング攻撃に悪用される可能性があります。

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 ヘッダーを設定するときには、注意が必要となります。

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

  <cfcookie name = "author"
  value = "#Form.author#"
  expires = "NOW">  

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。

cookie 不正操作脆弱性が発生するのは次の場合です。

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

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

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

Cookie Manipulation: Cross-Site Request Forgery のような攻撃が同時に行われると、正規ユーザーの cookie が攻撃者によって変更、追加、上書きまでもされることがあります。

HTTP レスポンス ヘッダーでの cookie 不正操作攻撃は、次のようなタイプの攻撃にもつながります。

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 ヘッダーを設定するときには、注意が必要となります。

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

...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
  Name:       "author",
  Value:      author,
  Domain:     "www.example.com",
}
http.SetCookie(w, &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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

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

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

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

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

Open Redirect: リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。

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 が制御され、フィッシング攻撃に悪用される可能性があります。

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

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

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

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

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 ヘッダーを設定するときには、注意が必要となります。

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

author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

Cross-User Defacement: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。

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 ヘッダーを設定するときには、注意が必要となります。

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

<?php
    $author = $_GET['AUTHOR_PARAM'];
    ...
    header("author: $author");
?>

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。

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

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

2. Web ユーザーに送信される HTTP レスポンスヘッダーにデータが検証せずに含まれている場合。

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

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

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

例: 次のコードセグメントは、location を HTTP リクエストから読み取り、HTTP レスポンスのヘッダーの location フ ィールドにセットします。

    location = req.field('some_location')
    ...
    response.addHeader("location",location)

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

HTTP/1.1 200 OK
...
location: index.html
...

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

HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...

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

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

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

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

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

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

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

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

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

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

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

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 ヘッダーを設定するときには、注意が必要となります。

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

...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...

「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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: 次の設定では、ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインを指定しています。

  <configuration>
   <system.webServer>
     <httpProtocol>
       <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*" />
       </customHeaders>
     </httpProtocol>
   </system.webServer>
  </configuration>

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、任意のドメインで実行されている JavaScript がアプリケーションのデータにアクセスできます。

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインをプログラミングにより指定している例を次に示します。

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、任意のドメインで実行されている JavaScript がアプリケーションのデータにアクセスできます。

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインをプログラミングにより指定している例を次に示します。

  <?php
    header('Access-Control-Allow-Origin: *');
  ?>

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインをプログラミングにより指定している例を次に示します。

response.addHeader("Access-Control-Allow-Origin", "*")

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインをプログラミングにより指定している例を次に示します。

  Response.AddHeader "Access-Control-Allow-Origin", "*"

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

このコードは CL_ABAP_RANDOM->INT31 関数を使用して、領収書ページの一意の識別子を生成します。CL_ABAP_RANDOM は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

このコードは Random.Next() 関数を使用して、領収書ページの一意の識別子を生成します。Random.Next() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

このコードは lrand48() 関数を使用して、領収書ページの一意の識別子を生成します。lrand48() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。


コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

このコードは Rand() 関数を使用して、領収書ページの一意の識別子を生成します。Rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供します。しかし、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは、統計的 PRNG を使用して RSA 鍵を作成します。

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

このコードは rand.New() 関数を使用して、RSA 鍵の乱数を生成します。rand.New() は統計的 PRNG なので、生成される値の推測は攻撃者にとってはたやすいことです。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次の Spring Boot 設定ファイルは、統計的 PRNG を使用して、セキュリティ上重要なトークンを作成します。

my.secret=${random.value}

このコードは Random.next() 関数を使用して、領収書ページの「一意の」識別子を生成します。Random.next() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

このコードは Math.random() 関数を使用して、領収書ページの一意の識別子を生成します。Math.random() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

このコードは Random.nextInt() 関数を使用して、領収書ページの「一意の」識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

このコードは rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

このコードは DBMS_RANDOM.SEED() 関数を使用して、領収書ページの一意の識別子を生成します。DBMS_RANDOM.SEED() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

このコードは rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

このコードは Kernel.rand() 関数を使用して、領収書ページの一意の識別子を生成します。Kernel.rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードでは、統計的 PRNG を使用してパスワードのリセット トークンとして使用されるランダムな値を作成します。

    sqlite3_randomness(10, &reset_token)

Insecure Randomness エラーが発生するのは、セキュリティが重要であるコンテキストで、ランダム性のソースとして、予期可能な値を生成する関数が使用される場合です。

コンピュータは決定論的な機械であるため、真のランダム性を生成することはできません。Pseudo-Random Number Generator (PRNG) はランダム性をアルゴリズムにより近似します。最初の値はシードと呼ばれ、後続の値はそこから計算されます。

PRNG には、統計的なものと暗号的なものがあります。統計的 PRNG は有用な統計上の特性を提供しますが、その出力はきわめて予測可能で、再現しやすい数値ストリームを形成するため、生成される値を予期できないことにセキュリティが依存している場合の使用には不適切です。この問題に対処するため、暗号的 PRNG は、より予期しにくい出力を生成します。値を暗号によって保護するためには、攻撃者が生成されたランダムな値と真にランダムな値を区別することが不可能か、または非常に困難である必要があります。一般的に、PRNG アルゴリズムは、暗号的に安全であると告知されていなければ統計的 PRNG である可能性が高く、セキュリティが重要なコンテキストで使用すべきではありません。PRNG アルゴリズムを使用することで、解読されやすい一時パスワードや暗号化キー、セッションハイジャック、DNS 偽装などの深刻な脆弱性が発生する可能性があります。

例: 次のコードは統計的 PRNG を使用して、購入後の一定期間利用できる領収書の URL を作成します。

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

このコードは Rnd() 関数を使用して、領収書ページの一意の識別子を生成します。Rnd() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (CL_ABAP_RANDOM クラスまたはそのバリアントなど) が特定の定数値を使用してシードされると、値を返すかまたは割り当てる GET_NEXT、INT および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1: 次の引用では、オブジェクト random_gen2 で生成される値は、オブジェクト random_gen1 から予想できます。

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

この例では、疑似乱数ジェネレータ、random_gen1 と random_gen2 が同じようにシードされたため、var1 = var2 となります

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。特定の値を使用して (srand(unsigned int) のような関数を使用) 疑似ランダム数値の生成機能 (rand() など) をシードすると、値を返すかまたは割り当てる rand() および類似のメソッドによって返される値は、攻撃者にとって予想可能になり、攻撃者が複数の PRNG 出力を収集できるようになります。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

この例では、randomNum1 と randomNum2 の結果は同一の方法でシードされているので、擬似ランダム数値の生成機能 srand(2223333) をシードするコール後の rand() への各コールは、結果的に同じコール実行順序で同じ出力になります。たとえば、出力は以下のようになります。

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

このような結果は決してランダムではありません。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (PRNG) が特定の値を使用 (math.Rand.New(Source) のような関数を使用) してシードされると、値を返すかまたは割り当てる math.Rand.Int() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

この例では、PRNG が同一の方法でシードされるため、擬似乱数ジェネレーターにシードを設定したコール (randomGen.Seed(12345)) の後に nextInt() をコールすると、同じ出力が同じ順序で得られます。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1:Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。

        Random randomGen1 = new Random();
        randomGen1.setSeed(12345);
        int randomInt1 = randomGen1.nextInt();
        byte[] bytes1 = new byte[4];
        randomGen1.nextBytes(bytes1);

        Random randomGen2 = new Random();
        randomGen2.setSeed(12345);
        int randomInt2 = randomGen2.nextInt();
        byte[] bytes2 = new byte[4];
        randomGen2.nextBytes(bytes2);

この例では、疑似乱数ジェネレータ、randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。

ランダム値または疑似ランダム値を生成する関数 (シードが渡される) を、定数の引数を使用してコールしないでください。疑似乱数ジェネレーター (Random など) が特定の値を使用 (Random(Int) のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。

例 1:Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

この例では、疑似乱数ジェネレータ、randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 byteArray1 と byteArray2 の値は等しくなります。

疑似ランダム値を生成する関数 (シードが渡される) を、整数の定数引数を使用してコールしないでください。疑似ランダム数値の生成機能が特定の値でシードされる場合、返される値が予測できます。

例 1: 疑似ランダム数値の生成機能で生成される値が、最初の 2 つのブロックで予測できます (どちらも同じシードで開始されるため)。

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

この例では、PRNG が同様にシードされているため、疑似ランダム数値の生成機能 (random.seed(123456)) をシードするコールの後の randint() への各コールの結果、同じものが同じ順序で出力されます。たとえば、出力は以下のようになります。

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

このような結果は決してランダムではありません。

クラス CL_ABAP_RANDOM (またはそのバリアント) を、汚染された引数を使用して初期化しないでください。そのような初期化を行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、以下のようなメソッド (これらに限りません) へのコールによって作成された値のシーケンスを攻撃者が予測できるようになります。 GET_NEXT, INT, FLOAT, PACKED.

ランダム値または疑似ランダム値 (rand() など) を生成する関数 (シード (srand() など) が渡される) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、擬似乱数生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。

疑似ランダム値を生成する関数 (ed25519.NewKeyFromSeed()) を、汚染された引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似乱数ジェネレータのシードに使用する値を制御できるようになるため、疑似乱数ジェネレータを呼び出したときに生成される一連の値を予測することができるようになります。

Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は擬似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。

Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextLong()、Random.nextDouble() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(ByteArray) で設定される値 (通常は整数) のシーケンスを予想できるようになります。

疑似ランダム値を生成する関数 (random.randint() など) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、疑似ランダム数値生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。このような場合は、暗号化された (安全な) プロトコルを使用する必要があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが送信されます。

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

受信する HttpResponse オブジェクトである res は、暗号化も認証もされていないチャネルを介して送信されるため、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、デバイスが WiFi 接続を経由して安全ではない公共のワイヤレス ネットワークに接続されることの多い場合、中間者 (Man-in-the-Middle) 攻撃にさらされる可能性があります。

例 1: 次のコードでは、(HTTPS プロトコルではなく) 安全でない HTTP プロトコルを使用しています。

    var account = new CloudStorageAccount(storageCredentials, false);

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

入力レスポンス response は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用して Web サーバーがセットアップされます。

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の Spring Boot 設定ファイルは、TLS プロトコルを無効にし、その結果 HTTP プロトコルを使用します。

server.ssl.enabled=false

例 2: 次の Spring 構成ファイルは、HTTP プロトコルの使用を必須としています。

      <intercept-url pattern="/member/**"  access="ROLE_USER" requires-channel="http"/>

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

入力 http.IncomingMessage オブジェクトの res は、暗号化されていない未認証のチャネルを介して配信されるので危険にさらされています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、ソケットの暗号化を無効にします。

...
stream_socket_enable_crypto($fp, false);
...

安全でない、暗号化されていない、または平文のプロトコルで送信されるすべての通信は、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、悪用される対象となります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

入力ストリーム in は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

JSONP は、設計上クロスドメインリクエストの実行を許可しますが、リクエスト元を制限および検証するための仕組みは用意されていません。悪意あるサイトがユーザーになりすまして簡単に JSONP リクエストを実行し、JSON レスポンスを処理することが可能です。このため、PII または機密データが送信されるときには、この通信技術を使用しないことを強く推奨します。
JSONP は、JSON の適切な処理のために要求側サイトにコールバック関数名を反映する必要があるため、XSS 攻撃を自ら招くように設計されています。JavaScript インジェクションを回避するために、コールバック関数名を検証し、不要な部分を削除する必要があります。コールバック関数名の不要な部分を削除するためには、可能な場合は許可リストの導入を検討するか、文字を英数字のみに制限します。