トロイの木馬ソースとは何か、そしてどのようにソースコードに侵入するのか
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と呼ばれる研究を発表しました。この研究は、方向性のあるフォーマット文字を用いてソースコードやコメントにバックドアを隠す手法に焦点を当てています。これらを利用することで、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成することが可能になります。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。例えば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。ファイル名の末尾部分の方向を反転させる。最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方で、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行を再配置する可能性があることが明らかになりました。そのため、エディタはコードやコメントを、コンパイラが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。パブリックミッションご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI私たちはcに行きますPDI
RLIの略語は右から左に分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップ・ディレクショナル・アイソレート）、右から左に読み上げます。結果は以下のようになります。
C O D E
ただし、コンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちは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が使用されていました。ファイル名の末尾部分の方向を反転させる。最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方で、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行を再配置する可能性があることが明らかになりました。そのため、エディタはコードやコメントを、コンパイラが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。パブリックミッションご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI私たちはcに行きますPDI
RLIの略語は右から左に分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップ・ディレクショナル・アイソレート）、右から左に読み上げます。結果は以下のようになります。
C O D E
ただし、コンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちは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が使用されていました。ファイル名の末尾部分の方向を反転させる。最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方で、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行を再配置する可能性があることが明らかになりました。そのため、エディタはコードやコメントを、コンパイラが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。パブリックミッションご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI私たちはcに行きますPDI
RLIの略語は右から左に分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップ・ディレクショナル・アイソレート）、右から左に読み上げます。結果は以下のようになります。
C O D E
ただし、コンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちは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は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
ローラ・ヴェルハイデは、Secure Code Warriorのソフトウェア開発者であり、ミッションラボとコーディングラボ向けの脆弱性調査とコンテンツ作成に注力しています。
11月初旬、ケンブリッジ大学は 「トロイの木馬ソース」と呼ばれる研究を発表しました。この研究は、方向性のあるフォーマット文字を用いてソースコードやコメントにバックドアを隠す手法に焦点を当てています。これらを利用することで、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成することが可能になります。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。例えば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。ファイル名の末尾部分の方向を反転させる。最近の調査により、多くのコンパイラがソースコード内のUnicode文字を警告なしに無視する一方で、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行を再配置する可能性があることが明らかになりました。そのため、エディタはコードやコメントを、コンパイラが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。パブリックミッションご自身で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI私たちはcに行きますPDI
RLIの略語は右から左に分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップ・ディレクショナル・アイソレート）、右から左に読み上げます。結果は以下のようになります。
C O D E
ただし、コンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちは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)
