6 見つかった項目
脆弱性
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーを設定するときには、注意が必要となります。

例: 次のコードセグメントは、ブログのエントリの作成者名 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 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
未検証のデータを HTTP レスポンス ヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie 不正操作、Open Redirectが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例 1: 次のコードは、攻撃者が制御可能な名前と値を含む HTTP ヘッダーを設定します。


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


名前と値のペアが authorJane Smith で構成されると想定した場合、このヘッダーを含む HTTP レスポンスは次のような形式になります。


HTTP/1.1 200 OK
...
author:Jane Smith
...


ただし、ヘッダーの値は未検証のユーザー入力から形成されるため、攻撃者が HTTP/1.1 200 OK\r\n...foobar などの悪意のある名前と値のペアを送信し、HTTP レスポンスが次の形式の 2 つのレスポンスに分割される場合があります。


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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 番目のリクエストを送信します。プロキシ サーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーや本文に含まれる機密情報が漏洩します。

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

Open Redirect: リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Microsoft .NET フレームワークの最新のバージョンでは、HttpResponse.AddHeader() メソッドに送信されるときに、CR、LF、および NULL 文字が %0d、%0a、および %00 に変換されます。最新の .NET フレームワークを使用しており、改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは 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.Text として送信された値に 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 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープン リダイレクト: リダイレクトで使用される URL を未検証の入力で制御することができる場合、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、またはページ乗っ取り攻撃が発生する可能性があります。
Explanation
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 ヘッダーを設定するときには、注意が必要となります。

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


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


「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 つのレスポンスを生成するため、最初のレスポンスは攻撃者のリクエストへのレスポンスとして解釈されますが、2 番目のレスポンスには行き先がありません。ユーザーが同一の TCP 接続を通して正しいリクエストをすると、待機していた攻撃者のリクエストが本来のユーザーのリクエストに対するレスポンスと解釈されます。続いて攻撃者は第 2 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
Header Manipulation の脆弱性が発生するのは次の場合です。

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

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

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

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 を Web フォームから読み取り、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 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
未検証のデータを HTTP レスポンス ヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie 不正操作、Open Redirect が発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例: 次のコード セグメントは、HTTP リクエストから「content-type」を読み取り、それを新しい HTTP リクエストのヘッダーに設定します。


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


「Content-Type」ヘッダーの値は未検証のユーザー入力で形成されるため、悪意のある攻撃者によって操作されて、脆弱性の悪用、コード インジェクション攻撃の実行、機密データの公開、悪意のあるファイルの実行の有効化、またはサービス拒否状況のトリガーが行われる可能性があり、アプリケーションのセキュリティと安定性に重大なリスクを引き起こします。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
未検証のデータを HTTP レスポンス ヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie 不正操作、Open Redirectが発生する可能性があります。
Explanation
Header Manipulation 脆弱性が発生するのは次の場合です。

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

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

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


攻撃者は任意の 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 番目のリクエストを送信します。プロキシ サーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーや本文に含まれる機密情報が漏洩します。

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

Open Redirect: リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Standards Mapping - Common Weakness Enumeration CWE ID 113
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例: 次のコードセグメントは、ブログのエントリの作成者名 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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。

クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーを設定するときには、注意が必要となります。

例: 次のコードセグメントは、ブログのエントリの作成者名 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 およびページ乗っ取り攻撃などの様々な攻撃を許すことになります。


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

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

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

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

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例: 次のコード セグメントで、namevalue が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


名前と値のペアが authorJane Smith で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。


HTTP/1.1 200 OK
...
author:Jane Smith
...


ただし、ヘッダーの値は未検証のユーザー入力から成るため、攻撃者が HTTP/1.1 200 OK\r\n...foobar などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、PHP の最近のバージョンでは、改行が header() 関数に渡されると、警告を生成し、ヘッダーの作成を中止します。使用している PHP のバージョンが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

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


