보안 도구 Fiddler를 만든 개발자이자 마이크로소프트 디펜더 팀에서 일하는 에릭 로런스(Eric Lawrence)가 겪은 일은 웹 보안의 근본적인 딜레마를 압축해서 보여준다. 그는 평소 즐겨 쓰던 클라우드플레어의 새 제품 출시 소식을 트위터에서 접하고 링크를 눌렀다. 마침 자신이 원하던 아이디 '@ericlaw'가 아직 비어 있었고, 남에게 선점당하기 전에 서둘러 확보해야 한다는 조급함이 밀려왔다. 로그인을 마치자 새 기능 사용을 '승인(authorize)'하라는 화면이 떴다. 그런데 이 흐름은 지난 몇 년간 기승을 부린 '동의 피싱(Consent Phishing)' 공격과 판박이였다.
정상 서비스가 왜 피싱처럼 보였나
의심을 키운 결정적 단서는 도메인이었다. 진입점이 이미 자신의 자격 증명을 보유한 cloudflare.com이 아니라, 자격 증명이 전혀 없는 cloudflare.pay였다. 로런스가 지적하듯 .com 도메인과 .pay 도메인 사이에는 어떤 기술적 소속 관계도 존재하지 않는다. .pay 최상위 도메인은 20달러만 있으면 누구나 등록할 수 있어, 공격자가 몇 분 만에 cloudflarepayments.pay 같은 그럴듯한 주소를 만들 수 있다. 이는 엄격한 심사를 요구하는 .bank 도메인과 대비된다. 게다가 클라우드플레어의 권한 승인 페이지는 정작 자사의 신규 기능을 스스로 인식하지 못했고, 신뢰를 표시하려던 초록색 체크마크는 오히려 수상해 보였다. 마이크로소프트 계정을 노리는 공격자가 앱 표시 이름과 아이콘을 그럴싸하게 꾸미듯, 그 이모지 역시 조작된 표시 이름의 일부처럼 보였기 때문이다.
피해자가 이상 신호를 감지해도 대응할 통로가 없었다는 점도 문제였다. 승인 페이지에는 '의심스러운 요청 신고' 링크가 없어, 그는 자신이 판단한 '공격'을 클라우드플레어에 알릴 방법이 마땅치 않았다. 대시보드로 돌아가 Wallet 기능을 찾았지만 사이드바에도, 공식 문서 검색에도 나오지 않았다. 결국 그는 사이트에 붙은 AI 챗봇 에이전트에게 물었다.
AI 에이전트도 최소 권한 원칙을 어겼다
여기서 또 다른 허점이 드러난다. 챗봇은 질문에 답하기 전 계정 접근 권한부터 요구했고, 그것도 읽기 전용이 아니라 전체 제어 권한을 먼저 제안했다. 계정별 정보가 필요 없는 단순 질문에조차 과도한 권한을 요구한 것은 최소 권한 원칙(Principle of Least Privilege)의 명백한 위반이다. 읽기 권한만 부여한 뒤 질문하자, AI는 '이것은 정말로 공격'이라고 답했다. 그는 즉시 피싱을 신고하려 했다.
그러나 몇 분간 더 뒤진 끝에 반전이 확인됐다. 이 모든 것은 실제로 존재하는 클라우드플레어의 정식 신제품이자 합법적인 사이트였다. 수상하게 보였던 초록 체크마크는 조작된 이름의 일부가 아니라, 사용자가 마우스를 올리면 보안 세부 정보가 뜨도록 설계된 UI 요소였다. 다만 배치가 잘못돼 오해를 샀을 뿐이다. 보안 문제 신고는 해커원(HackerOne)을 통하도록 안내됐지만, 정작 로그인 과정의 클라우드플레어 CAPTCHA가 작동하지 않아 그마저도 막혔다. 사내 보안에 정통한 회사가 만든 서비스가 피싱의 모든 조건을 갖추고 있었던 셈이다.
실무자가 새겨야 할 지점
이 사례의 가치는 특정 회사를 비난하는 데 있지 않다. 정상 서비스가 이토록 피싱처럼 보일 수 있다면, 매주 수백만 개의 새 사이트가 생겨나는 환경에서 마이크로소프트 스마트스크린이나 구글 세이프브라우징 같은 URL 평판 서비스가 오탐 없이 악성 사이트만 걸러내는 일이 얼마나 어려운지 짐작할 수 있다. 정상과 공격의 경계가 흐릿하면, 자동화된 차단 시스템도 사람도 판단할 근거를 잃는다.
실무 관점에서 되짚을 지점은 분명하다. 신뢰가 필요한 진입점은 이미 자격 증명을 보유한 신뢰 도메인 안에 두고, 저렴하게 취득 가능한 별도 sTLD에 흩어 놓지 말아야 한다. 보안을 나타내는 UI 요소는 조작 가능한 표시 문자열과 시각적으로 구분되도록 배치해야 하며, 승인 페이지에는 '의심스러운 요청 신고' 경로를 반드시 마련해야 한다. AI 에이전트를 붙일 때도 작업에 필요한 최소 권한만 요구하도록 기본값을 설계하는 것이 옳다. 로런스가 개발자에게는 모든 모범 사례를 지켜 달라 호소하고, 사용자에게는 클릭 전에 생각하고 정 안 되면 기다리라 조언하며, 보안 담당자에게는 피해자를 탓하지 말라고 당부한 이유가 여기에 있다. 사용자에게 진짜와 가짜를 육안으로 구별하라는 요구는 사실상 불가능한 과제이기 때문이다.