トロイの木馬ソースとは何か、そしてそれがどのようにソースコードに潜入するのか
11月初旬、ケンブリッジ大学は「 Trojan-Source」と題する研究を発表した。この研究の焦点は、指向性フォーマット文字を用いてバックドアをソースコードやコメント内に隠蔽する方法にある。これらはコード記述に利用可能であり、コンパイラによる論理解釈が人間のコード審査員による解釈と異なる点を利用する。
この脆弱性は新たに発見されたものです。過去には、ファイルの実際の拡張子を隠すために、ファイル名の末尾部分を反転させるなど、Unicodeを悪用する事例がありました。最近の研究によると、多くのコンパイラはソースコード内のUnicode文字を警告なしに無視し、コードエディタを含むテキストエディタは、これらの文字を含むコメントやコード行を再配置する可能性があります。したがって、エディタがコードやコメントを表示する方法は、コンパイラがそれらを解析する方法と異なる可能性があり、場合によってはコードとコメントが入れ替わることもあります。
詳細については、引き続きお読みください。あるいは、Trojan Source の模擬ハッキングを実際に試してみたい場合は、無料版の「公共ミッション」で体験してみてください。
双方向テキスト
ある種のトロイの木馬型ソース攻撃は、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、表示順序が異なるテキスト（例：英語（左から右）とアラビア語（右から左））をどのように組み合わせるかを処理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidi置換文字が含まれています。例えば、
RLIE D O CP D I
RLIは右から左への分離を表します。これはテキストをその文脈（PDI、つまり流行方向分離によって区切られたもの）から分離し、右から左へ読み取ります。その結果：
C O D E
しかし、コンパイラやインタプリタは通常、Bidiオーバーライドを含む書式制御文字をソースコードの解析前に処理しません。もし方向書式化文字を単に無視する場合、次のように解析します：
E D O C
新瓶に古い酒？
もちろん、これは目新しいことではない。かつては、方向性フォーマット文字がファイル名に挿入され、その悪意ある本質を隠蔽していた。RLOでなければ、「myspecialexe.doc」と表示される電子メールの添付ファイルは十分に無害に見えるかもしれない（右から左へのスーパーコントロール文字）が、表示される文字列は真の名である「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に大きく依存しているため、確実に検出されるとは限らない。
しかし、この脆弱性は当初、どのようにソースコードに潜入したのだろうか？まず、信頼できないソースからのソースコードを使用する場合、悪意のあるコードの貢献が気づかれずに済む可能性がある。次に、これは単にインターネットで見つけたコードをコピー＆ペーストするだけで実現可能であり、これは多くの開発者が過去に経験したことでしょう。ほとんどの組織は複数のベンダーからのソフトウェアコンポーネントに依存しています。これは、私たちがこのコードをどこまで完全に信頼し依存できるのかという疑問を投げかけます。隠されたバックドアを含むソースコードを、私たちはどのように選別すればよいのでしょうか？
これは誰の問題ですか？
一方、コンパイラとコンパイルパイプラインは、複数方向のソースコード行の使用を禁止すべきである。ただし、一方向が文字列とコメントのみに厳密に制限される場合は例外とする。文字列やコメント内の方向フォーマット文字がポップアップしない場合、方向変化を行末まで延長できることに留意されたい。通常、コードエディタは疑わしいUnicode文字（同形異義文字や方向指定フォーマット文字など）を明確に表示し強調すべきです。11月以降、GitHubは双方向Unicodeテキストを含む各行に警告フラグとメッセージを追加していますが、これらの文字の行内位置を強調表示しません。これにより、悪意のある方向変更や良性の変化が潜入する可能性が残されています。
開発者とコードレビュー担当者の意識が極めて重要です。そのため、脆弱性を説明する演習を作成しました。現在、この演習はJava、C#、Python、GO、PHPで利用可能です。
したがって、さらに詳しく知りたい場合は、当社のトロイの木馬ソースのシミュレーション（公開タスク）をお試しいただき、その後「トロイの木馬ソース研究」をお読みください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を醸成するお手伝いをします。AppSecマネージャー、開発者、最高情報セキュリティ責任者（CISO）、あるいはセキュリティに関わるあらゆる方々の組織において、不安全なコードに関連するリスクの低減を支援します。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は「 Trojan-Source」と題する研究を発表した。この研究の焦点は、指向性フォーマット文字を用いてバックドアをソースコードやコメント内に隠蔽する方法にある。これらはコード記述に利用可能であり、コンパイラによる論理解釈が人間のコード審査員による解釈と異なる点を利用する。
この脆弱性は新たに発見されたものです。過去には、ファイルの実際の拡張子を隠すために、ファイル名の末尾部分を反転させるなど、Unicodeを悪用する事例がありました。最近の研究によると、多くのコンパイラはソースコード内のUnicode文字を警告なしに無視し、コードエディタを含むテキストエディタは、これらの文字を含むコメントやコード行を再配置する可能性があります。したがって、エディタがコードやコメントを表示する方法は、コンパイラがそれらを解析する方法と異なる可能性があり、場合によってはコードとコメントが入れ替わることもあります。
詳細については、引き続きお読みください。あるいは、Trojan Source の模擬ハッキングを実際に試してみたい場合は、無料版の「公共ミッション」で体験してみてください。
双方向テキスト
ある種のトロイの木馬型ソース攻撃は、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、表示順序が異なるテキスト（例：英語（左から右）とアラビア語（右から左））をどのように組み合わせるかを処理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidi置換文字が含まれています。例えば、
RLIE D O CP D I
RLIは右から左への分離を表します。これはテキストをその文脈（PDI、つまり流行方向分離によって区切られたもの）から分離し、右から左へ読み取ります。その結果：
C O D E
しかし、コンパイラやインタプリタは通常、Bidiオーバーライドを含む書式制御文字をソースコードの解析前に処理しません。もし方向書式化文字を単に無視する場合、次のように解析します：
E D O C
新瓶に古い酒？
もちろん、これは目新しいことではない。かつては、方向性フォーマット文字がファイル名に挿入され、その悪意ある本質を隠蔽していた。RLOでなければ、「myspecialexe.doc」と表示される電子メールの添付ファイルは十分に無害に見えるかもしれない（右から左へのスーパーコントロール文字）が、表示される文字列は真の名である「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に大きく依存しているため、確実に検出されるとは限らない。
しかし、この脆弱性は当初、どのようにソースコードに潜入したのだろうか？まず、信頼できないソースからのソースコードを使用する場合、悪意のあるコードの貢献が気づかれずに済む可能性がある。次に、これは単にインターネットで見つけたコードをコピー＆ペーストするだけで実現可能であり、これは多くの開発者が過去に経験したことでしょう。ほとんどの組織は複数のベンダーからのソフトウェアコンポーネントに依存しています。これは、私たちがこのコードをどこまで完全に信頼し依存できるのかという疑問を投げかけます。隠されたバックドアを含むソースコードを、私たちはどのように選別すればよいのでしょうか？
これは誰の問題ですか？
一方、コンパイラとコンパイルパイプラインは、複数方向のソースコード行の使用を禁止すべきである。ただし、一方向が文字列とコメントのみに厳密に制限される場合は例外とする。文字列やコメント内の方向フォーマット文字がポップアップしない場合、方向変化を行末まで延長できることに留意されたい。通常、コードエディタは疑わしいUnicode文字（同形異義文字や方向指定フォーマット文字など）を明確に表示し強調すべきです。11月以降、GitHubは双方向Unicodeテキストを含む各行に警告フラグとメッセージを追加していますが、これらの文字の行内位置を強調表示しません。これにより、悪意のある方向変更や良性の変化が潜入する可能性が残されています。
開発者とコードレビュー担当者の意識が極めて重要です。そのため、脆弱性を説明する演習を作成しました。現在、この演習はJava、C#、Python、GO、PHPで利用可能です。
したがって、さらに詳しく知りたい場合は、当社のトロイの木馬ソースのシミュレーション（公開タスク）をお試しいただき、その後「トロイの木馬ソース研究」をお読みください。
11月初旬、ケンブリッジ大学は「 Trojan-Source」と題する研究を発表した。この研究の焦点は、指向性フォーマット文字を用いてバックドアをソースコードやコメント内に隠蔽する方法にある。これらはコード記述に利用可能であり、コンパイラによる論理解釈が人間のコード審査員による解釈と異なる点を利用する。
この脆弱性は新たに発見されたものです。過去には、ファイルの実際の拡張子を隠すために、ファイル名の末尾部分を反転させるなど、Unicodeを悪用する事例がありました。最近の研究によると、多くのコンパイラはソースコード内のUnicode文字を警告なしに無視し、コードエディタを含むテキストエディタは、これらの文字を含むコメントやコード行を再配置する可能性があります。したがって、エディタがコードやコメントを表示する方法は、コンパイラがそれらを解析する方法と異なる可能性があり、場合によってはコードとコメントが入れ替わることもあります。
詳細については、引き続きお読みください。あるいは、Trojan Source の模擬ハッキングを実際に試してみたい場合は、無料版の「公共ミッション」で体験してみてください。
双方向テキスト
ある種のトロイの木馬型ソース攻撃は、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、表示順序が異なるテキスト（例：英語（左から右）とアラビア語（右から左））をどのように組み合わせるかを処理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidi置換文字が含まれています。例えば、
RLIE D O CP D I
RLIは右から左への分離を表します。これはテキストをその文脈（PDI、つまり流行方向分離によって区切られたもの）から分離し、右から左へ読み取ります。その結果：
C O D E
しかし、コンパイラやインタプリタは通常、Bidiオーバーライドを含む書式制御文字をソースコードの解析前に処理しません。もし方向書式化文字を単に無視する場合、次のように解析します：
E D O C
新瓶に古い酒？
もちろん、これは目新しいことではない。かつては、方向性フォーマット文字がファイル名に挿入され、その悪意ある本質を隠蔽していた。RLOでなければ、「myspecialexe.doc」と表示される電子メールの添付ファイルは十分に無害に見えるかもしれない（右から左へのスーパーコントロール文字）が、表示される文字列は真の名である「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に大きく依存しているため、確実に検出されるとは限らない。
しかし、この脆弱性は当初、どのようにソースコードに潜入したのだろうか？まず、信頼できないソースからのソースコードを使用する場合、悪意のあるコードの貢献が気づかれずに済む可能性がある。次に、これは単にインターネットで見つけたコードをコピー＆ペーストするだけで実現可能であり、これは多くの開発者が過去に経験したことでしょう。ほとんどの組織は複数のベンダーからのソフトウェアコンポーネントに依存しています。これは、私たちがこのコードをどこまで完全に信頼し依存できるのかという疑問を投げかけます。隠されたバックドアを含むソースコードを、私たちはどのように選別すればよいのでしょうか？
これは誰の問題ですか？
一方、コンパイラとコンパイルパイプラインは、複数方向のソースコード行の使用を禁止すべきである。ただし、一方向が文字列とコメントのみに厳密に制限される場合は例外とする。文字列やコメント内の方向フォーマット文字がポップアップしない場合、方向変化を行末まで延長できることに留意されたい。通常、コードエディタは疑わしいUnicode文字（同形異義文字や方向指定フォーマット文字など）を明確に表示し強調すべきです。11月以降、GitHubは双方向Unicodeテキストを含む各行に警告フラグとメッセージを追加していますが、これらの文字の行内位置を強調表示しません。これにより、悪意のある方向変更や良性の変化が潜入する可能性が残されています。
開発者とコードレビュー担当者の意識が極めて重要です。そのため、脆弱性を説明する演習を作成しました。現在、この演習はJava、C#、Python、GO、PHPで利用可能です。
したがって、さらに詳しく知りたい場合は、当社のトロイの木馬ソースのシミュレーション（公開タスク）をお試しいただき、その後「トロイの木馬ソース研究」をお読みください。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を醸成するお手伝いをします。AppSecマネージャー、開発者、最高情報セキュリティ責任者（CISO）、あるいはセキュリティに関わるあらゆる方々の組織において、不安全なコードに関連するリスクの低減を支援します。
レポートを確認するデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は「 Trojan-Source」と題する研究を発表した。この研究の焦点は、指向性フォーマット文字を用いてバックドアをソースコードやコメント内に隠蔽する方法にある。これらはコード記述に利用可能であり、コンパイラによる論理解釈が人間のコード審査員による解釈と異なる点を利用する。
この脆弱性は新たに発見されたものです。過去には、ファイルの実際の拡張子を隠すために、ファイル名の末尾部分を反転させるなど、Unicodeを悪用する事例がありました。最近の研究によると、多くのコンパイラはソースコード内のUnicode文字を警告なしに無視し、コードエディタを含むテキストエディタは、これらの文字を含むコメントやコード行を再配置する可能性があります。したがって、エディタがコードやコメントを表示する方法は、コンパイラがそれらを解析する方法と異なる可能性があり、場合によってはコードとコメントが入れ替わることもあります。
詳細については、引き続きお読みください。あるいは、Trojan Source の模擬ハッキングを実際に試してみたい場合は、無料版の「公共ミッション」で体験してみてください。
双方向テキスト
ある種のトロイの木馬型ソース攻撃は、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、表示順序が異なるテキスト（例：英語（左から右）とアラビア語（右から左））をどのように組み合わせるかを処理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidi置換文字が含まれています。例えば、
RLIE D O CP D I
RLIは右から左への分離を表します。これはテキストをその文脈（PDI、つまり流行方向分離によって区切られたもの）から分離し、右から左へ読み取ります。その結果：
C O D E
しかし、コンパイラやインタプリタは通常、Bidiオーバーライドを含む書式制御文字をソースコードの解析前に処理しません。もし方向書式化文字を単に無視する場合、次のように解析します：
E D O C
新瓶に古い酒？
もちろん、これは目新しいことではない。かつては、方向性フォーマット文字がファイル名に挿入され、その悪意ある本質を隠蔽していた。RLOでなければ、「myspecialexe.doc」と表示される電子メールの添付ファイルは十分に無害に見えるかもしれない（右から左へのスーパーコントロール文字）が、表示される文字列は真の名である「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に大きく依存しているため、確実に検出されるとは限らない。
しかし、この脆弱性は当初、どのようにソースコードに潜入したのだろうか？まず、信頼できないソースからのソースコードを使用する場合、悪意のあるコードの貢献が気づかれずに済む可能性がある。次に、これは単にインターネットで見つけたコードをコピー＆ペーストするだけで実現可能であり、これは多くの開発者が過去に経験したことでしょう。ほとんどの組織は複数のベンダーからのソフトウェアコンポーネントに依存しています。これは、私たちがこのコードをどこまで完全に信頼し依存できるのかという疑問を投げかけます。隠されたバックドアを含むソースコードを、私たちはどのように選別すればよいのでしょうか？
これは誰の問題ですか？
一方、コンパイラとコンパイルパイプラインは、複数方向のソースコード行の使用を禁止すべきである。ただし、一方向が文字列とコメントのみに厳密に制限される場合は例外とする。文字列やコメント内の方向フォーマット文字がポップアップしない場合、方向変化を行末まで延長できることに留意されたい。通常、コードエディタは疑わしいUnicode文字（同形異義文字や方向指定フォーマット文字など）を明確に表示し強調すべきです。11月以降、GitHubは双方向Unicodeテキストを含む各行に警告フラグとメッセージを追加していますが、これらの文字の行内位置を強調表示しません。これにより、悪意のある方向変更や良性の変化が潜入する可能性が残されています。
開発者とコードレビュー担当者の意識が極めて重要です。そのため、脆弱性を説明する演習を作成しました。現在、この演習は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)
