AngularJSの亡霊：テンプレートインジェクションと「安全」の幻想
現代のWeb開発において、ReactやVue、あるいはAngularの最新版を使用しているエンジニアは「XSS？ああ、フレームワークがエスケープしてくれるやつでしょ」と高を括っているかもしれない。しかし、セキュリティの現場において「フレームワークが自動でやってくれる」という前提は、時として最も危険な盲点となる。
今日は、かつてWebフロントエンドを席巻し、今なおレガシーシステムとして生き続けるAngularJS（1.x系）のテンプレートインジェクションと、そのサンドボックス回避が我々に突きつける「防衛の限界」について、アーキテクトの視点から解剖する。
1. 根本原因：パースロジックの「過剰な親切心」
AngularJSの核心的な脆弱性は、その設計思想そのものにある。AngularJSはHTMLの中に独自の式（Expression）を埋め込むことで動的なDOM生成を実現していた。この仕組みを支えるのが$parseサービスだ。
// AngularJSが内部的に式を評価するイメージ
// ユーザー入力をそのまま式として受け入れてしまうことが全ての始まり
$scope.$eval(userProvidedString);
本来、$parseは単なるデータバインディングのためのものだった。しかし、JavaScriptのサブセットとして定義されたこの式言語は、極めて強力な実行環境を内包していた。ここに、開発者が意図しない「コード実行」の余地が生まれた。これが、いわゆるAngularJSのテンプレートインジェクションだ。
2. サンドボックス回避：論理のバグを突く
AngularJSの初期バージョンでは、この式実行を制限するために「サンドボックス」を設けていた。しかし、これは「悪意あるコードを拒否する」というブラックリスト方式の試みであり、本質的に脆弱だった。
攻撃者は、JavaScriptのプロトタイプチェーンを辿り、Functionコンストラクタを呼び出すことでサンドボックスを突破した。有名な回避ペイロードを分解すると、その「泥臭さ」がよく分かる。
// 典型的なペイロード例（一部簡略化）
// constructorプロパティを辿って、Functionコンストラクタを呼び出し、
// 任意のalert(1)を実行させる
{{
‘a’.constructor.prototype.charAt = [].join;
[1]|orderBy:'(a=alert(1))’
}}
この手法の恐ろしい点は、Webアプリケーションのパケット構造上は「ただの文字列」として送信され、サーバーサイドのWAFや正規表現フィルタを容易にすり抜けることだ。プロトコルレイヤーではHTTPの正常なリクエストに過ぎないため、IDS/IPSによる検知も困難を極める。
3. なぜ現代のフレームワークでも「安全」と言い切れないのか
最新のフレームワーク（ReactやAngular v2以降）では、データバインディング時に自動的にエスケープ処理が走る。しかし、我々が警戒すべきは「フレームワークの機能」ではなく「開発者の実装ミス」だ。
dangerouslySetInnerHTMLの安易な利用: Reactにおいて、外部ソースのHTMLを直接挿入するこのメソッドは、XSSの温床となる。- フレームワークを介さないDOM操作:
document.getElementById().innerHTML = ...といった、JSネイティブな操作が混在する場合、セキュリティガードレイルは機能しない。 - 生成AIによるコード生成の罠: 近年、AIが生成したコードの中に、サニタイズを省略した危険なパターンが紛れ込むケースが増加している。AIは「動くコード」を作るのが得意だが、「堅牢なコード」を作ることは保証しない。
4. 現場で打つべき防衛の「次の一手」
今、アーキテクトに求められるのは、フレームワークの機能に依存しない「多層防御」だ。
CSP（Content Security Policy）の厳格化
フレームワークがサンドボックスを回避されることを前提に、ブラウザ側で実行を制限する。
CSPヘッダーの例
unsafe-eval を排除し、インラインスクリプトを禁止することで、
万が一テンプレートインジェクションが発生しても実行を阻止する
Content-Security-Policy: default-src ‘self’; script-src ‘self’; object-src ‘none’;
アーキテクチャの監査：信頼境界の明確化
ユーザーからの入力（Untrusted Data）を直接コンポーネントのテンプレートとして評価させるロジックがないか、以下の観点でコードをレビューしてほしい。
1. 動的なテンプレート生成の排除: サーバーから受け取った文字列をそのまま ng-bind-html や innerHTML に流し込んでいないか？
2. サニタイズの強制: 必須であれば DOMPurify などの信頼できるライブラリを必ず噛ませる。
3. 入力の検証: 型定義や検証ロジックをフロントエンドだけでなく、APIの受付口で必ず実施する（Zero Trustの実装）。
結びに代えて
AngularJSの脆弱性は、古の遺物ではない。今なお、多くの大規模システムにおいて、その「便利さ」という麻薬に頼った設計が残されている。
セキュリティとは、ツールを盲信することではない。「フレームワークは常に壊れうる」という前提に立ち、その壊れた瞬間にどう被害を最小化するかという「壊れた後の設計」を考えることだ。
コードを書くとき、ふと立ち止まって考えてみてほしい。あなたが書いたその一行が、将来の脆弱性の温床になっていないか。それが、真のエンジニアリングにおける「守り」の第一歩となる。
コメント