トロイの木馬ソースとは何であり、ソースコードにどのように潜り込むのでしょうか？
11月初旬、ケンブリッジ大学は「 トロイの木馬-ソース」と題する 研究を発表しました。この 研究は、方向性書式指定文字を用いてソースコードやコメントにバックドアを隠蔽する手法に焦点を当てています。これにより、コンパイラが人間のコードレビュー担当者と異なる方法でロジックを解釈するコードを生成することが可能となります。
以前、Unicodeがファイルの実際の拡張子を隠すなど悪用された事例はあったものの、この脆弱性は新たに発生したものです。ファイル名の末尾部分の方向転換。最近の研究によれば、多くのコンパイラは警告なしにソースコード内のユニコード文字を無視する一方、コードエディタを含むテキストエディタはこれに基づいてコメントとコードを含む行を再配置（リフロー）することが可能です。したがってエディタは、コンパイラが解析する方法とは異なる順序でコードとコメントを表示することができ、コードとコメントを交換する場合でも同様です。
詳細を知りたい場合は読み進めてください。またはトロイの木馬ソースのハッキングシミュレーションを試してみたい場合は、無料で提供されているサービスにすぐにアクセスしてみてください。公共任務を直接体験してください。
双方向テキスト
これらのトロイの木馬攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用します。このアルゴリズムは、英語（左から右）やアラビア語（右から左）のように表示順序が異なるテキストの整列方法を処理します。方向書式指定文字を使用してグループを再構成し、文字の順序を表示することができます。
上記の表には攻撃に関連する一部のBidiオーバーライド文字が含まれています。例えば、
RLIe d o cPD
略語RLIは以下を表します。右から左への分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップディレクショナルアイソレート）をクリックし、右から左へ読みます。結果は次の通りです。
C O D E
しかしコンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含む書式制御文字を処理しません。方向性書式指定文字を単に無視すると、次のように解析されます。
E D O C
新しい瓶に入った古いワイン？
もちろんこれは太陽の下で新しいことではありません。過去には方向指定文字が使用されていました。ファイル名に挿入され、その悪意のある性質を隠すためです。「myspecialexe.doc」と表示されたメール添付ファイルは、RLO（右から左へのオーバーライド）がなければ十分に無邪気に見えたかもしれません。実際の名前が「myspecialcod.exe」であることを示す文字の贈り物でした。
トロイの木馬ソース攻撃は、ソースコード内のコメントや文字列に方向指定文字を挿入します。これらの制御文字は、構文エラーやコンパイルエラーを引き起こさないためです。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るようにします。
例えば、次のバイトを順に含むファイル:
方向指定文字ごとに以下のように再配置されます。
方向指定文字が明示的に呼び出されていない場合、コードは次のようにレンダリングされます。
RLOは最後の行で閉じる中括弧を開く中括弧に反転し、その逆も同様です。このコードを実行すると、次のような結果が出力されます。「あなたは管理者です。」管理者チェックはコメントアウトされていますが、制御文字を見ると、そのチェックが依然として存在していたという印象を与えます。
(出典: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これは皆様にどのような影響を与える可能性があるでしょうか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど多くの言語が攻撃に対して脆弱であり、 さらに多くの言語が攻撃に脆弱であると推定されます。一般の開発者はソースコード内の方向指定文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えない方が良いかもしれません。さらに、これらの文字の可視化はIDEによって大きく異なるため、発見される保証はありません。
しかし、そもそもこの脆弱性はどのようにソースコードに潜入できたのでしょうか？何よりもまず、信頼できないソースからのソースコードを使用する際、悪意のあるコードの混入が気づかれないまま発生する可能性があります。第二に、インターネットで見つけたコードをコピー＆ペーストするだけで、このような事態が起こり得ます。 私たちの開発者のほとんどが過去に経験したことでしょう。ほとんどの組織は複数のベンダーのソフトウェアコンポーネントに依存しています。これにより、このコードをどの程度信頼し、依存できるかという疑問が生じます。隠されたバックドアを含むソースコードをどのように選別できるでしょうか？
誰の問題でしょうか？
一方、コンパイラとビルドパイプラインは、一方向が文字列やコメントで厳密に制限されていない限り、複数の方向を持つソースコード行を許可すべきではありません。なお、文字列やコメントの方向指定文字は、ポップされない場合、行末まで方向変更を延長できます。一般的にコードエディタは、ホモグリフや方向指定文字など疑わしいユニコード文字を明示的にレンダリングし強調表示すべきです。11月からGitHubは、双方向ユニコードテキストを含む全てのコード行に警告記号とメッセージを追加します。 ただし、これらの文字の行位置は強調表示されません。これにより、悪意のある方向変更が依然として潜入する可能性があります。
開発者とコードレビュアー間の認識は不可欠であるため、脆弱性を説明するガイダンスを作成しました。現在この練習はJava、C#、Python、GO、PHPで利用可能です。
より詳しく知りたい場合は、当社の製品をお試しください。トロイソースシミュレーション（公開ミッション）、そしてトロイソースリサーチをお読みください。
セキュアコードウォリアーは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を組織に根付かせるために存在します。AppSec管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、組織が安全でないコードに関連するリスクを軽減できるよう支援します。
デモ予約
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は「 トロイの木馬-ソース」と題する 研究を発表しました。この 研究は、方向性書式指定文字を用いてソースコードやコメントにバックドアを隠蔽する手法に焦点を当てています。これにより、コンパイラが人間のコードレビュー担当者と異なる方法でロジックを解釈するコードを生成することが可能となります。
以前、Unicodeがファイルの実際の拡張子を隠すなど悪用された事例はあったものの、この脆弱性は新たに発生したものです。ファイル名の末尾部分の方向転換。最近の研究によれば、多くのコンパイラは警告なしにソースコード内のユニコード文字を無視する一方、コードエディタを含むテキストエディタはこれに基づいてコメントとコードを含む行を再配置（リフロー）することが可能です。したがってエディタは、コンパイラが解析する方法とは異なる順序でコードとコメントを表示することができ、コードとコメントを交換する場合でも同様です。
詳細を知りたい場合は読み進めてください。またはトロイの木馬ソースのハッキングシミュレーションを試してみたい場合は、無料で提供されているサービスにすぐにアクセスしてみてください。公共任務を直接体験してください。
双方向テキスト
これらのトロイの木馬攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用します。このアルゴリズムは、英語（左から右）やアラビア語（右から左）のように表示順序が異なるテキストの整列方法を処理します。方向書式指定文字を使用してグループを再構成し、文字の順序を表示することができます。
上記の表には攻撃に関連する一部のBidiオーバーライド文字が含まれています。例えば、
RLIe d o cPD
略語RLIは以下を表します。右から左への分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップディレクショナルアイソレート）をクリックし、右から左へ読みます。結果は次の通りです。
C O D E
しかしコンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含む書式制御文字を処理しません。方向性書式指定文字を単に無視すると、次のように解析されます。
E D O C
新しい瓶に入った古いワイン？
もちろんこれは太陽の下で新しいことではありません。過去には方向指定文字が使用されていました。ファイル名に挿入され、その悪意のある性質を隠すためです。「myspecialexe.doc」と表示されたメール添付ファイルは、RLO（右から左へのオーバーライド）がなければ十分に無邪気に見えたかもしれません。実際の名前が「myspecialcod.exe」であることを示す文字の贈り物でした。
トロイの木馬ソース攻撃は、ソースコード内のコメントや文字列に方向指定文字を挿入します。これらの制御文字は、構文エラーやコンパイルエラーを引き起こさないためです。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るようにします。
例えば、次のバイトを順に含むファイル:
方向指定文字ごとに以下のように再配置されます。
方向指定文字が明示的に呼び出されていない場合、コードは次のようにレンダリングされます。
RLOは最後の行で閉じる中括弧を開く中括弧に反転し、その逆も同様です。このコードを実行すると、次のような結果が出力されます。「あなたは管理者です。」管理者チェックはコメントアウトされていますが、制御文字を見ると、そのチェックが依然として存在していたという印象を与えます。
(出典: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これは皆様にどのような影響を与える可能性があるでしょうか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど多くの言語が攻撃に対して脆弱であり、 さらに多くの言語が攻撃に脆弱であると推定されます。一般の開発者はソースコード内の方向指定文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えない方が良いかもしれません。さらに、これらの文字の可視化はIDEによって大きく異なるため、発見される保証はありません。
しかし、そもそもこの脆弱性はどのようにソースコードに潜入できたのでしょうか？何よりもまず、信頼できないソースからのソースコードを使用する際、悪意のあるコードの混入が気づかれないまま発生する可能性があります。第二に、インターネットで見つけたコードをコピー＆ペーストするだけで、このような事態が起こり得ます。 私たちの開発者のほとんどが過去に経験したことでしょう。ほとんどの組織は複数のベンダーのソフトウェアコンポーネントに依存しています。これにより、このコードをどの程度信頼し、依存できるかという疑問が生じます。隠されたバックドアを含むソースコードをどのように選別できるでしょうか？
誰の問題でしょうか？
一方、コンパイラとビルドパイプラインは、一方向が文字列やコメントで厳密に制限されていない限り、複数の方向を持つソースコード行を許可すべきではありません。なお、文字列やコメントの方向指定文字は、ポップされない場合、行末まで方向変更を延長できます。一般的にコードエディタは、ホモグリフや方向指定文字など疑わしいユニコード文字を明示的にレンダリングし強調表示すべきです。11月からGitHubは、双方向ユニコードテキストを含む全てのコード行に警告記号とメッセージを追加します。 ただし、これらの文字の行位置は強調表示されません。これにより、悪意のある方向変更が依然として潜入する可能性があります。
開発者とコードレビュアー間の認識は不可欠であるため、脆弱性を説明するガイダンスを作成しました。現在この練習はJava、C#、Python、GO、PHPで利用可能です。
より詳しく知りたい場合は、当社の製品をお試しください。トロイソースシミュレーション（公開ミッション）、そしてトロイソースリサーチをお読みください。
11月初旬、ケンブリッジ大学は「 トロイの木馬-ソース」と題する 研究を発表しました。この 研究は、方向性書式指定文字を用いてソースコードやコメントにバックドアを隠蔽する手法に焦点を当てています。これにより、コンパイラが人間のコードレビュー担当者と異なる方法でロジックを解釈するコードを生成することが可能となります。
以前、Unicodeがファイルの実際の拡張子を隠すなど悪用された事例はあったものの、この脆弱性は新たに発生したものです。ファイル名の末尾部分の方向転換。最近の研究によれば、多くのコンパイラは警告なしにソースコード内のユニコード文字を無視する一方、コードエディタを含むテキストエディタはこれに基づいてコメントとコードを含む行を再配置（リフロー）することが可能です。したがってエディタは、コンパイラが解析する方法とは異なる順序でコードとコメントを表示することができ、コードとコメントを交換する場合でも同様です。
詳細を知りたい場合は読み進めてください。またはトロイの木馬ソースのハッキングシミュレーションを試してみたい場合は、無料で提供されているサービスにすぐにアクセスしてみてください。公共任務を直接体験してください。
双方向テキスト
これらのトロイの木馬攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用します。このアルゴリズムは、英語（左から右）やアラビア語（右から左）のように表示順序が異なるテキストの整列方法を処理します。方向書式指定文字を使用してグループを再構成し、文字の順序を表示することができます。
上記の表には攻撃に関連する一部のBidiオーバーライド文字が含まれています。例えば、
RLIe d o cPD
略語RLIは以下を表します。右から左への分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップディレクショナルアイソレート）をクリックし、右から左へ読みます。結果は次の通りです。
C O D E
しかしコンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含む書式制御文字を処理しません。方向性書式指定文字を単に無視すると、次のように解析されます。
E D O C
新しい瓶に入った古いワイン？
もちろんこれは太陽の下で新しいことではありません。過去には方向指定文字が使用されていました。ファイル名に挿入され、その悪意のある性質を隠すためです。「myspecialexe.doc」と表示されたメール添付ファイルは、RLO（右から左へのオーバーライド）がなければ十分に無邪気に見えたかもしれません。実際の名前が「myspecialcod.exe」であることを示す文字の贈り物でした。
トロイの木馬ソース攻撃は、ソースコード内のコメントや文字列に方向指定文字を挿入します。これらの制御文字は、構文エラーやコンパイルエラーを引き起こさないためです。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るようにします。
例えば、次のバイトを順に含むファイル:
方向指定文字ごとに以下のように再配置されます。
方向指定文字が明示的に呼び出されていない場合、コードは次のようにレンダリングされます。
RLOは最後の行で閉じる中括弧を開く中括弧に反転し、その逆も同様です。このコードを実行すると、次のような結果が出力されます。「あなたは管理者です。」管理者チェックはコメントアウトされていますが、制御文字を見ると、そのチェックが依然として存在していたという印象を与えます。
(出典: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これは皆様にどのような影響を与える可能性があるでしょうか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど多くの言語が攻撃に対して脆弱であり、 さらに多くの言語が攻撃に脆弱であると推定されます。一般の開発者はソースコード内の方向指定文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えない方が良いかもしれません。さらに、これらの文字の可視化はIDEによって大きく異なるため、発見される保証はありません。
しかし、そもそもこの脆弱性はどのようにソースコードに潜入できたのでしょうか？何よりもまず、信頼できないソースからのソースコードを使用する際、悪意のあるコードの混入が気づかれないまま発生する可能性があります。第二に、インターネットで見つけたコードをコピー＆ペーストするだけで、このような事態が起こり得ます。 私たちの開発者のほとんどが過去に経験したことでしょう。ほとんどの組織は複数のベンダーのソフトウェアコンポーネントに依存しています。これにより、このコードをどの程度信頼し、依存できるかという疑問が生じます。隠されたバックドアを含むソースコードをどのように選別できるでしょうか？
誰の問題でしょうか？
一方、コンパイラとビルドパイプラインは、一方向が文字列やコメントで厳密に制限されていない限り、複数の方向を持つソースコード行を許可すべきではありません。なお、文字列やコメントの方向指定文字は、ポップされない場合、行末まで方向変更を延長できます。一般的にコードエディタは、ホモグリフや方向指定文字など疑わしいユニコード文字を明示的にレンダリングし強調表示すべきです。11月からGitHubは、双方向ユニコードテキストを含む全てのコード行に警告記号とメッセージを追加します。 ただし、これらの文字の行位置は強調表示されません。これにより、悪意のある方向変更が依然として潜入する可能性があります。
開発者とコードレビュアー間の認識は不可欠であるため、脆弱性を説明するガイダンスを作成しました。現在この練習はJava、C#、Python、GO、PHPで利用可能です。
より詳しく知りたい場合は、当社の製品をお試しください。トロイソースシミュレーション（公開ミッション）、そしてトロイソースリサーチをお読みください。
以下のリンクをクリックし、このリソースのPDFをダウンロードしてください。
セキュアコードウォリアーは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を組織に根付かせるために存在します。AppSec管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、組織が安全でないコードに関連するリスクを軽減できるよう支援します。
レポートを見るデモ予約
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は「 トロイの木馬-ソース」と題する 研究を発表しました。この 研究は、方向性書式指定文字を用いてソースコードやコメントにバックドアを隠蔽する手法に焦点を当てています。これにより、コンパイラが人間のコードレビュー担当者と異なる方法でロジックを解釈するコードを生成することが可能となります。
以前、Unicodeがファイルの実際の拡張子を隠すなど悪用された事例はあったものの、この脆弱性は新たに発生したものです。ファイル名の末尾部分の方向転換。最近の研究によれば、多くのコンパイラは警告なしにソースコード内のユニコード文字を無視する一方、コードエディタを含むテキストエディタはこれに基づいてコメントとコードを含む行を再配置（リフロー）することが可能です。したがってエディタは、コンパイラが解析する方法とは異なる順序でコードとコメントを表示することができ、コードとコメントを交換する場合でも同様です。
詳細を知りたい場合は読み進めてください。またはトロイの木馬ソースのハッキングシミュレーションを試してみたい場合は、無料で提供されているサービスにすぐにアクセスしてみてください。公共任務を直接体験してください。
双方向テキスト
これらのトロイの木馬攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用します。このアルゴリズムは、英語（左から右）やアラビア語（右から左）のように表示順序が異なるテキストの整列方法を処理します。方向書式指定文字を使用してグループを再構成し、文字の順序を表示することができます。
上記の表には攻撃に関連する一部のBidiオーバーライド文字が含まれています。例えば、
RLIe d o cPD
略語RLIは以下を表します。右から左への分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップディレクショナルアイソレート）をクリックし、右から左へ読みます。結果は次の通りです。
C O D E
しかしコンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含む書式制御文字を処理しません。方向性書式指定文字を単に無視すると、次のように解析されます。
E D O C
新しい瓶に入った古いワイン？
もちろんこれは太陽の下で新しいことではありません。過去には方向指定文字が使用されていました。ファイル名に挿入され、その悪意のある性質を隠すためです。「myspecialexe.doc」と表示されたメール添付ファイルは、RLO（右から左へのオーバーライド）がなければ十分に無邪気に見えたかもしれません。実際の名前が「myspecialcod.exe」であることを示す文字の贈り物でした。
トロイの木馬ソース攻撃は、ソースコード内のコメントや文字列に方向指定文字を挿入します。これらの制御文字は、構文エラーやコンパイルエラーを引き起こさないためです。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るようにします。
例えば、次のバイトを順に含むファイル:
方向指定文字ごとに以下のように再配置されます。
方向指定文字が明示的に呼び出されていない場合、コードは次のようにレンダリングされます。
RLOは最後の行で閉じる中括弧を開く中括弧に反転し、その逆も同様です。このコードを実行すると、次のような結果が出力されます。「あなたは管理者です。」管理者チェックはコメントアウトされていますが、制御文字を見ると、そのチェックが依然として存在していたという印象を与えます。
(出典: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これは皆様にどのような影響を与える可能性があるでしょうか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど多くの言語が攻撃に対して脆弱であり、 さらに多くの言語が攻撃に脆弱であると推定されます。一般の開発者はソースコード内の方向指定文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えない方が良いかもしれません。さらに、これらの文字の可視化はIDEによって大きく異なるため、発見される保証はありません。
しかし、そもそもこの脆弱性はどのようにソースコードに潜入できたのでしょうか？何よりもまず、信頼できないソースからのソースコードを使用する際、悪意のあるコードの混入が気づかれないまま発生する可能性があります。第二に、インターネットで見つけたコードをコピー＆ペーストするだけで、このような事態が起こり得ます。 私たちの開発者のほとんどが過去に経験したことでしょう。ほとんどの組織は複数のベンダーのソフトウェアコンポーネントに依存しています。これにより、このコードをどの程度信頼し、依存できるかという疑問が生じます。隠されたバックドアを含むソースコードをどのように選別できるでしょうか？
誰の問題でしょうか？
一方、コンパイラとビルドパイプラインは、一方向が文字列やコメントで厳密に制限されていない限り、複数の方向を持つソースコード行を許可すべきではありません。なお、文字列やコメントの方向指定文字は、ポップされない場合、行末まで方向変更を延長できます。一般的にコードエディタは、ホモグリフや方向指定文字など疑わしいユニコード文字を明示的にレンダリングし強調表示すべきです。11月からGitHubは、双方向ユニコードテキストを含む全てのコード行に警告記号とメッセージを追加します。 ただし、これらの文字の行位置は強調表示されません。これにより、悪意のある方向変更が依然として潜入する可能性があります。
開発者とコードレビュアー間の認識は不可欠であるため、脆弱性を説明するガイダンスを作成しました。現在この練習はJava、C#、Python、GO、PHPで利用可能です。
より詳しく知りたい場合は、当社の製品をお試しください。トロイソースシミュレーション（公開ミッション）、そしてトロイソースリサーチをお読みください。
始めるのに役立つリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
