流入リンクをopen redirectにしない――安全な遷移先とURL tokenの検証

利用者入力を含む遷移先を許可するとき、javascript scheme、偽装host、相対URL、改変tokenをどう拒否するか。

コードから観測できること

1. safe redirectとURL tokenは専用libへ分離され、safe redirectにはテストがある。リンク機能ごとに独自の文字列判定を複製しないことが監査可能性につながる。
2. URLの見た目ではなくURL parserが解釈したscheme・host・pathを基準にする必要がある。example.com.attackerのような接頭辞一致は許可判定にならない。
3. tokenは秘匿値とは限らない。改変検知、期限、用途、再利用可否を分け、URLへ含まれる個人識別子をアクセスログへ残しすぎない設計が必要になる。

再現・追加測定の手順

1. 正常な同一origin・許可外origin・相対URLを列挙する
2. scheme省略や文字コードを変えた入力を追加する
3. tokenを1 byteずつ改変する
4. 拒否時のfallback先とログ内容を確認する

この資料だけでは証明できないこと

1. 許可host自体が侵害された場合はredirect検査だけで防げない。
2. 短縮URLの多段redirectは最終到達先まで別途観測する必要がある。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。