説明
DNSの正引き・逆引き結果やリクエストのHost名を、信頼やアクセス許可、認証の直接の根拠にすると、操作された名前や結果によって回避される可能性があります。リクエストのHost名はクライアントが指定でき、DNSの結果もスプーフィング、キャッシュポイズニング、リバインディングの影響を受ける場合があります。
想定される影響
- 攻撃者が操作できる名前や名前解決の結果によるアクセス制御の回避
- DNSリバインディングや逆引き結果の操作による、信頼するドメインの確認の回避
対処方法
- 認証と認可には、DNSから独立した信頼の根拠を使ってください。
- ネットワーク上の接続先を検証する場合は、解決したIPを許可CIDRと比較し、リダイレクト後も再検証してください。
例
変更前
javascript
app.get("/host", (req, res) => {
const host = req.hostname;
if (host === "trusted.example.com") {
return res.send("allowed");
}
res.status(403).end();
});
変更後
この抜粋の verifySignedToken は、署名、有効期限などの要件を検証し、失敗したリクエストを拒否するヘルパーです。返すユーザーオブジェクトには検証済みの役割の配列を含めます。
javascript
app.get("/host", (req, res) => {
const user = verifySignedToken(req);
if (!user.roles.includes("admin")) {
return res.status(403).end();
}
res.send("allowed");
});
説明:
- 変更前: クライアントが指定したHost名をアクセス許可の根拠にしています。
- 変更後: 署名付きトークンとサーバー側の役割の確認を使います。TLSクライアント認証も、DNSから独立した信頼の根拠です。