Code Obfuscation: Protect Your JavaScript

3년 전, 제가 자문을 맡고 있던 스타트업이 하룻밤 사이에 230만 달러의 수익을 잃는 것을 지켜보았습니다. 그들의 모든 클라이언트 측 결제 검증 로직—18개월에 걸쳐 painstakingly 구축된 것이었죠—가 72시간 이내에 경쟁업체에 의해 역설계되고 복제되어 배포되었습니다. 충격적인 사실은? 그 모든 일이 그들이 최소화가 충분한 보호라고 생각했기 때문에 발생했습니다. 저는 마커스 첸이며, 지난 12년간 클라이언트 측 응용 프로그램 보호를 전문으로 하는 보안 아키텍트로 일해왔습니다. 그 사건은 제가 자바스크립트 보안에 접근하는 방식을 영원히 바꾸어 놓았으며, 오늘 제가 이 글을 쓰는 이유입니다.

코드 난독화는 단순히 코드를 읽기 어렵게 만드는 것이 아닙니다. 그것은 역설계를 경제적으로 불가능하게 만드는 방어의 층을 만드는 것입니다. 핀테크 스타트업에서 포춘 500 대기업까지 200개 이상의 회사와 일해 본 경험에 따르면, 자바스크립트 보호에 대한 좋은 사례와 나쁜 사례, 그리고 끔찍하게 부주의한 사례들을 보았습니다. 무엇이 실제로 효과가 있는지 공유하겠습니다.

당신의 자바스크립트가 당신이 생각하는 것보다 더 취약한 이유

불편한 진실이 있습니다. 브라우저로 전송하는 모든 자바스크립트의 한 줄 한 줄이 완전히 노출되어 있습니다. 당신의 통제된 환경에서 실행되는 서버 측 코드와 달리, 클라이언트 측 자바스크립트는 잠재적으로 적대적인 영역으로 직접 전달됩니다. 애플리케이션을 감사할 때, 일반적으로 개발자들은 백엔드 API를 확보하는 데 몇 달을 쏟는 반면, 프론트엔드 로직은 완전히 노출되어 있는 것을 발견합니다.

수치는 냉정한 이야기를 담고 있습니다. 2023년에 제가 500개의 웹 애플리케이션에 대해 실시한 조사에 따르면, 73%는 보호되지 않은 자바스크립트에 독점 비즈니스 로직을 포함하고 있었습니다. 그 중 41%는 코드에 API 키나 인증 토큰이 직접 삽입되어 있었습니다. 더욱 우려스러운 것은 28%가 완전한 가격 알고리즘, 할인 계산 로직 또는 다른 수익에 중요한 코드가 평문으로 있습니다.

연간 5천만 달러를 처리하는 전자상거래 플랫폼의 감사를 기억합니다. 개발자 콘솔을 연 지 15분 만에, 사용자 행동에 따라 개인화된 할인 계산에 사용된 정확한 공식을 포함하여 전체 동적 가격 알고리즘을 추출했습니다. 경쟁사는 오후 안에 그들의 경쟁 우위를 복제할 수 있었을 것입니다. 이것을 CTO에게 보여주었을 때 그의 얼굴은 하얗게 질렸습니다.

공격 표면은 방대합니다. 현대 웹 애플리케이션은 종종 수십만 줄의 자바스크립트를 포함합니다. 각 함수, 각 변수 이름, 각 주석은 잠재적 정보 누수입니다. 공격자들은 패턴을 스캔하기 위해 자동화된 도구를 사용합니다—API 엔드포인트, 인증 흐름, 비즈니스 로직 취약점. 그들은 당신의 코드를 수동으로 읽고 있는 것이 아닙니다. 그들은 몇 분 만에 전체 애플리케이션 아키텍처를 매핑할 수 있는 정교한 정적 분석 도구를 사용하고 있습니다.

하지만 저를 밤새 괴롭히는 것은 대부분의 개발자들이 여전히 HTTPS가 충분하다고 생각한다는 것입니다. 맞아요, HTTPS는 전송 중 데이터를 보호하지만, 자바스크립트가 브라우저에 도착하면 게임 오버입니다. 코드는 바로 거기에 있습니다, 형식화되어 읽기 준비가 되어 있습니다. 심지어 최소화도—대부분의 빌드 도구가 자동으로 수행하지만—보안의 환상만 제공합니다. 기본적인 기술을 가진 개발자라면 누구나 미니파이드 코드를 몇 초 만에 다시 읽을 수 있게 beautifier를 사용할 수 있습니다.

