설명
DNS 정방향 또는 역방향 조회 결과나 요청 Host 이름을 신뢰 경계, 접근 허용, 인증 판단에 직접 사용하면 조작된 이름이나 해석 결과로 우회될 수 있습니다. 요청의 Host 이름은 클라이언트가 지정할 수 있고, DNS 조회 결과도 스푸핑, 캐시 오염, 리바인딩의 영향을 받을 수 있습니다.
잠재적 영향
- 공격자가 조작 가능한 이름 해석 결과로 접근 제어를 우회할 수 있습니다.
- 신뢰 도메인 확인이 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");
});
설명:
- 변경 전: DNS 정방향 또는 역방향 조회 결과나 요청 Host 이름을 신뢰 경계, 접근 허용, 인증 판단에 직접 사용하면 조작된 이름이나 해석 결과로 우회될 수 있습니다. 요청의 Host 이름은 클라이언트가 지정할 수 있고, DNS 조회 결과도 스푸핑, 캐시 오염, 리바인딩의 영향을 받을 수 있습니다.
- 변경 후: 인증과 권한 결정에는 TLS 클라이언트 인증, 서명 토큰, 서버 측 권한 모델처럼 DNS와 독립적인 신뢰 근거를 사용하세요.