トロイの木馬とは何か、どうやってソースコードに忍び込むのか
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
始めるためのリソース
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.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
