클릭 한 번에 GitHub 토큰이 털린다 — VSCode 버그로 본 OAuth와 URI 핸들러의 함정

무슨 일이 있었냐면

한 보안 연구자가 VSCode의 버그를 이용해서 링크 클릭 한 번(1-Click)으로 사용자의 GitHub 토큰을 훔칠 수 있는 취약점을 발견하고 공개했어요. 토큰이 뭔지부터 짚고 갈게요. GitHub 토큰은 비밀번호 대신 쓰는 "열쇠"예요. 이게 있으면 그 사람 계정으로 코드를 읽고, 쓰고, 비공개 저장소까지 접근할 수 있거든요. 그러니까 이게 털린다는 건 비밀번호가 털리는 것과 거의 같은, 아주 심각한 사고예요.

무서운 건 사용자가 뭔가 수상한 파일을 받거나 명령어를 실행한 게 아니라, 그냥 링크 하나를 클릭했을 뿐인데 토큰이 공격자에게 넘어갈 수 있었다는 점이에요.

어떻게 가능했냐면

핵심은 vscode:// 같은 커스텀 URI 핸들러예요. 이게 뭐냐면, 웹 브라우저에서 https://를 누르면 브라우저가 열리듯이, vscode:// 로 시작하는 링크를 누르면 운영체제가 "아 이건 VSCode가 처리할 일이네" 하고 VSCode 앱을 깨워서 넘겨주는 구조예요. 확장 프로그램 설치나 OAuth 로그인 완료 같은 걸 매끄럽게 처리하려고 만든 편리한 기능이죠.

문제는 OAuth 로그인 흐름이랑 엮였을 때예요. GitHub로 로그인할 때 보통 이런 순서로 돌아가요. 브라우저에서 GitHub에 로그인 → GitHub가 임시 인증 코드(code)를 발급 → 그 코드를 다시 앱(VSCode)으로 돌려줌 → VSCode가 그 코드를 진짜 토큰으로 교환. 이때 "코드를 다시 앱으로 돌려주는" 그 통로가 바로 vscode:// URI 핸들러였어요.

공격자는 이 흐름의 약한 고리를 노렸어요. 보통 OAuth에는 state라는 "내가 시작한 요청이 맞는지 확인하는 일회용 표식"이 있어야 위조 요청을 막을 수 있는데, 이 검증이 허술하거나, 핸들러가 어떤 출처에서 온 콜백인지 제대로 확인하지 않으면, 공격자가 미리 만들어둔 악성 링크로 인증 흐름을 가로채거나 자기 쪽으로 코드를 흘려보낼 수 있게 돼요. 결과적으로 피해자가 무심코 누른 링크가 인증 코드 또는 토큰을 공격자 손에 쥐여주게 되는 거죠. 연구자는 이 과정을 단계별로 재현해서 "1-Click"이면 충분하다는 걸 보여줬어요.

업계 맥락

사실 커스텀 URI 핸들러를 노린 공격은 새로운 카테고리는 아니에요. 데스크톱 앱이 늘어나면서 slack://, zoommtg://, vscode:// 같은 핸들러가 많아졌고, 그만큼 "누가 이 링크를 보냈는지", "이 콜백이 진짜 우리가 시작한 흐름의 응답인지" 검증을 빠뜨리는 사고가 반복됐거든요. OAuth 표준이 PKCE(코드 가로채기를 막는 추가 절차)나 엄격한 redirect_uri 검증, state 검증을 권하는 이유가 바로 이런 공격을 막기 위해서예요.

VSCode처럼 수백만 개발자가 쓰고, 확장 생태계가 거대한 도구일수록 이런 취약점의 파급력이 커요. 개발자 한 명의 토큰이 털리면 그 사람이 접근하던 회사 비공개 저장소까지 위험해지니까요.

한국 개발자에게 주는 시사점

앱을 만들면서 OAuth를 직접 붙이는 분들이라면 체크리스트가 분명해요. 첫째, state 값을 반드시 생성하고 콜백에서 검증하세요. 둘째, 가능하면 PKCE를 적용하세요. 셋째, 커스텀 URI로 들어온 데이터는 "외부에서 온 신뢰할 수 없는 입력"으로 간주하고, 어떤 콜백인지·예상한 흐름이 맞는지 꼼꼼히 확인하세요.

사용자 입장에서도 교훈이 있어요. 출처가 불분명한 vscode://, cursor:// 같은 앱 실행 링크는 누르기 전에 한 번 의심하는 습관이 필요하고, VSCode와 확장 프로그램은 보안 패치가 나오면 미루지 말고 바로 업데이트하는 게 최선의 방어예요.

마무리

한 줄 정리하면, "편리하라고 만든 딥링크가 검증을 빠뜨리면 그대로 공격 통로가 된다"예요. 여러분은 직접 만든 서비스의 OAuth 콜백에서 state와 redirect_uri를 제대로 검증하고 계신가요? 혹시 "일단 동작하니까" 하고 넘긴 인증 흐름이 있진 않나요?