Javaのソースコード文字列にペイロードを隠す：Unicodeエスケープの“意外な”挙動と悪用の視点

本記事は、PortSwigger Researchによる「Hiding payloads in Java source code strings」（https://portswigger.net/research/hiding-payloads-in-java-source-code-strings）を元ソースとして要点を整理したものです。追加の背景説明も、提示されたresearchContext内の関連ソースに限定して補足します。

概要

Javaのソースコードでは、Unicodeエスケープ（例：\uXXXX形式）を含む文字列やトークンが、開発者の直感とは異なるタイミングで解釈され得ます。PortSwigger Researchは、この挙動が「驚くかもしれない」形で現れること、そしてそれを悪用してペイロードを“見た目上”隠す（レビュー時に気づきにくくする）手口が成立し得ることを示しています。

ここで重要なのは、隠蔽の狙いが「実行時の強力な暗号化」ではなく、「ソースコード上の可読性・監査性を意図的に下げる」点にあることです。つまり、通常のリファクタリングや静的解析、差分レビューといった工程において、危険な文字列や構文が目視で判別しづらくなること自体がリスクになります。

詳細

PortSwigger Researchの記事は、Javaがソースコード内のUnicodeエスケープを扱う際の仕様・挙動を踏まえると、文字列リテラルの“見た目”と、実際にコンパイラ（あるいは解釈の段階）が受け取る内容にズレが生じ得る点を扱っています。これにより、表面上は無害に見える断片に危険な意図を埋め込み、レビュー担当者や監査ツールの設定次第では検知しづらくする、という発想が可能になります。

この種の「解釈のギャップ」を突く考え方は、Webセキュリティでも一般的です。PortSwiggerのWeb Security Academyでは、入力が標準的なデコード処理を経ることを逆手に取り、フィルタを回避して有害なペイロード（XSSやSQLインジェクションなど）を通すために、さまざまなエンコーディングを使って攻撃を難読化できる旨が解説されています。ソースコード難読化も同様に、見る側・処理する側の「どの段階で何が正規化・デコードされるか」という前提のズレを狙う点で共通しています。

一方で、難読化は“隠せば終わり”ではありません。Security Stack Exchangeの議論でも、難読化されたコードはデオブファスケーション（読み解き）され得ること、そして難読化の有効性には限界があるという見方が示されています。したがって防御の観点では、難読化を「攻撃者が使う手段」として理解しつつも、最終的には（1）ビルドやCI段階での厳密な解析、（2）危険な構文・文字列パターンの検査、（3）レビュー体制や表示設定（エスケープを可視化する表示、差分の正規化表示など）の整備、といったプロセス面の対策が重要になります。

さらに、組織としては「見た目に頼った安全性判断」を減らすことが肝心です。ソースコードのレビューは最終防波堤になりがちですが、レビューは人間の認知に強く依存します。Unicodeエスケープのように、表示上は気づきにくい形で意味が変わる余地があるなら、レビュー補助の仕組み（自動検査やルール化）を前提にした運用が必要です。PortSwigger Researchの問題提起は、その“盲点”を具体例として意識化する点に価値があります。