コーダーがセキュリティを征服：シェア＆ラーニングシリーズ-CRLF インジェクション
今回のようなブログや記事では、句読点が読者の助けになります。例えば、ピリオドは文章の終わりを読者に伝えますし、コンマはリストの中で記事を区切ったり、アイデアを分けるために固い間を入れたりします。このブログのようによく書かれたブログでは、句読点はほとんど目立たず、私たちが何年も前に処理することを学んだ標準的な背景コードの一部に過ぎません。
でも、もしハッカーがこの記事に入り込んで、変な句読点を間違った場所に挿入したらどうなるでしょう？こんな感じで。
テキストを変更することなく、情報を処理することが非常に困難になります。
これは基本的にCRLFインジェクション攻撃で起こることです。CRLFとは、キャリッジリターンとラインフィードの略で、行の終わりを示すために単独または組み合わせて使用されます。攻撃者が既存のアプリケーションにCRやLFのコードを挿入することができれば、時にはアプリケーションの動作を変更することができます。その効果は一般的な攻撃に比べて予測が困難ですが、標的となる組織にとってはそれに劣らず危険です。
このエピソードでは、以下のことを学びます。
- 攻撃者がCRLFインジェクションを引き起こす方法
- なぜCRLFの注射は危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにしてCRLFインジェクションを引き起こすのでしょうか？
既存のコードにCRLF文字を挿入し、特定の結果を得ようとすることは、不可能ではないものの、かなり困難です。それが難しいのは、攻撃者がオペレーティングシステムや対象となるシステムのその他の要素に応じて、異なるCRLFの組み合わせを使用する必要があるからです。例えば、最新のWindowsマシンでは、行末にCRとLFの両方が必要ですが、LinuxではLFのコードのみが必要です。HTTPリクエストでは、行末に必ず正確なCRLFコードが必要です。
しかし、CRLF攻撃は実装が難しく、その結果を予測するのも難しいという事実に加え、他のインジェクションタイプの攻撃とほぼ同様の方法で開始されます。悪意のあるユーザーは、ウェブサイトやアプリケーション上の入力可能な領域にデータを入力しますが、その際、通常の入力データの代わりに、または入力データの後にCRLFコードを入力します。
例えば、攻撃者は HTTPS ヘッダーの最後に、キャリッジリターン（%0d）を表す ASCII コードと、それに続くラインフィード（%0a）を表す ASCII コードを入力することができる。すると、クエリ全体は次のようになります。
https://validsite.com/index.php?page=home%0d%0a
データがサニタイズされていなかったり、フィルタリングされていなかったりすると、上記のコードによって対象となるアプリケーションやWebサイトでおかしなことが起こる可能性があります。
なぜCRLFの注射は危険なのか？
CRLF インジェクションによる攻撃は、他の攻撃に比べて精度が低いものの、少なくとも一部の場合はかなり危険です。低レベルでは、余分な行を追加することでログファイルが混乱し、サイバーセキュリティの自動防御機能が作動して管理者に問題のないことを警告するかもしれません。しかし、これを利用して、同時期に発生している実際の侵入行為からリソースをそらすことも可能です。
しかし、CRLF攻撃は直接ダメージを与えることもあります。例えば、コマンドを受け付けてから特定のファイルを検索するように設計されているアプリケーションの場合、クエリにCRLFコードを追加すると、アプリケーションがその処理を隠したままではなく画面に表示するきっかけとなり、攻撃者にとって貴重な情報となる可能性があります。
CRLF を注入することで、行末のコードが有効なレスポンスを複数に分割してしまう、いわゆるレスポンス・スプリッティング攻撃を行うこともできます。これにより、ハッカーはCRLFコードの後のヘッダーをコントロールできるようになり、それを利用して追加コードを注入することができます。また、CRLF攻撃によって破壊された部分に続く行に、攻撃者が自分のコードを完全に注入できるような隙を作り、別の攻撃を引き起こす可能性もあります。
CRLFインジェクション脆弱性の解消
このシリーズから得られる重要なメッセージがあるとすれば、それは「ユーザーの入力を絶対に信用してはいけない」ということです。本連載で取り上げた脆弱性のほとんどは、何らかの形でユーザーの入力領域に関わっており、CRLFインジェクションの欠陥も例外ではありません。
ユーザーが入力する箇所には、アプリケーションやサーバが誤って解釈する可能性のある不正なコードの注入を防ぐためのフィルタを適用する必要があります。CRLF 攻撃では、HTTP ヘッダのロックダウンが特に重要ですが、GET や POST のパラメータ、さらには Cookie も忘れてはなりません。CRLFコードがさらなるインジェクションの引き金にならないようにするには、ユーザーのブラウザに送信されるすべてのデータにHTMLエンコーディングを適用することが有効です。
CRLFインジェクションの詳細情報
さらに詳しい情報は、OWASPがCRLFインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
攻撃者が既存のアプリケーションに CR または LF コードを挿入できれば、その動作を変更できることがあります。ほとんどの攻撃に比べて、その影響を予測するのは簡単ではありませんが、標的となる組織にとっても同様に危険です。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
今回のようなブログや記事では、句読点が読者の助けになります。例えば、ピリオドは文章の終わりを読者に伝えますし、コンマはリストの中で記事を区切ったり、アイデアを分けるために固い間を入れたりします。このブログのようによく書かれたブログでは、句読点はほとんど目立たず、私たちが何年も前に処理することを学んだ標準的な背景コードの一部に過ぎません。
でも、もしハッカーがこの記事に入り込んで、変な句読点を間違った場所に挿入したらどうなるでしょう？こんな感じで。
テキストを変更することなく、情報を処理することが非常に困難になります。
これは基本的にCRLFインジェクション攻撃で起こることです。CRLFとは、キャリッジリターンとラインフィードの略で、行の終わりを示すために単独または組み合わせて使用されます。攻撃者が既存のアプリケーションにCRやLFのコードを挿入することができれば、時にはアプリケーションの動作を変更することができます。その効果は一般的な攻撃に比べて予測が困難ですが、標的となる組織にとってはそれに劣らず危険です。
このエピソードでは、以下のことを学びます。
- 攻撃者がCRLFインジェクションを引き起こす方法
- なぜCRLFの注射は危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにしてCRLFインジェクションを引き起こすのでしょうか？
既存のコードにCRLF文字を挿入し、特定の結果を得ようとすることは、不可能ではないものの、かなり困難です。それが難しいのは、攻撃者がオペレーティングシステムや対象となるシステムのその他の要素に応じて、異なるCRLFの組み合わせを使用する必要があるからです。例えば、最新のWindowsマシンでは、行末にCRとLFの両方が必要ですが、LinuxではLFのコードのみが必要です。HTTPリクエストでは、行末に必ず正確なCRLFコードが必要です。
しかし、CRLF攻撃は実装が難しく、その結果を予測するのも難しいという事実に加え、他のインジェクションタイプの攻撃とほぼ同様の方法で開始されます。悪意のあるユーザーは、ウェブサイトやアプリケーション上の入力可能な領域にデータを入力しますが、その際、通常の入力データの代わりに、または入力データの後にCRLFコードを入力します。
例えば、攻撃者は HTTPS ヘッダーの最後に、キャリッジリターン（%0d）を表す ASCII コードと、それに続くラインフィード（%0a）を表す ASCII コードを入力することができる。すると、クエリ全体は次のようになります。
https://validsite.com/index.php?page=home%0d%0a
データがサニタイズされていなかったり、フィルタリングされていなかったりすると、上記のコードによって対象となるアプリケーションやWebサイトでおかしなことが起こる可能性があります。
なぜCRLFの注射は危険なのか？
CRLF インジェクションによる攻撃は、他の攻撃に比べて精度が低いものの、少なくとも一部の場合はかなり危険です。低レベルでは、余分な行を追加することでログファイルが混乱し、サイバーセキュリティの自動防御機能が作動して管理者に問題のないことを警告するかもしれません。しかし、これを利用して、同時期に発生している実際の侵入行為からリソースをそらすことも可能です。
しかし、CRLF攻撃は直接ダメージを与えることもあります。例えば、コマンドを受け付けてから特定のファイルを検索するように設計されているアプリケーションの場合、クエリにCRLFコードを追加すると、アプリケーションがその処理を隠したままではなく画面に表示するきっかけとなり、攻撃者にとって貴重な情報となる可能性があります。
CRLF を注入することで、行末のコードが有効なレスポンスを複数に分割してしまう、いわゆるレスポンス・スプリッティング攻撃を行うこともできます。これにより、ハッカーはCRLFコードの後のヘッダーをコントロールできるようになり、それを利用して追加コードを注入することができます。また、CRLF攻撃によって破壊された部分に続く行に、攻撃者が自分のコードを完全に注入できるような隙を作り、別の攻撃を引き起こす可能性もあります。
CRLFインジェクション脆弱性の解消
このシリーズから得られる重要なメッセージがあるとすれば、それは「ユーザーの入力を絶対に信用してはいけない」ということです。本連載で取り上げた脆弱性のほとんどは、何らかの形でユーザーの入力領域に関わっており、CRLFインジェクションの欠陥も例外ではありません。
ユーザーが入力する箇所には、アプリケーションやサーバが誤って解釈する可能性のある不正なコードの注入を防ぐためのフィルタを適用する必要があります。CRLF 攻撃では、HTTP ヘッダのロックダウンが特に重要ですが、GET や POST のパラメータ、さらには Cookie も忘れてはなりません。CRLFコードがさらなるインジェクションの引き金にならないようにするには、ユーザーのブラウザに送信されるすべてのデータにHTMLエンコーディングを適用することが有効です。
CRLFインジェクションの詳細情報
さらに詳しい情報は、OWASPがCRLFインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
今回のようなブログや記事では、句読点が読者の助けになります。例えば、ピリオドは文章の終わりを読者に伝えますし、コンマはリストの中で記事を区切ったり、アイデアを分けるために固い間を入れたりします。このブログのようによく書かれたブログでは、句読点はほとんど目立たず、私たちが何年も前に処理することを学んだ標準的な背景コードの一部に過ぎません。
でも、もしハッカーがこの記事に入り込んで、変な句読点を間違った場所に挿入したらどうなるでしょう？こんな感じで。
テキストを変更することなく、情報を処理することが非常に困難になります。
これは基本的にCRLFインジェクション攻撃で起こることです。CRLFとは、キャリッジリターンとラインフィードの略で、行の終わりを示すために単独または組み合わせて使用されます。攻撃者が既存のアプリケーションにCRやLFのコードを挿入することができれば、時にはアプリケーションの動作を変更することができます。その効果は一般的な攻撃に比べて予測が困難ですが、標的となる組織にとってはそれに劣らず危険です。
このエピソードでは、以下のことを学びます。
- 攻撃者がCRLFインジェクションを引き起こす方法
- なぜCRLFの注射は危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにしてCRLFインジェクションを引き起こすのでしょうか？
既存のコードにCRLF文字を挿入し、特定の結果を得ようとすることは、不可能ではないものの、かなり困難です。それが難しいのは、攻撃者がオペレーティングシステムや対象となるシステムのその他の要素に応じて、異なるCRLFの組み合わせを使用する必要があるからです。例えば、最新のWindowsマシンでは、行末にCRとLFの両方が必要ですが、LinuxではLFのコードのみが必要です。HTTPリクエストでは、行末に必ず正確なCRLFコードが必要です。
しかし、CRLF攻撃は実装が難しく、その結果を予測するのも難しいという事実に加え、他のインジェクションタイプの攻撃とほぼ同様の方法で開始されます。悪意のあるユーザーは、ウェブサイトやアプリケーション上の入力可能な領域にデータを入力しますが、その際、通常の入力データの代わりに、または入力データの後にCRLFコードを入力します。
例えば、攻撃者は HTTPS ヘッダーの最後に、キャリッジリターン（%0d）を表す ASCII コードと、それに続くラインフィード（%0a）を表す ASCII コードを入力することができる。すると、クエリ全体は次のようになります。
https://validsite.com/index.php?page=home%0d%0a
データがサニタイズされていなかったり、フィルタリングされていなかったりすると、上記のコードによって対象となるアプリケーションやWebサイトでおかしなことが起こる可能性があります。
なぜCRLFの注射は危険なのか？
CRLF インジェクションによる攻撃は、他の攻撃に比べて精度が低いものの、少なくとも一部の場合はかなり危険です。低レベルでは、余分な行を追加することでログファイルが混乱し、サイバーセキュリティの自動防御機能が作動して管理者に問題のないことを警告するかもしれません。しかし、これを利用して、同時期に発生している実際の侵入行為からリソースをそらすことも可能です。
しかし、CRLF攻撃は直接ダメージを与えることもあります。例えば、コマンドを受け付けてから特定のファイルを検索するように設計されているアプリケーションの場合、クエリにCRLFコードを追加すると、アプリケーションがその処理を隠したままではなく画面に表示するきっかけとなり、攻撃者にとって貴重な情報となる可能性があります。
CRLF を注入することで、行末のコードが有効なレスポンスを複数に分割してしまう、いわゆるレスポンス・スプリッティング攻撃を行うこともできます。これにより、ハッカーはCRLFコードの後のヘッダーをコントロールできるようになり、それを利用して追加コードを注入することができます。また、CRLF攻撃によって破壊された部分に続く行に、攻撃者が自分のコードを完全に注入できるような隙を作り、別の攻撃を引き起こす可能性もあります。
CRLFインジェクション脆弱性の解消
このシリーズから得られる重要なメッセージがあるとすれば、それは「ユーザーの入力を絶対に信用してはいけない」ということです。本連載で取り上げた脆弱性のほとんどは、何らかの形でユーザーの入力領域に関わっており、CRLFインジェクションの欠陥も例外ではありません。
ユーザーが入力する箇所には、アプリケーションやサーバが誤って解釈する可能性のある不正なコードの注入を防ぐためのフィルタを適用する必要があります。CRLF 攻撃では、HTTP ヘッダのロックダウンが特に重要ですが、GET や POST のパラメータ、さらには Cookie も忘れてはなりません。CRLFコードがさらなるインジェクションの引き金にならないようにするには、ユーザーのブラウザに送信されるすべてのデータにHTMLエンコーディングを適用することが有効です。
CRLFインジェクションの詳細情報
さらに詳しい情報は、OWASPがCRLFインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
今回のようなブログや記事では、句読点が読者の助けになります。例えば、ピリオドは文章の終わりを読者に伝えますし、コンマはリストの中で記事を区切ったり、アイデアを分けるために固い間を入れたりします。このブログのようによく書かれたブログでは、句読点はほとんど目立たず、私たちが何年も前に処理することを学んだ標準的な背景コードの一部に過ぎません。
でも、もしハッカーがこの記事に入り込んで、変な句読点を間違った場所に挿入したらどうなるでしょう？こんな感じで。
テキストを変更することなく、情報を処理することが非常に困難になります。
これは基本的にCRLFインジェクション攻撃で起こることです。CRLFとは、キャリッジリターンとラインフィードの略で、行の終わりを示すために単独または組み合わせて使用されます。攻撃者が既存のアプリケーションにCRやLFのコードを挿入することができれば、時にはアプリケーションの動作を変更することができます。その効果は一般的な攻撃に比べて予測が困難ですが、標的となる組織にとってはそれに劣らず危険です。
このエピソードでは、以下のことを学びます。
- 攻撃者がCRLFインジェクションを引き起こす方法
- なぜCRLFの注射は危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにしてCRLFインジェクションを引き起こすのでしょうか？
既存のコードにCRLF文字を挿入し、特定の結果を得ようとすることは、不可能ではないものの、かなり困難です。それが難しいのは、攻撃者がオペレーティングシステムや対象となるシステムのその他の要素に応じて、異なるCRLFの組み合わせを使用する必要があるからです。例えば、最新のWindowsマシンでは、行末にCRとLFの両方が必要ですが、LinuxではLFのコードのみが必要です。HTTPリクエストでは、行末に必ず正確なCRLFコードが必要です。
しかし、CRLF攻撃は実装が難しく、その結果を予測するのも難しいという事実に加え、他のインジェクションタイプの攻撃とほぼ同様の方法で開始されます。悪意のあるユーザーは、ウェブサイトやアプリケーション上の入力可能な領域にデータを入力しますが、その際、通常の入力データの代わりに、または入力データの後にCRLFコードを入力します。
例えば、攻撃者は HTTPS ヘッダーの最後に、キャリッジリターン（%0d）を表す ASCII コードと、それに続くラインフィード（%0a）を表す ASCII コードを入力することができる。すると、クエリ全体は次のようになります。
https://validsite.com/index.php?page=home%0d%0a
データがサニタイズされていなかったり、フィルタリングされていなかったりすると、上記のコードによって対象となるアプリケーションやWebサイトでおかしなことが起こる可能性があります。
なぜCRLFの注射は危険なのか？
CRLF インジェクションによる攻撃は、他の攻撃に比べて精度が低いものの、少なくとも一部の場合はかなり危険です。低レベルでは、余分な行を追加することでログファイルが混乱し、サイバーセキュリティの自動防御機能が作動して管理者に問題のないことを警告するかもしれません。しかし、これを利用して、同時期に発生している実際の侵入行為からリソースをそらすことも可能です。
しかし、CRLF攻撃は直接ダメージを与えることもあります。例えば、コマンドを受け付けてから特定のファイルを検索するように設計されているアプリケーションの場合、クエリにCRLFコードを追加すると、アプリケーションがその処理を隠したままではなく画面に表示するきっかけとなり、攻撃者にとって貴重な情報となる可能性があります。
CRLF を注入することで、行末のコードが有効なレスポンスを複数に分割してしまう、いわゆるレスポンス・スプリッティング攻撃を行うこともできます。これにより、ハッカーはCRLFコードの後のヘッダーをコントロールできるようになり、それを利用して追加コードを注入することができます。また、CRLF攻撃によって破壊された部分に続く行に、攻撃者が自分のコードを完全に注入できるような隙を作り、別の攻撃を引き起こす可能性もあります。
CRLFインジェクション脆弱性の解消
このシリーズから得られる重要なメッセージがあるとすれば、それは「ユーザーの入力を絶対に信用してはいけない」ということです。本連載で取り上げた脆弱性のほとんどは、何らかの形でユーザーの入力領域に関わっており、CRLFインジェクションの欠陥も例外ではありません。
ユーザーが入力する箇所には、アプリケーションやサーバが誤って解釈する可能性のある不正なコードの注入を防ぐためのフィルタを適用する必要があります。CRLF 攻撃では、HTTP ヘッダのロックダウンが特に重要ですが、GET や POST のパラメータ、さらには Cookie も忘れてはなりません。CRLFコードがさらなるインジェクションの引き金にならないようにするには、ユーザーのブラウザに送信されるすべてのデータにHTMLエンコーディングを適用することが有効です。
CRLFインジェクションの詳細情報
さらに詳しい情報は、OWASPがCRLFインジェクションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
%20(1).avif)
.avif)
