チップス
どんぐり大学卒、一般企業の情報システム部で働く若手エンジニア。
入社1〜3年目らしい悩みを抱えつつ、日々の運用やセキュリティ対応に奮闘中。慌てんぼうだが素直で吸収力が高く、ボスに鍛えられながら着実に成長している。
ボス
セキュリティ、インフラ、運用の修羅場をくぐってきた歴戦のエンジニア。サイバーセキュリティラボの所長でボスと呼ばれている。
現場視点と経営視点の両方から、本当に使えるセキュリティとキャリア戦略を叩き込む。口は悪いが面倒見はよく、若手育成と実践的な情報発信に力を注いでいる。
「AIコードレビューを導入したから、セキュリティは安心だと思ってたのに…」
「フレームワークが自動で入れるコードにも脆弱性が潜んでいるの？」
チップスボス！Claude CodeもCodex Securityも見落としたセキュリティの穴があるって記事を見たでしゅ！AIのレビューって万能じゃないんでしゅか！？
ボスふふふ、万能だと思っていたのか？今回の問題は、Railsのフレームワークが「自動で」挿入するCSRFトークンが外部に漏れるというものだ。コードの表面上には脆弱性が見えない。だからこそ、AIも人間も見落とした。
GMOサイバーセキュリティ byイエラエが公開したこの事例は、LLMベースのセキュリティツールの限界を端的に示しています。
AIレビューを過信せず、フレームワークの暗黙的な動作まで理解することの大切さを、この記事で確認しましょう。
SAML認証やフレームワークのセキュリティに関わる方は、ぜひ確認してみてください。
SAML SSOでは、IdP（認証を行う側）がSP（サービス提供側）にHTTP POSTで認証結果を送信します。
このとき、Railsのform_tagヘルパーを使うと問題が起きます。
Railsのform_tagは、CSRF対策として自動的に認証トークンをhiddenフィールドに挿入します。
通常のアプリ内フォームなら正しい動作ですが、SAML認証のように外部ドメインへPOSTする場面では状況が変わります。
本来IdP内部でしか使われないはずのCSRFトークンが、外部のSPに送信されてしまうのです。
攻撃者がこのトークンを入手すると、以下のような被害が発生する恐れがあります。
特にRedisセッションストレージを使用し、SameSite Cookie属性が未設定の環境ではリスクが高まります。
チップスえっ、フレームワークが勝手に入れるコードが原因なんでしゅか？コードを見ても分からないじゃないでしゅか！
ボスだからこそ厄介なんだ。コードレビューで見えるのは「書いたコード」だけで、フレームワークが裏で何をしているかまでは追えない。ツールに頼る前に、使っているフレームワークの動作を理解しておく必要がある。
Claude Codeの/security-reviewコマンドやCodex Securityは、SPの許可リストが開放的すぎる点は指摘できました。
しかし、CSRFトークンの漏洩については検出できませんでした。
LLMがこの脆弱性を見落とした理由は明確です。
修正方法はシンプルで、外部へのPOSTにはフレームワークのフォームヘルパーを使わず、素のHTMLで記述します。
これにより、CSRFトークンの自動挿入を防げます。
Spring BootのThymeleafなど、他のフレームワークでも同様のパターンに注意が必要です。
ボスAIは優秀な助手だが、フレームワークの「裏側」を知るのは人間の仕事だ。ツールを使いこなすには、ツールの限界を知っておかないとな。
チップスAIだけに頼らず、自分でもフレームワークの動きを理解しなきゃいけないんでしゅね。勉強するでしゅ！
今回の事例は、AIセキュリティレビューの限界を示す貴重なケースです。
フレームワークが暗黙的に行う処理には、コード上に現れない脆弱性が潜んでいます。
SAML認証を実装する際は、外部ドメインへのフォーム送信でフレームワークのヘルパーを使わないことを徹底しましょう。
参考：GMOサイバーセキュリティ byイエラエ – Claude CodeもCodex Securityも見落とした脆弱性
