4 見つかった項目
脆弱性
Abstract
デバッグ メッセージは、攻撃者がシステムについて学び、攻撃の形態を計画するのに役立ちます。
Explanation
Android アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debuggable 属性 (<application> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。
References
[1] JavaDoc for Android Android
[2] Standards Mapping - Common Weakness Enumeration CWE ID 11
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[4] Standards Mapping - FIPS200 CM
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M10 Lack of Binary Protections
[10] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-RESILIENCE-4
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.android_misconfiguration_debug_information
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