<?php
$location = $_GET['some_location'];
...
header("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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーを設定するときには、注意が必要となります。

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


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


「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 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープン リダイレクト: リダイレクトで使用される URL を未検証の入力で制御することができる場合、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例: 次のコード セグメントは、ブログのエントリの作成者名 author を HTTP リクエストから読み取り、サイトの別の部分への get リクエストに使用します。


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


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


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


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


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie の不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。 たとえば、Play Framework では、禁止されている文字を含むヘッダーを設定しようとすると、例外が発生します。 使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。 しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。たとえば、Apache Tomcat の最近のバージョンでは、禁止されている文字を含むヘッダーを設定しようとすると、IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。

例: 次のコード セグメントで、namevalue が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


名前と値のペアが authorJane Smith で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。


HTTP/1.1 200 OK
...
author:Jane Smith
...


ただし、ヘッダーの値は未検証のユーザー入力から成るため、攻撃者が HTTP/1.1 200 OK\r\n...foobar などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 ヘッダーへの悪意ある文字の挿入を防ぐようになっています。しかし、標準的な ASP をサポートするサーバーの多くは保護機能を持っていません。

例: 次のコード セグメントは、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 のリクエストを送信します。プロキシサーバーは本来のユーザーのためにサーバーが生成したリクエストを使用してそれにレスポンスするため、このユーザー向けのレスポンスのヘッダーやボディに含まれる機密情報が漏洩します。

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

オープンリダイレクト: 入力が検証されないため、リダイレクトで使用される URL が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
未検証のデータを cookie に含めると HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie 不正操作、Open Redirectが発生する可能性があります。
Explanation
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 が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 を未検証の入力で制御することができる場合、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
未検証のデータを cookie に含めると HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie 不正操作、Open Redirectが発生する可能性があります。
Explanation
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 が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
未検証のデータを HTTP レスポンスヘッダーに含めると、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
未検証のデータを cookie に含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookie の不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
Cookie Manipulation の脆弱性が発生するのは次の場合です。

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

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

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

Cookie Manipulation: Cross-Site Request Forgery のような攻撃が同時に行われると、正規ユーザーの 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 ヘッダーを設定するときには、注意が必要となります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
未検証のデータをクッキーに含めると、HTTP Response Header Manipulation 攻撃につながり、キャッシュポイズニング、Cross-Site Scripting、クロスユーザー改竄、ページ乗っ取り攻撃、cookieの不正操作、またはオープンリダイレクトが発生する可能性があります。
Explanation
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 が制御され、フィッシング攻撃に悪用される可能性があります。
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
未検証のデータを SMTP ヘッダーに含めると、攻撃者は CCBCC などの任意のヘッダーを追加し、それを使用して、メールの内容を自身に漏らしたり、メール サーバーをスパム ボットとして悪用したりできます。
Explanation
SMTP Header Manipulation の脆弱性が発生するのは次の場合です。
1.信頼されていないソース (多くの場合、Web アプリケーションの HTTP リクエスト) からデータがアプリケーションに入り込んだ場合。

2.メール サーバーに送信される SMTP ヘッダーにデータが検証なしで含まれている場合。

多くのソフトウェア セキュリティの脆弱性と同様、SMTP Header Manipulation は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は脆弱なアプリケーションに悪意あるデータを渡し、アプリケーションがそのデータを SMTP ヘッダーに追加します。
SMTP Header Manipulation 攻撃の最もよくある手段の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メール アドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。
例: 次のコード セグメントは、[Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。

func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}

「Page not working」のような、標準的な英数字で構成されている文字列がリクエストで送信されたと仮定した場合、SMTP ヘッダーは次のような形式になります。

...
subject: [Contact us query] Page not working
...

ただし、ヘッダーの値は未検証のユーザー入力から形成されているので、レスポンスがこの形式を維持するのは、subject として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が、悪意のある文字列として "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." などを送信した場合、SMTP ヘッダーは次のような形式になります。

...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...

これにより、攻撃者は効果的にスパム メッセージを作成したり、他の攻撃の中でも匿名の電子メールを送信したりできます。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
未検証のデータを SMTP ヘッダーに追加すると、攻撃者は CCBCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。
Explanation
SMTP Header Manipulation (SMTP ヘッダー操作) の脆弱性が発生するのは次の場合です。

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

2.メール サーバーに送信される SMTP ヘッダーにデータが検証せずに追加された場合。

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

SMTP Header Manipulation (SMTP ヘッダー操作) 攻撃の最もよくある利用法の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メール アドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例: 次のコードセグメントは [Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


「Page not working」のような、標準的な英数字で構成されている文字列がリクエストで送信されたと仮定した場合、SMTP ヘッダーは次のような形式になります。


...
subject: [Contact us query] Page not working
...


ただし、ヘッダーの値は未検証のユーザー入力から形成されているので、レスポンスがこの形式を維持するのは、subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


これにより、攻撃者はスパム メッセージを作ったり、匿名電子メールを送信したりするなどの攻撃を行うことができます。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
未検証のデータを SMTP ヘッダーに追加すると、攻撃者は CCBCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。
Explanation
SMTP Header Manipulation (SMTP ヘッダー操作) の脆弱性が発生するのは次の場合です。

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

2.メール サーバーに送信される SMTP ヘッダーにデータが検証せずに追加された場合。

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

SMTP Header Manipulation 攻撃の最もよくある利用法の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メール アドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例: 次のコードセグメントは [Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


「Page not working」のような、標準的な英数字で構成されている文字列がリクエストで送信されたと仮定した場合、SMTP ヘッダーは次のような形式になります。


...
subject: [Contact us query] Page not working
...


ただし、ヘッダーの値は未検証のユーザー入力から形成されているので、レスポンスがこの形式を維持するのは、subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


これにより、攻撃者はスパム メッセージを作ったり、匿名電子メールを送信したりするなどの攻撃を行うことができます。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
未検証のデータを SMTP ヘッダーに追加すると、攻撃者は CCBCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メール サーバーをスパム ボットとして使用したりできます。
Explanation
SMTP Header Manipulation (SMTP ヘッダー操作) の脆弱性が発生するのは次の場合です。

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

2.メール サーバーに送信される SMTP ヘッダーにデータが検証せずに追加された場合。

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

SMTP Header Manipulation 攻撃の最もよくある利用法の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メール アドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例: 次のコードセグメントは [Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


「Page not working」のような、標準的な英数字で構成されている文字列がリクエストで送信されたと仮定した場合、SMTP ヘッダーは次のような形式になります。


...
subject: [Contact us query] Page not working
...


ただし、ヘッダーの値は未検証のユーザー入力から形成されているので、レスポンスがこの形式を維持するのは、subject として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が "Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..." といった悪意のある文字列を送信すると、SMTP ヘッダーは次の形式になります。


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


これにより、攻撃者はスパム メッセージを作ったり、匿名電子メールを送信したりするなどの攻撃を行うことができます。
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
顧客パスワードや社会保障番号などの個人情報の取り扱いを誤ると、ユーザーのプライバシーが危険にさらされるだけでなく、多くの場合に法律違反となります。
Explanation
次の場合に Privacy Violation が発生します。

1. ユーザーの個人情報がプログラムに持ち込まれる場合。

2. コンソール、File System、ネットワークなどの外部の場所にデータが書き込まれる場合。
例 1: 次のコードには、データベースに加えられたレコードのコンテンツをログ ファイルに格納して追跡するロギング ステートメントが含まれています。


pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);
Example 1 のコードでは、平文のパスワードがファイルシステムに記録されています。多くの開発者がファイルシステムをデータの安全な格納先として信頼しがちですが、特にプライバシーに関わる場合は盲目的に信頼しないでください。

プライバシーは、いくつかの理由により、モバイルの世界で最も懸念される事項の 1 つです。理由の 1 つは、デバイスをなくす機会が非常に多いことです。もう 1 つは、モバイルアプリケーション間のプロセス間通信にあります。モバイル プラットフォームでは、あちこちのソースからアプリケーションがダウンロードされ、同じデバイス上で一緒に実行されます。このため、たとえばバンキング アプリケーションのすぐそばでマルウェアを実行するなどの可能性が高くなるので、アプリケーションの開発者は、同じデバイスで実行されている他のアプリケーションに送信するメッセージにどの情報を含めるかについて十分注意する必要があります。機密性の高い情報は、モバイルアプリケーション間のプロセス間通信で扱われないようにする必要があります。

例 2: 次のコードは、Android WebView store から特定サイトのユーザー名とパスワードを読み取り、それを登録済みの全受信者に開示します。

...
webview.setWebViewClient(new WebViewClient() {
public void onReceivedHttpAuthRequest(WebView view,
HttpAuthHandler handler, String host, String realm) {
String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
String username = credentials[0];
String password = credentials[1];
Intent i = new Intent();
i.setAction("SEND_CREDENTIALS");
i.putExtra("username", username);
i.putExtra("password", password);
view.getContext().sendBroadcast(i);
}
});
...


この例では、いくつかの問題を示しています。まず、WebView の認証情報はデフォルトで平文によって保存されており、ハッシュされていません。ユーザーのデバイスがルート化されている (またはエミュレータを使用している) 場合、保存されている特定サイトのパスワードを読み取ることができます。次に、平文だけのの認証情報が登録済みの全受信者に開示されることは、SEND_CREDENTIALS アクションによってインテントに接続リクエストを行うように登録済みの受信者の誰もがメッセージを受信することを意味します。この開示は受信者数を制限する許可によっても保護されませんが、この場合対策として許可を使用することは推奨されません。

個人データがプログラムに持ち込まれる方法はさまざまです。

- パスワードや個人情報の形でユーザーが直接入力する。

- アプリケーションにより、データベースなどのデータストアからアクセスされる。

- パートナなどの第三者から間接的に持ち込まれる。

通常、モバイル環境の文脈では、機密情報に (パスワード、SSN、およびその他の一般的な個人情報加えて) 次を含みます。

- 場所

- 携帯電話番号

- シリアル番号およびデバイス ID

- ネットワーク オペレーター情報

- ボイスメール情報


個人情報と明記されていないデータも、別のコンテキストでは個人情報としての意味を持つことがあります。たとえば、学籍番号は、学生の個人情報に結びつくような明示的で公開されたマッピングがないので、通常、個人情報とは見なされません。しかし、学校が学生の社会保障番号に基づいて学籍番号を生成する場合は、学籍番号は個人情報と見なすべきです。

多くの場合、セキュリティとプライバシーの問題は互いに競い合っているかのようです。セキュリティの見地からは、異常な活動があった場合に後で識別できるように、重要な操作はすべて記録するべきです。ただし、個人データが関係する場合、それによりリスクが生じる可能性があります。

個人データの安全でない取り扱いにもさまざまな形態がありますが、一般的なリスクの原因は不適切な信頼にあります。多くの場合、プログラマはプログラムが実行される操作環境を信頼するので、個人情報を File System やレジストリなどのローカルに制御されているリソースに格納することも適切だと考えます。ただし、一部のリソースへのアクセスが制限されている場合も、実際にアクセス権を持っている個人なら信頼できるとは限りません。たとえば、2004 年には、AOL のある不心得な従業員が、約 9,200 万人の個人顧客の電子メール アドレスを、海外のギャンブル Web サイトのマーケティングをしているスパマーに販売しました [1]。

こうした悪用が注目を集めたため、個人データの収集と管理に関する規制は厳しさを増しています。会社などの所在地や業種、処理する個人データの性質によって異なりますが、以下に挙げる連邦や州の規制の遵守を求められる場合があります。

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

これらの規制にも関わらず、Privacy Violation はますます高い頻度で発生し続けています。
References
[1] J. Oates AOL man pleads guilty to selling 92m email addies The Register
[2] Privacy Initiatives U.S. Federal Trade Commission
[3] Safe Harbor Privacy Framework U.S. Department of Commerce
[4] Financial Privacy: The Gramm-Leach Bliley Act (GLBA) Federal Trade Commission
[5] Health Insurance Portability and Accountability Act (HIPAA) U.S. Department of Human Services
[6] California SB-1386 Government of the State of California
[7] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[8] SQLCipher.
[9] FUNDAMENTALS-4: Establish trust boundaries Oracle
[10] CONFIDENTIAL-2: Do not log highly sensitive information Oracle
[11] Standards Mapping - Common Weakness Enumeration CWE ID 359
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000169
[16] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), AU-12 Audit Generation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, AU-12 Audit Record Generation
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[24] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[25] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000650 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000650 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000650 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000650 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000650 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000650 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000650 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000650 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000650 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000650 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000650 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000650 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000650 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000650 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.java.pci_privacy_violation
Abstract
このプログラムはあいまいな方法で変数にアクセスするため、攻撃を受けやすくなります。
Explanation
HttpRequest クラスにより、プログラムは QueryStringFormCookies、または ServerVariables コレクションの変数に配列アクセスの形でアクセスすることができます (Request["myParam"] など)。同じ名前の変数が 2 個以上存在する場合、.NET フレームワークは次の順序でコレクションを検索して最初に検出した変数の値を返します。QueryStringFormCookiesServerVariablesQueryString は最初に検索されるため、QueryString のパラメーターがフォーム、cookie、およびサーバーの変数の値より優先される可能性があります。同様に、フォームの値は CookiesServerVariables コレクションの変数より優先され、Cookies コレクションの変数は ServerVariables の変数より優先される場合があります。
例 1: ユーザーの電子メールアドレスを一時的に cookie に保存しておき、そのユーザーに連絡する際にその値を読み取る、というバンキングアプリケーションを例に考えてみます。次のコードは cookie の値を読み取り、指定された電子メールアドレスに口座の残高を送信します。

...
String toAddress = Request["email"]; //Expects cookie value
Double balance = GetBalance(userID);
SendAccountBalance(toAddress, balance);
...
Example 1 のコードが http://www.example.com/GetBalance.aspx にアクセス中に実行されると仮定してみましょう。攻撃者が認証済みユーザーに http://www.example.com/GetBalance.aspx?email=evil%40evil.com をリクエストするリンクをクリックさせることができる場合、そのユーザーの口座残高が記載された電子メールは evil@evil.com に送信されてしまいます。
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[2] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[3] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[12] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing
Abstract
このプログラムはあいまいな方法でサーバー変数にアクセスするため、攻撃を受けやすくなります。
Explanation
HttpRequest クラスにより、プログラムは QueryStringFormCookies、または ServerVariables コレクションの変数に配列アクセスの形でアクセスすることができます (Request["myParam"] など)。同じ名前の変数が 2 個以上存在する場合、.NET フレームワークは次の順序でコレクションを検索して最初に検出した変数の値を返します。QueryStringFormCookiesServerVariablesQueryString は最初に検索されるため、QueryString のパラメーターがフォーム、cookie、およびサーバーの変数の値より優先される可能性があります。同様に、フォームの値は CookiesServerVariables コレクションの変数より優先され、Cookies コレクションの変数は ServerVariables の変数より優先される場合があります。
例 1: 次のコードは、コンテンツを表示する前に www.example.com からリクエストが送信されたことを確認するために、HTTP リファラー ヘッダーのサーバー変数をチェックしています。

...
if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
ServeContent();
else
Response.Redirect("http://www.example.com/");
...
Example 1 のコードが http://www.example.com/ProtectedImages.aspx にアクセス中に実行されると仮定してみましょう。攻撃者がこの URL に対して直接リクエストを送信すると、適切なリファラーヘッダーが設定されず、そのリクエストは失敗します。しかし、攻撃者が必要な値を持つ偽の HTTP_REFERER パラメーター (http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com など) を送信した場合には、このルックアップによって ServerVariables ではなく QueryString の値が返され、チェックに合格することになります。
References
[1] Microsoft IIS Server Variables
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[13] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing_server_variable