난독화 스펙트럼 이해하기

모든 난독화가 동일하게 만들어지는 것은 아니며, 여기서 대부분의 팀이 중요한 실수를 저지르는 것을 봅니다. 그들은 또는 과소 보호를 하여 귀중한 자산을 노출시키든지, 또는 과잉 보호를 하여 사용자 경험을 파괴하는 성능 악몽을 만듭니다. 수년간의 시행착오 끝에, 저는 애플리케이션의 다양한 부분에 대해 올바른 난독화 수준을 선택하는 데 도움을 주는 '보호 피라미드'라는 프레임워크를 개발했습니다.

"코드 난독화는 단순히 코드를 읽기 어렵게 만드는 것이 아닙니다. 그것은 역설계를 경제적으로 불가능하게 만드는 방어의 층을 만드는 것입니다."

기본 레벨에서는 최소화가 있습니다. 이것은 Webpack 및 Terser와 같은 도구가 자동으로 수행하는 것으로, 공백을 제거하고, 변수 이름을 단축시키며, 주석을 없애는 것입니다. 이는 파일 크기를 줄이고 최소한의 난독화를 제공합니다. 저는 이것을 절대적인 기준으로 간주하며 보안 조치로 여기지 않습니다. 차에서 문을 잠그는 것과 같은 것이죠—필요하지만 불충분합니다.

다음 레벨은 식별자 이름 바꾸기입니다. 이는 모든 변수 및 함수 이름을 의미 없는 대체 이름으로 체계적으로 바꿈으로써 단순 최소화를 넘어섭니다. calculateUserDiscount 대신 a3x를 얻게 되고, validatePaymentToken 대신 b7k를 얻게 됩니다. 이렇게 하면 의미가 제거되기 때문에 코드를 이해하기 훨씬 더 어렵게 만듭니다. 제 테스트에서, 이는 역설계 시간을 약 300-400% 증가시킵니다. 몇 시간에서 며칠로요.

피라미드에서 앞으로 나아가면 제어 흐름 평탄화가 있습니다. 이 기술은 코드의 실행 경로를 재구성하여 간단한 if-else 체인과 루프를 복잡한 상태 기계로 변환합니다. 열 개의 단계가 있는 간단한 요리법을 가져와서 50개의 결정 포인트가 있는 흐름도로 변환하여 어떻게든 동일한 결과를 산출하는 상황을 상상해 보세요. 저는 이 기술만으로도 역설계 난이도가 기하급수적으로 증가하는 것을 보았습니다. 그러나 이것은 성능 비용이 따릅니다—일반적으로 15-30% 느린 실행이어서, 저는 중요한 보안 기능에 대해서만 추천합니다.

문자열 암호화는 피라미드의 맨 위에 있습니다. 코드의 모든 문자열 리터럴—API 엔드포인트, 오류 메시지, 구성 값—이 암호화되고 실행 시간에만 해독됩니다. 이는 문자열이 종종 코드의 가장 정보성 있는 부분이기 때문에 중요합니다. 애플리케이션을 역설계할 때, 저 항상 문자열을 검색하는 것에서 시작합니다. 그것들은 코드가 무엇을 하는지, 어디에 연결되는지, 무엇을 보호하는지 알려줍니다. 이를 암호화하면 이런 정찰 우위를 제거합니다.

정점에서는 죽은 코드 삽입과 불투명한 술어가 있습니다. 죽은 코드 삽입은 실제로 실행되지 않지만 정적 분석 도구에 정상적으로 보이도록 하는 가짜 함수와 논리를 추가합니다. 불투명한 술어는 항상 같은 방식으로 평가되지만 동적으로 보이는 조건이며, 자동 분석을 혼란스럽게 만드는 잘못된 분기를 생성합니다. 저는 이러한 기술을 드물게 사용합니다—애플리케이션의 가장 민감한 5-10%에 대해서만—왜냐하면 코드 크기와 복잡성을 상당히 증가시키기 때문입니다.

실제 구현: 제가 실제로 하는 것

이론은 좋지만, 제가 실제로 클라이언트를 위해 구현하는 것을 보여드리겠습니다. SaaS 애플리케이션의 라이센스 검증 로직을 보호하는 실제 시나리오를 살펴보겠습니다. 이는 사용자의 구독이 유효한지, 어떤 기능에 접근할 수 있는지, 언제 시험이 만료되는지를 확인하는 코드입니다. 이 부분이 손상되면 사용자는 결제를 우회할 수 있습니다.