로그인 흐름이 진짜와 가짜를 똑같이 만들어 피싱은 사용자나 DNS 탓이 아니다
"의심스러운 링크를 누르지 마세요"라는 보안 수칙은 정작 실제 서비스 환경에서 거의 힘을 쓰지 못한다는 지적이 나왔다. 원인은 사용자의 부주의가 아니라, 정상적인 로그인 과정 자체가 여러 도메인을 넘나들도록 설계돼 있다는 점이다. 한 조직의 인증 흐름이 자사 도메인에서 출발해 전혀 다른 회사의 도메인을 몇 번이고 거쳐 다시 자사 도메인으로 돌아오는 식이라면, 사용자는 결국 URL을 읽지 않는 습관을 학습하게 된다.
글쓴이는 실제 사례에서 이름만 바꾼 로그인 체인을 공개했다. 회사 도메인의 특정 경로에서 시작해 login.[회사].com, login.smallcrow.com 뒤에 붙은 UUID, experience.crow-cloud.com/[회사]/auth, flock.auth.bird-security.com/authorization, api-deadbeef.bird-security.com/oauth/v1/authorize?token=..., api2.bird-security.com/2fa를 차례로 통과한 뒤 다시 회사 도메인으로 돌아온다. 이 긴 여정 어디에도 아이디·비밀번호·2단계 인증 코드를 입력하는 화면은 해당 회사 도메인에 호스팅되지 않는다. 여기에 토큰 만료로 갑자기 튀어나오는 인증 팝업까지 겹치면 사용자가 피싱을 알아챌 여지는 사실상 사라진다. 공격자가 할 일은 회사 로고와 비밀번호 입력창을 넣은 웹사이트를 만드는 것뿐이고, URL은 아무도 보지 않으니 상관없다.
URL 자체가 직관적이지 않다는 점도 인정해야 한다. 스킴과 호스트 이름은 구체적인 요소에서 일반적인 요소로 진행하고, 경로는 반대 방향으로 읽힌다. 예를 들어 어떤 이미지 주소에서 프로토콜, 서버 이름, 운영자, 최상위 도메인이 차례로 나오고 그 뒤에 폴더와 파일명이 붙는 구조를 생각하면, 정작 중요한 2차 도메인은 URL 한가운데에 박혀 있게 된다. 비기술 사용자에게 이 구조를 가르쳐야 하지만, 호스트 이름이 신뢰할 수 있는 지표가 아니라면 그 교육 자체가 무의미해진다.
그래서 제안은 규범적인 어조로 제시된다. 조직은 하나의 잘 알려진 루트 도메인을 사용해야 하고, 내부 서비스는 반드시 그 루트의 서브도메인에 두어야 한다. [회사]-auth.com, [회사].다른회사.com, 다른회사.com/[회사], auth.다른회사.com/[큰 UUID] 같은 형태는 사기 사이트와 구분되지 않으므로 정상화해서는 안 된다는 것이다. 로그인 페이지에서 특히 치명적이지만, 좋은 습관을 만들고 사회공학 공격을 막기 위해 모든 곳에 적용하는 편이 낫다. 이메일이나 SMS로 보내는 링크도 인식 가능한 도메인 아래에 있어야 하며, 부득이하게 외부로 보내야 한다면 자사 도메인의 로컬 리다이렉트를 만들어 경유시키라고 권한다. 모든 것을 직접 호스팅할 필요는 없다는 점도 짚는다. 커스텀 도메인을 지원하는 서비스가 많고 링크 자체는 무료다. 전화번호도 같은 원칙이 적용된다. 문자나 메일로 특정 번호로 전화하라고 안내해서는 사기 여부를 확인할 방법이 없으므로, 원문 메시지에서 링크한 웹페이지에 연락처를 제공해야 한다. 글은 이런 요구 수준을 표현할 때 RFC 2119의 MUST·SHOULD 등의 정의를 따른다고 밝힌다.
배경에는 DNS에 대한 신뢰 문제가 깔려 있다. DNS는 40년 넘게 계층 구조를 유지해 왔고, 어떤 웹사이트를 누가 운영하는지에 혼란이 생길 이유가 없다. 그런데도 정상 사이트를 사기 사이트와 구분할 수 없게 만드는 관행이 사실상 표준처럼 굳어졌다. 정부 기관조차 자신에게 할당된 TLD를 일관되게 사용하지 않는다는 지적이 나오고, 글 말미에는 FedEx 사례를 다룬 트로이 헌트의 글 링크가 붙어 있다. 상황이 이 지경에 이르자 서브도메인이라는 개념 자체가 범죄자에게 아무런 감독 없이 타인을 사칭할 도구를 준다며 없애야 한다는 주장까지 등장했다.
개발자에게 이 글은 OAuth·SSO 리다이렉트 체인 설계 문제로 직결된다. 인증 화면이 자사 루트 도메인 하위에 있는지, 외부 IdP를 쓴다면 커스텀 도메인을 붙일 수 있는지, 이메일·SMS 템플릿의 링크가 자사 도메인을 거치는지, 토큰 만료 팝업이 어느 도메인에서 뜨는지를 확인해야 한다. 이런 요소는 개별 기능이 아니라 사용자가 "정상"이라고 학습하는 패턴을 형성한다는 점이 핵심이다. 정상 흐름이 사기처럼 보이면 아무리 좋은 경고 문구를 넣어도 효과가 없다.
다만 이 글은 개인적인 불만(rant) 형식의 제안이며, 표준 문서나 벤더의 공식 권고가 아니다. 레거시 IdP나 여러 SaaS를 조합한 환경에서는 도메인 체계를 즉시 바꾸기 어렵다는 현실적 제약도 있다. 원문 역시 URL이 직관적이지 않다는 점을 인정하고, 사용자 교육만으로는 부족하다는 전제 위에서 논의를 전개한다.