界: Input Validation and Representation

入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「Cross-Site Scripting」攻撃、「SQL Injection」などです。

175 見つかった項目
脆弱性
Abstract
ユーザー指定のデータを apex:iframe のソース URL として受け入れると、悪意のあるコンテンツが Visualforce ページにロードされることがあります。
Explanation
フレーム偽装の脆弱性は、次の場合に発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。

2. データが検証なしで iframe URL として使用される場合。

この方法の場合、攻撃者はインライン フレームにレンダリングする内容を制御できることがあります。フィッシング攻撃者は悪意のあるサイトを示すようにフレーム URL を変更することで、認証情報やその他の機密データを含むユーザー情報を盗もうとすることがあります。ベース ドメイン (Salesforce.com) が信頼できる場合、攻撃対象者はページを信頼して、要求されたすべての情報を提供します。

例 1: 次のコード例では、iframesrc URL パラメーターは apex:iframe のターゲット URL として直接使用されています。

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>


この方法では、攻撃者が対象者に悪意のある Web サイトに設定された iframesrc パラメーターを提供した場合、悪意のある Web サイトのコンテンツを使用してフレームがレンダリングされます。

<iframe src="http://evildomain.com/">
References
[1] Ryan C. Barnett Content Spoofing - TechTarget
[2] Salesforce Developers Technical Library Secure Coding Guidelines
desc.dataflow.apex.frame_spoofing
Abstract
信頼できないソースから Google Remote Procedure Call (gRPC) Metadata オブジェクトが作成されています。これにより、重要なプロトコル フィールドの制御を攻撃者に許してしまうおそれがあります。
Explanation
Metadata クラスは、Google Remote Procedure Call (gRPC) で使用される基本プロトコルのヘッダー データを格納するためによく使用されます。基盤となるプロトコルが HTTP の場合、Metadata オブジェクト内のデータを制御すると、システムが HTTP Header Manipulation に対して脆弱になる可能性があります。他の攻撃ベクトルが可能であり、主に基盤となるプロトコルに基づいています。

例 1: 次のコードは、gRPC Metadata オブジェクトへの入力として使用されるユーザー制御可能なデータを示しています。


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
desc.dataflow.java.grpc_metadata_manipulation
Abstract
プログラムにより、攻撃者は、クライアント アプリケーションを実行している Hadoop クラスターのコア コンポーネントを制御することが可能になります。
Explanation
Hadoop Cluster Control エラーが発生するのは次の場合です。

- 信頼できないソースからデータがプログラムに入り込んだ。

- データが NameNodeDataNodeJobTraker などの、Hadoop クラスターのコアコンポーネントで使用され、Hadoop クラスターの状態が変更された。

Hadoop クラスターは適さない環境です。クラスターノードへの未許可のアクセスから保護するセキュリティが適切に設定されていない場合、攻撃によってインフラストラクチャの制御権が奪われます。それにより、Hadoop クラスターから提供されるデータが改ざんされる可能性があります。

例 1: 以下のコードは、Hadoop クラスター マスター マシンのコマンドラインから入力を受け取る、典型的なクライアントアプリケーションの Job サブミッションを示しています。


public static void run(String args[]) throws IOException {

String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
適さない環境では、Hadoop クラスターに送信される Job が改ざんされる可能性があります。
Explanation
次の場合に Hadoop Job Manipulation エラーが発生します。

- 信頼できないソースからデータがプログラムに入り込んだ。

- データがクライアントジョブを制御する JobConf の値を指定するために使用された。

Hadoop クラスターは適さない環境です。クラスターマシン上の HDFS への未許可のアクセスから保護するセキュリティが適切に設定されていない場合、攻撃によって制御権が奪われます。それにより、Hadoop クラスターから提供されるデータが改ざんされている恐れが生じます。

例 1: 以下のコードは、Hadoop クラスター マスター マシンのコマンドラインから入力を受け取る、典型的なクライアントアプリケーションの Job サブミッションを示しています。


public void run(String args[]) throws IOException {

String inputDir = args[0];
String outputDir = args[1];

// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);

Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);

return job;
}
例 2: 次のコードは、攻撃者が実行中のジョブを制御してコマンドライン引数を使用して終了させるケースを示しています。


public static void main(String[] args) throws Exception {

JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();

}
desc.dataflow.java.hadoop_job_manipulation
Abstract
Handlebars テンプレートではエスケープが無効になっており、これにより、複数の新たな脆弱性が発生する可能性があります。
Explanation
Handlebars テンプレートで実行されるデフォルトのエスケープは、攻撃者からアプリケーションを保護するのに役立ちます。これにより、さまざまな種類の脆弱性を対象とした数々の攻撃を防ぐことができます。最も突出した保護は、特定の種類の Cross-Site Scripting 攻撃に対するものです。このアプリケーションでは、この保護メカニズムが明確に無効になっています。

例 1: 次の例は、Handlebars テンプレートのエスケープが無効になっている状態を示しています。

let template = Handlebars.compile('{{foo}}', { noEscape: true })
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 554
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[24] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.handlebars_misconfiguration_escaping_disabled
Abstract
プロトタイプは Handlebars テンプレートで許可されており、プロトタイプ汚染という脆弱性に対する攻撃の可能性が生じます。
Explanation
Handlebars テンプレートは、オブジェクトのプロトタイプにはアクセスできません。アプリケーションが Prototype Pollution 攻撃を受けやすくなるためです。

プロトタイプ汚染攻撃は、悪意のあるユーザーがオブジェクトのプロトタイプの関数またはプロパティを制御できる場合に発生します。テンプレートに渡されるオブジェクトのプロトタイプを制御することで、Dynamic Code Evaluation、Cross-Site Scripting、リモート コード実行などの数々の脆弱性が発生します。

例 1: Handlebars テンプレートを設定する次の例では、プロトタイプ メソッドがデフォルトで許可されているほか、特別な __defineGetter__ 関数が許可されています。

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
References
[1] Handlebars Runtime Options: Options to Control Prototype Access Handlebars
[2] Mahmoud Gamal Handlebars template injection and RCE in a Shopify app
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.javascript.handlebars_misconfiguration_prototypes_allowed
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
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
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
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
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
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」ヘッダーの値は未検証のユーザー入力で形成されるため、悪意のある攻撃者によって操作されて、脆弱性の悪用、コード インジェクション攻撃の実行、機密データの公開、悪意のあるファイルの実行の有効化、またはサービス拒否状況のトリガーが行われる可能性があり、アプリケーションのセキュリティと安定性に重大なリスクを引き起こします。
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
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
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
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
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
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
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
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 が制御され、フィッシング攻撃に悪用される可能性があります。
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
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
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
desc.dataflow.vb.header_manipulation