AIセキュリティレビューの盲点：CSRFトークン漏洩をClaude CodeもCodexも見落とした理由

「AIコードレビューを導入したから、セキュリティは安心だと思ってたのに…」
「フレームワークが自動で入れるコードにも脆弱性が潜んでいるの？」

チップス

ボス！Claude CodeもCodex Securityも見落としたセキュリティの穴があるって記事を見たでしゅ！AIのレビューって万能じゃないんでしゅか！？

ボス

ふふふ、万能だと思っていたのか？今回の問題は、Railsのフレームワークが「自動で」挿入するCSRFトークンが外部に漏れるというものだ。コードの表面上には脆弱性が見えない。だからこそ、AIも人間も見落とした。

GMOサイバーセキュリティ byイエラエが公開したこの事例は、LLMベースのセキュリティツールの限界を端的に示しています。
AIレビューを過信せず、フレームワークの暗黙的な動作まで理解することの大切さを、この記事で確認しましょう。

SAML認証やフレームワークのセキュリティに関わる方は、ぜひ確認してみてください。

CSRFトークンが外部に漏れる仕組み

SAML SSOでは、IdP（認証を行う側）がSP（サービス提供側）にHTTP POSTで認証結果を送信します。
このとき、Railsのform_tagヘルパーを使うと問題が起きます。

Railsのform_tagが引き起こす落とし穴

Railsのform_tagは、CSRF対策として自動的に認証トークンをhiddenフィールドに挿入します。
通常のアプリ内フォームなら正しい動作ですが、SAML認証のように外部ドメインへPOSTする場面では状況が変わります。
本来IdP内部でしか使われないはずのCSRFトークンが、外部のSPに送信されてしまうのです。

攻撃者がこのトークンを入手すると、以下のような被害が発生する恐れがあります。

特にRedisセッションストレージを使用し、SameSite Cookie属性が未設定の環境ではリスクが高まります。

チップス

えっ、フレームワークが勝手に入れるコードが原因なんでしゅか？コードを見ても分からないじゃないでしゅか！

ボス

だからこそ厄介なんだ。コードレビューで見えるのは「書いたコード」だけで、フレームワークが裏で何をしているかまでは追えない。ツールに頼る前に、使っているフレームワークの動作を理解しておく必要がある。

AIレビューの限界と正しい対策

Claude Codeの/security-reviewコマンドやCodex Securityは、SPの許可リストが開放的すぎる点は指摘できました。
しかし、CSRFトークンの漏洩については検出できませんでした。

AIが見落とした理由と修正方法

LLMがこの脆弱性を見落とした理由は明確です。

修正方法はシンプルで、外部へのPOSTにはフレームワークのフォームヘルパーを使わず、素のHTMLで記述します。
これにより、CSRFトークンの自動挿入を防げます。
Spring BootのThymeleafなど、他のフレームワークでも同様のパターンに注意が必要です。

まとめ

ボス

AIは優秀な助手だが、フレームワークの「裏側」を知るのは人間の仕事だ。ツールを使いこなすには、ツールの限界を知っておかないとな。

チップス

AIだけに頼らず、自分でもフレームワークの動きを理解しなきゃいけないんでしゅね。勉強するでしゅ！

今回の事例は、AIセキュリティレビューの限界を示す貴重なケースです。
フレームワークが暗黙的に行う処理には、コード上に現れない脆弱性が潜んでいます。
SAML認証を実装する際は、外部ドメインへのフォーム送信でフレームワークのヘルパーを使わないことを徹底しましょう。

参考：GMOサイバーセキュリティ byイエラエ – Claude CodeもCodex Securityも見落とした脆弱性