トロイの木馬ソースとは何か、そしてそれはどのようにあなたのソースコードに潜り込むのか？
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と題する研究を発表した。この研究は、ソースコードやコメント内の指向性フォーマット記号を用いてバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを生成することが可能となる。
このセキュリティ上の脆弱性は新たなものです——過去にUnicodeが悪用された事例は存在します。例えば、ファイル名の末尾部分の方向を反転させることで、ファイルの真の拡張子を隠蔽するといった手法です。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方、テキストエディタ（コードエディタを含む）はコメント行やそれに基づくコードを再配置できることが判明しました。 そのため、エディタがコードとコメントを表示する順序がコンパイラが解析する順序と異なる場合があり、コードとコメントが入れ替わる事態さえ起こり得る。
さらに詳しく知りたい方は読み進めてください。あるいは、実際に腕まくりをしてトロイアンソースのハッキングシミュレーションを試してみたい方は、無料公開ミッションにアクセスしてご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、Unicode双方向アルゴリズム（bidirectional）を利用しています。このアルゴリズムは、英語（左から右）とアラビア語（右から左）のように表示順序が異なるテキストの組み立てを処理します。方向指定フォーマット文字を使用することで、グループ化を再編成し、文字の表示順序を変更することが可能です。
上記の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば
RLIE D O CP D I
RLIは「右から左へ分離」を意味する略語です。これはテキストを文脈から分離し（PDIで区切られ）、方向性分離を行い、右から左へ読み上げます。その結果は以下の通りです：
C O D E
コンパイラとインタプリタは通常、ソースコードの解析前に書式制御文字（双方向オーバーライドを含む）を処理しません。方向性書式制御文字を単に無視する場合、解析対象となるのは：
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に大きく依存するため、認識が保証されることは決してありません。
しかし、このセキュリティホールはいったいどうやってソースコードに潜り込んだのか？第一に、信頼できないソースからのコードを使用した場合に発生し得る。悪意のあるコードの寄稿が気づかれずに残っていた場合だ。第二に、インターネットからコードを単純にコピー＆ペーストすることで起こり得る。これは開発者のほとんどが一度は経験したことだろう。 多くの企業は複数のベンダーのソフトウェアコンポーネントに依存している。これは、私たちがこのコードをどこまで完全に信頼し、依存できるかという疑問を投げかける。隠されたバックドアを含むソースコードをどのように探せばよいのだろうか？
それは誰の問題ですか？
一方で、コンパイラやビルドパイプラインは、方向性が文字列やコメントに厳密に限定されていない限り、複数の方向性を持つソースコード行を禁止すべきです。方向性フォーマット記号が文字列やコメント内で表示されない場合、行末まで方向変更が延長される可能性があることに注意してください。 一般的に、コードエディタは同形異義語や方向性フォーマット記号などの疑わしいUnicode文字を明示的にレンダリングし、強調表示すべきである。 11月以降、GitHubは双方向Unicodeテキストを含む各コード行に警告記号とメッセージを追加していますが、行内の該当文字位置は強調表示されません。これにより、悪意のある方向変更が無害な変更に紛れ込む可能性が残ります。
開発者とコードレビュー担当者は、この問題に対する認識を必ず高める必要があります。このため、脆弱性を実証する包括的なソリューションを作成しました。現在、このソリューションはJava、C#、Python、GO、PHP向けに提供されています。
もっと知りたいなら、トロイアン・ソースのシミュレーション（公開ミッション）を試してみて、トロイアン・ソース研究を読んでみてください。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
デモを予約する
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und konzentriert sich auf die Erforschung von Sicherheitslücken und die Erstellung von Inhalten für Missions und Coding Labs.
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と題する研究を発表した。この研究は、ソースコードやコメント内の指向性フォーマット記号を用いてバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを生成することが可能となる。
このセキュリティ上の脆弱性は新たなものです——過去にUnicodeが悪用された事例は存在します。例えば、ファイル名の末尾部分の方向を反転させることで、ファイルの真の拡張子を隠蔽するといった手法です。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方、テキストエディタ（コードエディタを含む）はコメント行やそれに基づくコードを再配置できることが判明しました。 そのため、エディタがコードとコメントを表示する順序がコンパイラが解析する順序と異なる場合があり、コードとコメントが入れ替わる事態さえ起こり得る。
さらに詳しく知りたい方は読み進めてください。あるいは、実際に腕まくりをしてトロイアンソースのハッキングシミュレーションを試してみたい方は、無料公開ミッションにアクセスしてご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、Unicode双方向アルゴリズム（bidirectional）を利用しています。このアルゴリズムは、英語（左から右）とアラビア語（右から左）のように表示順序が異なるテキストの組み立てを処理します。方向指定フォーマット文字を使用することで、グループ化を再編成し、文字の表示順序を変更することが可能です。
上記の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば
RLIE D O CP D I
RLIは「右から左へ分離」を意味する略語です。これはテキストを文脈から分離し（PDIで区切られ）、方向性分離を行い、右から左へ読み上げます。その結果は以下の通りです：
C O D E
コンパイラとインタプリタは通常、ソースコードの解析前に書式制御文字（双方向オーバーライドを含む）を処理しません。方向性書式制御文字を単に無視する場合、解析対象となるのは：
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に大きく依存するため、認識が保証されることは決してありません。
しかし、このセキュリティホールはいったいどうやってソースコードに潜り込んだのか？第一に、信頼できないソースからのコードを使用した場合に発生し得る。悪意のあるコードの寄稿が気づかれずに残っていた場合だ。第二に、インターネットからコードを単純にコピー＆ペーストすることで起こり得る。これは開発者のほとんどが一度は経験したことだろう。 多くの企業は複数のベンダーのソフトウェアコンポーネントに依存している。これは、私たちがこのコードをどこまで完全に信頼し、依存できるかという疑問を投げかける。隠されたバックドアを含むソースコードをどのように探せばよいのだろうか？
それは誰の問題ですか？
一方で、コンパイラやビルドパイプラインは、方向性が文字列やコメントに厳密に限定されていない限り、複数の方向性を持つソースコード行を禁止すべきです。方向性フォーマット記号が文字列やコメント内で表示されない場合、行末まで方向変更が延長される可能性があることに注意してください。 一般的に、コードエディタは同形異義語や方向性フォーマット記号などの疑わしいUnicode文字を明示的にレンダリングし、強調表示すべきである。 11月以降、GitHubは双方向Unicodeテキストを含む各コード行に警告記号とメッセージを追加していますが、行内の該当文字位置は強調表示されません。これにより、悪意のある方向変更が無害な変更に紛れ込む可能性が残ります。
開発者とコードレビュー担当者は、この問題に対する認識を必ず高める必要があります。このため、脆弱性を実証する包括的なソリューションを作成しました。現在、このソリューションはJava、C#、Python、GO、PHP向けに提供されています。
もっと知りたいなら、トロイアン・ソースのシミュレーション（公開ミッション）を試してみて、トロイアン・ソース研究を読んでみてください。
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と題する研究を発表した。この研究は、ソースコードやコメント内の指向性フォーマット記号を用いてバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを生成することが可能となる。
このセキュリティ上の脆弱性は新たなものです——過去にUnicodeが悪用された事例は存在します。例えば、ファイル名の末尾部分の方向を反転させることで、ファイルの真の拡張子を隠蔽するといった手法です。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方、テキストエディタ（コードエディタを含む）はコメント行やそれに基づくコードを再配置できることが判明しました。 そのため、エディタがコードとコメントを表示する順序がコンパイラが解析する順序と異なる場合があり、コードとコメントが入れ替わる事態さえ起こり得る。
さらに詳しく知りたい方は読み進めてください。あるいは、実際に腕まくりをしてトロイアンソースのハッキングシミュレーションを試してみたい方は、無料公開ミッションにアクセスしてご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、Unicode双方向アルゴリズム（bidirectional）を利用しています。このアルゴリズムは、英語（左から右）とアラビア語（右から左）のように表示順序が異なるテキストの組み立てを処理します。方向指定フォーマット文字を使用することで、グループ化を再編成し、文字の表示順序を変更することが可能です。
上記の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば
RLIE D O CP D I
RLIは「右から左へ分離」を意味する略語です。これはテキストを文脈から分離し（PDIで区切られ）、方向性分離を行い、右から左へ読み上げます。その結果は以下の通りです：
C O D E
コンパイラとインタプリタは通常、ソースコードの解析前に書式制御文字（双方向オーバーライドを含む）を処理しません。方向性書式制御文字を単に無視する場合、解析対象となるのは：
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に大きく依存するため、認識が保証されることは決してありません。
しかし、このセキュリティホールはいったいどうやってソースコードに潜り込んだのか？第一に、信頼できないソースからのコードを使用した場合に発生し得る。悪意のあるコードの寄稿が気づかれずに残っていた場合だ。第二に、インターネットからコードを単純にコピー＆ペーストすることで起こり得る。これは開発者のほとんどが一度は経験したことだろう。 多くの企業は複数のベンダーのソフトウェアコンポーネントに依存している。これは、私たちがこのコードをどこまで完全に信頼し、依存できるかという疑問を投げかける。隠されたバックドアを含むソースコードをどのように探せばよいのだろうか？
それは誰の問題ですか？
一方で、コンパイラやビルドパイプラインは、方向性が文字列やコメントに厳密に限定されていない限り、複数の方向性を持つソースコード行を禁止すべきです。方向性フォーマット記号が文字列やコメント内で表示されない場合、行末まで方向変更が延長される可能性があることに注意してください。 一般的に、コードエディタは同形異義語や方向性フォーマット記号などの疑わしいUnicode文字を明示的にレンダリングし、強調表示すべきである。 11月以降、GitHubは双方向Unicodeテキストを含む各コード行に警告記号とメッセージを追加していますが、行内の該当文字位置は強調表示されません。これにより、悪意のある方向変更が無害な変更に紛れ込む可能性が残ります。
開発者とコードレビュー担当者は、この問題に対する認識を必ず高める必要があります。このため、脆弱性を実証する包括的なソリューションを作成しました。現在、このソリューションはJava、C#、Python、GO、PHP向けに提供されています。
もっと知りたいなら、トロイアン・ソースのシミュレーション（公開ミッション）を試してみて、トロイアン・ソース研究を読んでみてください。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
レポートを見るデモを予約する
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und konzentriert sich auf die Erforschung von Sicherheitslücken und die Erstellung von Inhalten für Missions und Coding Labs.
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と題する研究を発表した。この研究は、ソースコードやコメント内の指向性フォーマット記号を用いてバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを生成することが可能となる。
このセキュリティ上の脆弱性は新たなものです——過去にUnicodeが悪用された事例は存在します。例えば、ファイル名の末尾部分の方向を反転させることで、ファイルの真の拡張子を隠蔽するといった手法です。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方、テキストエディタ（コードエディタを含む）はコメント行やそれに基づくコードを再配置できることが判明しました。 そのため、エディタがコードとコメントを表示する順序がコンパイラが解析する順序と異なる場合があり、コードとコメントが入れ替わる事態さえ起こり得る。
さらに詳しく知りたい方は読み進めてください。あるいは、実際に腕まくりをしてトロイアンソースのハッキングシミュレーションを試してみたい方は、無料公開ミッションにアクセスしてご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、Unicode双方向アルゴリズム（bidirectional）を利用しています。このアルゴリズムは、英語（左から右）とアラビア語（右から左）のように表示順序が異なるテキストの組み立てを処理します。方向指定フォーマット文字を使用することで、グループ化を再編成し、文字の表示順序を変更することが可能です。
上記の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば
RLIE D O CP D I
RLIは「右から左へ分離」を意味する略語です。これはテキストを文脈から分離し（PDIで区切られ）、方向性分離を行い、右から左へ読み上げます。その結果は以下の通りです：
C O D E
コンパイラとインタプリタは通常、ソースコードの解析前に書式制御文字（双方向オーバーライドを含む）を処理しません。方向性書式制御文字を単に無視する場合、解析対象となるのは：
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に大きく依存するため、認識が保証されることは決してありません。
しかし、このセキュリティホールはいったいどうやってソースコードに潜り込んだのか？第一に、信頼できないソースからのコードを使用した場合に発生し得る。悪意のあるコードの寄稿が気づかれずに残っていた場合だ。第二に、インターネットからコードを単純にコピー＆ペーストすることで起こり得る。これは開発者のほとんどが一度は経験したことだろう。 多くの企業は複数のベンダーのソフトウェアコンポーネントに依存している。これは、私たちがこのコードをどこまで完全に信頼し、依存できるかという疑問を投げかける。隠されたバックドアを含むソースコードをどのように探せばよいのだろうか？
それは誰の問題ですか？
一方で、コンパイラやビルドパイプラインは、方向性が文字列やコメントに厳密に限定されていない限り、複数の方向性を持つソースコード行を禁止すべきです。方向性フォーマット記号が文字列やコメント内で表示されない場合、行末まで方向変更が延長される可能性があることに注意してください。 一般的に、コードエディタは同形異義語や方向性フォーマット記号などの疑わしい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)
