비밀번호 재설정 메일의 절대 URL은 임의 요청이 보낸 Host 값을 그대로 이어 붙여 만들지 않습니다. 서버에 설정한 공개 URL을 쓰거나, 요청 host가 사전에 검증된 신뢰 도메인 목록에 있는지 확인해야 합니다.
Host를 고정해도 reset 흐름 전체가 안전해지는 것은 아닙니다. HTTPS, 충분히 무작위이고 단회 사용·만료되는 token, 재설정 페이지의 Referrer 정책, token 로그 노출을 별도로 확인합니다.
Host 헤더는 서비스의 신뢰된 기준 URL이 아닙니다
HTTP 요청의 Host 값은 클라이언트가 보내는 입력입니다. reverse proxy가 전달하는 X-Forwarded-Host 역시 프록시가 어떤 값을 덮어쓰거나 검증하는지 확인하지 않고 신뢰하면 안 됩니다. 비밀번호 재설정 서비스가 이 값으로 이메일 링크를 만들면 공격자가 자신의 도메인을 넣은 링크가 정상 발신 도메인의 메일로 전송될 수 있습니다. 수신자는 메일 발신자를 보고 URL도 믿을 수 있다고 오인할 수 있습니다.
교육용 메일 기록 세 건을 비교합니다
| 입력·서버 설정 | 생성 URL 예시 | 판정 |
|---|---|---|
| Host: account.example.test; 서버 기준 URL도 고정 | https://account.example.test/reset?token=[REDACTED] | 신뢰 기준 URL 사용 |
| Host: attacker.example; 요청 host를 무검증 사용 | https://attacker.example/reset?token=[REDACTED] | 링크 도메인 조작 가능 |
| Host: tenant.example.test; 사전 허용 목록에 없음 | 메일 생성 중단 또는 검증 오류 | allowlist 외 host 거부 |
실서비스에서 외부 호스트를 지원해야 한다면 무조건 첫 요청을 거부하라는 뜻은 아닙니다. tenant별 domain이 이미 승인·소유 확인됐는지 서버 설정에서 찾아 해당 account와 묶어야 합니다. HTTP Host 문법만 정규화하거나 문자열 접미사 비교만 하는 방식은 example.test.attacker.invalid 같은 변형을 놓칠 수 있습니다. 가능하면 복구 링크의 기준 origin을 요청 처리 경로와 별도로 신뢰된 설정으로 관리합니다.
URL token을 쓰더라도 수명을 짧게 관리합니다
OWASP의 복구 지침은 token이 암호학적으로 안전하게 생성되고, 충분히 길며, 안전하게 저장되고, 한 번 사용한 뒤 무효화되고 적절한 시간에 만료되도록 권고합니다. 링크에 token이 들어가면 접근 로그·브라우저 이력·공유된 메시지에 남을 수 있습니다. URL token을 쓴다고 해서 자체로 비정상은 아니지만 권한을 부여하는 비밀값으로 다루고 노출 경로를 제한해야 합니다.
재설정 페이지에서 Referer 전달도 확인합니다
재설정 페이지가 외부 이미지나 분석 자원을 불러오면 브라우저의 Referer 헤더가 요청 URL의 일부를 전달할 수 있습니다. OWASP는 reset 페이지에 no-referrer 정책을 두고, token 추측을 막을 속도 제한을 검토하도록 안내합니다. 실제 정책이 URL 경로·query를 어떻게 처리하는지는 브라우저와 응답 헤더를 확인해야 합니다. 페이지가 token을 소비한 뒤 token 없는 URL로 이동하는 설계도 고려할 수 있지만, 구체 구현은 서비스 검토가 필요합니다.
복구 링크 생성 경계를 순서대로 확인합니다
- 재설정 URL의 기준 origin이 설정 파일·승인 목록 어디에서 오는지 추적합니다.
- Host와 forwarded host를 임의 값으로 바꾼 가상 테스트를 만들고 생성 URL이 영향을 받는지 확인합니다.
- 서버가 고정 origin 또는 account별 검증 allowlist를 쓰는지 확인합니다.
- 링크가 HTTPS이고 token이 무작위·사용자 귀속·단회·만료 조건을 가지는지 점검합니다.
- 웹 서버와 메일 템플릿 로그가 token 원문을 보존하지 않도록 합니다.
- 복구 페이지의 Referrer 정책과 외부 자원 요청을 살핍니다.
- 실제 메일 전송이나 운영 계정 변경은 별도 승인 절차에서 다룹니다.
도메인을 고정해도 token의 재사용까지 막히지는 않습니다
도메인 검증은 링크의 목적지를 보호하고 token 수명·단회 검증은 복구 권한을 보호합니다. 둘 중 하나로 다른 쪽을 대신할 수 없습니다. 공개 도메인만 바꾼 테스트는 URL 생성 경계를 보여 줄 뿐, 실제 메시지 보안이나 계정 복구 권한 검사를 증명하지 않습니다.
복습: Host가 바뀌면 링크도 따라가야 하나요?
문제: 사용자가 보낸 Host가 attacker.example인데 서버에 설정된 복구 origin은 account.example.test입니다. 어떤 주소로 재설정 링크를 만들어야 하나요?
정답: 고정된 account.example.test를 기준으로 만듭니다. 승인된 여러 origin을 지원하는 경우에도 요청 Host를 그대로 믿지 않고 사전에 검증된 목록에서 선택합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
재설정 서비스가 받은 Host가 untrusted.invalid인데 고정 복구 origin은 account.example.test입니다. reset URL은 어느 host를 사용해야 하며, token 보호에서 두 가지를 더 적으세요.
정답과 해설 확인
신뢰된 고정 origin을 씁니다. token은 안전하게 생성하고 충분히 길게 하며, 사용 후 무효화·만료되도록 하고 HTTPS와 Referer 노출 방지도 확인합니다.요청 Host는 신뢰할 수 있는 절대 URL 원천이 아닙니다. URL host 검증, token 생명주기, 전송·브라우저 노출은 서로 다른 보호 지점입니다.