웹 보안은 왜 이렇게 어려운가
웹 보안의 어려움은 단순히 기술적 복잡성에서 오지 않는다. 오히려 정상적인 UX와 공격 패턴이 너무나 닮아 있다는 점에서 비롯된다. 최근 Cloudflare의 신규 서비스 출시 과정에서 발생한 사례는 이 문제를 적나라하게 보여준다. 사용자가 공식 트윗을 통해 서비스를 접하고, 로그인을 완료한 뒤 OAuth 권한 동의 화면을 마주했을 때 — 이것이 진짜 서비스인지, 정교한 피싱 공격인지 구분하기가 극도로 어려웠다.
이 사례에서 의심을 유발한 요소는 여러 가지였다. 진입점이 기존 계정이 연동된 cloudflare.com이 아니라 cloudflare.pay라는 낯선 도메인이었고, .pay sTLD는 단 $20에 누구나 등록 가능한 도메인이었다. 권한 동의 화면의 녹색 체크마크 이모지는 신뢰를 암시하는 시각적 장치처럼 보였지만, 공격자도 동일한 이모지를 앱 이름에 삽입해 신뢰감을 위장할 수 있다. Microsoft 계정을 노린 OAuth 피싱에서도 동일한 수법이 반복적으로 관찰된다.
Consent Phishing과 도메인 신뢰의 함정
Consent Phishing은 OAuth 권한 동의 흐름을 악용하는 공격 방식이다. 사용자가 정상적인 OAuth 화면처럼 보이는 페이지에서 "허용"을 클릭하는 순간, 공격자의 앱이 이메일·캘린더·파일 등 민감한 리소스에 대한 접근 권한을 획득한다. 비밀번호를 탈취하지 않아도 되기 때문에 MFA(다중 인증)를 우회할 수 있다는 점에서 최근 몇 년간 급격히 증가했다.
도메인 신뢰 문제도 핵심이다. 사용자는 흔히 같은 회사라면 도메인도 연관되어 있을 것이라 기대한다. 그러나 .com과 .pay는 기술적으로 아무런 관계가 없다. 백엔드 개발자 입장에서도 서비스 설계 시 신규 도메인 도입이 사용자에게 어떤 신호를 주는지 반드시 고려해야 한다. 기존 신뢰 도메인 내에서 경로로 분리(cloudflare.com/pay)하는 방식이 훨씬 안전하고 명확한 선택이다.
실무에서 적용할 수 있는 보안 원칙
이 사례는 서비스를 설계하는 개발자에게도 직접적인 교훈을 준다.
- OAuth/Permission 화면은 반드시 기존 신뢰 도메인에서 제공하라. 신규 도메인으로 인증 플로우를 분리하면 사용자에게 불필요한 의심과 혼란을 준다.
- 앱 이름과 아이콘에 대한 검증 로직을 강화하라. 이모지나 유사 문자를 이용한 위장 앱 등록을 방지하는 서버사이드 필터링이 필요하다.
- 긴박감(urgency)을 유발하는 UX는 피싱과 구분이 어렵다. "지금 당장 신청하지 않으면 놓친다"는 식의 UX는 사용자의 보안 판단력을 약화시킨다.
// OAuth 앱 등록 시 display_name 검증 예시
private void validateAppDisplayName(String displayName) {
if (displayName.codePoints().anyMatch(cp -> cp > 0xFFFF)) {
throw new IllegalArgumentException("이모지 또는 특수문자 포함 앱 이름은 허용되지 않습니다.");
}
}
권한 동의 화면을 직접 구현하는 경우라면, 앱의 출처·권한 범위·요청 이유를 명확하게 표시하고 사용자가 충분히 검토할 수 있는 시간적 여유를 UX에 설계해야 한다.
정리
.pay,.app등 새로운 sTLD는 누구나 저렴하게 등록 가능하므로, 인증·결제 플로우는 기존 신뢰 도메인 내 경로로 유지하는 것이 원칙이다.- Consent Phishing은 MFA를 우회하고 OAuth 권한 탈취로 이어질 수 있으므로, 앱 등록 및 권한 동의 화면 설계에 서버사이드 검증을 반드시 포함해야 한다.
- 정상적인 서비스 UX와 피싱 패턴이 구분되지 않을 때 보안은 무너진다 — 개발자는 "사용자가 이 화면을 의심할 수 있는가"를 설계 단계에서 스스로 물어야 한다.