Description
Using forward or reverse DNS results, or the request's Host name, as direct proof of trust, access permission, or identity can allow bypasses. Clients can choose the request's Host name; DNS results may also be affected by spoofing, cache poisoning, or rebinding.
Potential impact
- Attacker-controlled names or resolution results may bypass access controls.
- Trust checks based on domain names may be vulnerable to DNS rebinding or manipulated reverse DNS.
Remediation
- Base authentication and authorization on evidence independent of DNS.
- If network location checks are needed, compare resolved IPs with allowed CIDR ranges and revalidate after redirects.
Examples
Before
javascript
app.get("/host", (req, res) => {
const host = req.hostname;
if (host === "trusted.example.com") {
return res.send("allowed");
}
res.status(403).end();
});
After
In this excerpt, verifySignedToken validates the signature, expiration, and other token requirements, rejects failures, and returns a verified role array on the user object.
javascript
app.get("/host", (req, res) => {
const user = verifySignedToken(req);
if (!user.roles.includes("admin")) {
return res.status(403).end();
}
res.send("allowed");
});
Explanation:
- Before: A client-supplied Host name is treated as permission to access the endpoint.
- After: Use a signed token and server-side role checks. TLS client authentication is another trust source independent of DNS.