Seasar2・Teedaとは？EOLの古いWebフレームワークが危険な理由

【要約】Seasar2 / Teeda と EOLリスクのポイント#

項目	詳細
Teedaとは？	JavaのSeasar2 / JSFベースで画面を作る古いWebフレームワーク
EOLの状況	2016年9月にサポート終了（10年以上経過）
HTMLから判明する理由	`xmlns:te` 属性や `/teedaExtension/.../ajax.js` のパスで痕跡が丸見え
EOLがヤバい本質	「今すぐ動かなくなる」ではなく「新脆弱性が来ても公式パッチが出ない」点
依存関係のリスク	本体が無事でも、内部で使う古いライブラリ（StrutsやCommons等）から抜かれる

タイムズカーのサイトを見ていたら、HTMLに古いJavaフレームワーク「Teeda」の痕跡を見かけた。
タイムズカーの不正アクセス事故（第3報）が話題になっていたタイミングでもあったので気になって調べた備忘録。

※なお、タイムズカーの公式発表では事故原因としてTeedaやSeasar2は一切挙げられていないので、「Teedaのせいで漏洩した」なんて話ではない。
今回はそこではなく、 「EOLになった古いWebフレームワークを使い続けると何がどう危険なのか？」 を技術的に掘り下げてみる。

そもそもSeasar2とTeedaって何者？#

Java周りの昔のフレームワークって関係性がややこしい。
ざっくり図にするとこんな感じ。

graph TD
    Java["Java Webアプリケーション"]
    Java --> JSF["JSF 標準仕様"]
    JSF --> Teeda["Teeda 画面/プレゼンテーション"]
    Java --> Seasar2["Seasar2 DIコンテナ"]
    Seasar2 -.->|内部で利用/依存| Teeda

TeedaはJSF（JavaServer Faces）の仕様をベースに作られた画面構築用のプレゼンテーションフレームワーク。
その裏側でDIコンテナとしてSeasar2が動いているようなイメージ。

Teeda Extensionを使うと、JSPじゃなくて普通のHTMLをテンプレートにして、対応するJavaのページクラスとバインドして画面を作れた。
昔のJava開発（2000年代後半〜2010年代前半）ではかなり人気があったやつだ。

一言で言えば、**「JavaでWeb画面をサクッと作るための仕組み」**と思えばOK。

なぜフロントのHTMLからTeedaがバレるのか？#

「なんでサーバー側のJavaフレームワークがHTML見ただけで分かるの？」って思うかもしれないが、HTMLにバッチリ名前が残ってる。

xmlns:te="http://www.seasar.org/teeda/extension"

こんな感じのネームスペース宣言があったり、

<script src="/view/teedaExtension/org/seasar/teeda/ajax/js/ajax.js?20201217"></script>

Teeda独自のAjax用JavaScriptが特定パスで読み込まれてたりする。
フロントに特有のタグやJSパスが出力される仕様なので、HTMLソースを見れば「あ、これTeeda使ってるな」と一発で分かってしまうわけだ。

ただし、HTMLから分かるのはあくまで「Teedaを使っている痕跡がある」ということまで。
サーバー内部でどう組み込まれているか、バージョンはいくつか、現在もメインで動いているのかまでは分からない。

EOLって何がそんなにヤバいの？（動くならそのままでダメなの？）#

Teedaを含むSeasarプロジェクトの多くは、**2016年9月26日にEOL（サポート終了）**を迎えている。
2026年現在からすると、実に10年間放置されていることになる。

ここで素朴な疑問が出てくる。
「EOLでも普通に動いてるなら、そのままでも良くない？」

結論から言うと、「今日動いてるから明日も安全」とはならないのがEOLの怖いところ。

flowchart TD
    A["平時: 問題なく動作<br/>動くだけなら動作する"] --> B["新たな脆弱性 / ゼロデイが発覚"]
    B --> C{"公式のEOL状態"}
    C -->|サポート終了| D["公式から修正パッチが提供されない"]
    D --> E["【恐怖】自力で修正するかサービス停止の2択"]

EOL（End of Life）になった瞬間にプログラムが自己破壊するわけじゃない。
「ドキュメントや過去ライブラリの配布は続くけど、新しい脆弱性が見つかっても誰も直してくれないよ」という状態になることだ。

つまりEOLの恐怖ってのは、**「今危険かどうか」ではなく「問題が起きた時に詰む」**という点にある。

フレームワーク単体だけ見てても意味がない理由#

調査していて一番「なるほどな」と思ったのがこれ。
Webフレームワークって単体で動いてるわけじゃない。

Teedaの依存関係を調べてみると、Seasar2本体だけじゃなく、Servlet API、JSP、Commons Collections、Commons Loggingなんかがズラッと並んでいる。

graph TD
    App["Webアプリケーション"]
    App --> Teeda["Teeda 画面制御"]
    Teeda --> Seasar2["Seasar2 DIコンテナ"]
    Seasar2 --> Libs["依存ライブラリ<br/>Commons, Strutsなど"]
    Libs --> Runtime["Java / Servlet / Webコンテナ<br/>Tomcatなど"]

つまり、「Teeda自体に脆弱性があるか？」だけを気にしてても意味がない。
Teedaが内部で抱え込んでいる古い外部ライブラリや、Java実行環境自体に脆弱性が見つかったら、それだけでアウトになる可能性がある。

実際にあったS2Strutsの恐怖事例#

「依存ライブラリのせいで巻き込まれる」イメージを掴むのにいい例が、Seasar系の別プロダクトであるS2Strutsだ。

