サーバサイドレンダリングの導入から生じるSSRF | セキュリティブログ | 脆弱性診断（セキュリティ診断）のGMOサイバーセキュリティ byイエラエ

オフェンシブセキュリティ部の山崎です。サーバサイドレンダリング（SSR）の導入によってSSRFが発生する問題を見つける機会があったため、本記事では実例を交えながら紹介したいと思います。 サーバサイドレンダリング（SSR）とは？ 本記事で扱うSSRとは「サーバ上でHTMLを出力すること」を指しています。ただしerbやjspのようなテンプレートからHTMLを出力するのとは異なり、一般的には以下のようにクライアントサイドレンダリング（CSR）の文脈で使われることが主です。 近年のVue.jsやReactを代表するようなWebフロントエンドフレームワークはブラウザ上で動的にDOMツリーを構築して画面を描画（CSR）するのが主流となっています。これによってページ遷移を挟まずユーザ体験のよいシングルページアプリケーション（SPA）が作ることができるというメリットがあります。 ただ、単純なSPAにはデメ

[tyage]

書きました

[rjge]

クライアントからのリクエストは信頼できないコンテンツだって前提は常に頭に入れておきたい

[nmcli]

まあ、結局はクライアントから送られて来るパラメータをできるだけ信用しない設計にするのが基本だわな

[efcl]

requestヘッダをSSRに使ってるときにSSRFが起きるとい話

[raimon49]

HTTPヘッダ経由でのインジェクション

[n314]

いまいちよく分からんが、不正なHostで200返す時点で間違ってるような。

[Falky]

たし蟹

[yujiorama]

SSRでもクライアントのリクエストを信頼してはいけない話

[takezaki]

“SSR関連のフレームワークとしてはNext.jsやNuxt.jsが有名ですが、これらで推奨されている実装方法に従えばこの問題は起きづらいようです。”

[rryu]

Fetch APIを使っていてかつ相対URLのホスト名の補完にリクエスト由来の値を使っているとそれがサーバサイドで実行された時にSSRFが発生する。

[hirose504]

“Nuxt.jsのhttpモジュールでは、デフォルトの通信先ホスト名は環境変数等から選択されるためユーザ入力値が自動的に使用されることはありません”

[Keisuke69]

リクエストヘッダのHostを参照してるようなものだとよろしくない、と