過去にJVNで報告された脆弱性（JVN#19118282）では、S2Struts自体ではなく、内部で使っていたApache StrutsにClassLoader操作の脆弱性があったことが原因で、S2Strutsまで任意コード実行のリスクに晒された。

JVN#19118282 の攻撃経路と何ができてしまうのか？#

「ClassLoaderが操作できると何がマズいの？」って思うかもしれないが、これがかなり極悪。
具体的にどういう経路で何が起こるのかをMermaidで図にするとこんな感じになる。

graph TD
    A["攻撃者"] -->|1. 悪意あるリクエスト<br/>class.classLoader...| B["S2Struts / Struts"]
    B -->|2. パラメータ自動バインド| C["Javaオブジェクト"]
    C -->|3. getClass メソッド経由で貫通| D["ClassLoader<br/>Tomcat等のサーバー核心部"]
    D -->|4. サーバー設定の書き換え| E["ログ出力設定・ディレクトリ改ざん"]
    E -->|5. Webシェルの配置・実行| F["【被害】任意コード実行 RCE<br/>サーバー完全乗っ取り"]

【何が問題の経路になっているのか？】

リクエストの自動バインド: StrutsやS2Strutsには、画面から送られてきたフォームデータをJavaオブジェクトのプロパティに自動でセットする機能がある。
getClass() への突き抜け: 本来なら「名前」や「年齢」セット用の口なのだが、Javaの仕様上すべてのオブジェクトが持つ getClass() メソッド経由で、class.classLoader... というパラメータを送り込むと、Webサーバー（Tomcatなど）の核心部である ClassLoader（クラスローダー） にアクセスが届いてしまう。
サーバー設定の改ざん: クラスローダーまで届くと、Tomcatのログ設定（ログの出力ファイル名や拡張子）をリクエスト経由で勝手に書き換えられてしまう。

【何ができてしまうのか？】

Webシェルの配置と任意コード実行（RCE）: ログの拡張子を .jsp に変えて、ログ内容にJavaコードを含めるようなリクエストを送りつけることで、サーバー上に悪意あるスクリプト（Webシェル）を勝手に生成できちゃう。
サーバーの完全乗っ取り: Webシェルが配置されると、攻撃者はブラウザ経由でサーバー上の任意のOSコマンドが実行可能になる。データベースの個人情報を丸ごと引き抜かれたり、サーバー自体を乗っ取られて踏み台にされたりするわけだ。

※もちろんS2StrutsとTeedaは別物なので、Teedaで全く同じ攻撃ができるわけじゃない。
ただ、「フレームワーク本体が無事でも、内部で使ってるライブラリの穴からサーバーごと落ちる」という構造は完全に同じだ。

「古い＝即アウト」ではない？#

ここまで見てくると、「古いフレームワーク＝速攻でハックされる」と思いがちだが、実はそうとも言い切れない。

flowchart TD
    A["古いフレームワークを使用"] --> B["古い依存ライブラリもセットで固定"]
    B --> C["脆弱性発見時に公式修正版が出ない"]
    C --> D["自力パッチ / WAF回避 / フレームワーク移行など<br/>リカバリ難易度が跳ね上がる"]

結局のところ、**「古い＝即危険」というよりは、「脆弱性が見つかった時のリカバリ難易度が跳ね上がる」**と考えるのがしっくりくる。

古いWebフレームワークを見つけた時にチェックすべきポイント#

もし自分がレガシーシステムの調査を任されたら、単に「EOLだからダメです！」と騒ぐのではなく、以下の順番でリスクを掘り下げていくと思う。

flowchart TD
    P1["1. フレームワーク / バージョン確認"] --> P2["2. EOL状態の確認"]
    P2 --> P3["3. 依存ライブラリ Commons等のバージョン確認"]
    P3 --> P4["4. 実行環境 Java / Tomcat のバージョン"]
    P4 --> P5["5. 既知のCVE/JVN脆弱性との照合"]
    P5 --> P6["6. 脆弱な機能が実際使われているか？"]
    P6 --> P7["7. 外部から攻撃可能なリクエスト経路か？"]
    P7 --> P8["8. WAF等の緩和策で防げているか？"]

「脆弱性があること」と「実際に攻撃可能であること」は別問題。
機能を使ってなかったり、WAFでガードされていれば即被害には繋がらないが、EOLだと運用コストと心理的負担が毎年増していくのは間違いない。

まとめ：EOLが本当に恐しいのは「復旧の選択肢が消える」こと#

タイムズカーのHTMLにあったTeedaの痕跡から調べてみたが、今回の学びをまとめるとこんな感じ。

Teedaは2016年にEOLになっており、サポートは終了している。
HTMLの xmlns:te や /teedaExtension/.../ajax.js で使っていることが丸見えになる。
EOL＝即死亡ではない。 本当に恐しいのは、新しい脆弱性が出た時に公式パッチが来ないこと。
本体だけでなく、内部で抱えている古い依存ライブラリ（Commons等）の脆弱性から刺されるリスクがある。
古いフレームワークが怖いのは「古い」ということ自体より、**「何かあった時に安全な状態に戻す手段（選択肢）がなくなっている」**こと。

なお繰り返しになるが、タイムズカーの不正アクセス件で 「TeedaやSeasar2が原因だった」という発表は一切ない。
公開HTMLに痕跡があることと、実際の事件の原因は全く別物として考える必要がある。

「古いフレームワークを使ってるからこの会社はダメだ」と決めつけるのではなく、**「自分の管理するシステムにEOLのフレームワークが残っていたらどう対処すべきか？」**を考える良いきっかけにしたい。