An Analysis of Modern Web Security Vulnerabilities Inside WebAssembly Applications

이 논문은 웹어셈블리 (WASM) 모듈 내의 바이너리 취약점이 웹 애플리케이션의 보안 메커니즘을 무력화하여 SQL 주입이나 XS-Leaks 와 같은 웹 보안 위협으로 이어질 수 있음을 증명하고, 이를 완화하기 위한 최선의 실천 방안과 방어 전략을 제시합니다.

핵심

이 논문은 **"웹어셈블리 (WebAssembly, WASM)"**라는 최신 웹 기술이 가진 숨겨진 위험에 대해 경고하는 연구입니다.

쉽게 비유하자면, 이 논문은 **"웹사이트에 '초고속 엔진'을 달았더니, 그 엔진이 고장 나면서 차 전체가 불타버리는 일이 생길 수 있다"**는 이야기입니다.

자세한 내용을 일상적인 언어와 비유로 설명해 드릴게요.

---

1. 배경: 왜 웹어셈블리 (WASM) 가 필요한가요?

과거 웹사이트는 '자바스크립트'라는 언어로만 만들었습니다. 하지만 자바스크립트는 무거운 작업 (예: 3D 게임, 고화질 영상 편집) 을 할 때 조금 느립니다.
그래서 개발자들은 C 나 C++ 같은 강력한 언어로 만든 프로그램을 웹사이트에서도 바로 실행할 수 있게 만들었는데, 이것이 바로 **웹어셈블리 (WASM)**입니다.

• 비유: 웹사이트를 '택시'라고 생각해보세요. 자바스크립트는 일반 택시이고, WASM 은 '포뮬러 1 레이싱카'입니다. 레이싱카는 훨씬 빠르고 강력하지만, 조금만 잘못 다루면 큰 사고가 납니다.

2. 문제: 레이싱카의 치명적인 결함

이 논문은 레이싱카 (WASM) 가 가진 치명적인 약점을 지적합니다. WASM 은 원래 C/C++ 언어로 만들어졌기 때문에, **기존의 C/C++ 프로그램이 가진 '고장 (버그)'**을 그대로 가지고 옵니다.

• 주요 고장 유형:
  • 버퍼 오버플로우 (Buffer Overflow): 물통에 물을 너무 많이 부으면 넘쳐서 바닥을 적십니다. 프로그램도 메모리 공간보다 많은 데이터를 넣으면, 옆에 있는 중요한 데이터까지 덮어씌웁니다.
  • Use After Free (사용 후 해제): 쓰레기통에 버린 쓰레기를 다시 꺼내 쓰는 것 같습니다. 메모리를 비운 뒤에도 그 주소를 계속 쓰려고 하면, 그 자리에 다른 쓰레기 (해커의 악성 코드) 가 들어와서 엉뚱한 일이 일어납니다.

3. 핵심 발견: "엔진 고장이 차 전체를 망친다"

기존에는 "WASM 이 고장 나면 WASM 안에서만 문제가 생기겠지?"라고 생각했습니다. 하지만 이 논문은 WASM 의 고장이 웹사이트 전체를 해치는 새로운 방식을 발견했습니다.

해커는 WASM 의 고장을 이용해 웹사이트를 공격합니다. 마치 레이싱카의 브레이크가 고장 나서, 그 충격으로 차 안의 운전석 (웹사이트) 을 파괴하는 것과 같습니다.

구체적인 공격 사례 3 가지:

① SQL 주입 (데이터베이스 해킹)

• 상황: 웹사이트는 "이름을 입력하세요"라고 물어봅니다. WASM 은 이 이름을 데이터베이스에 저장합니다.
• 공격: WASM 내부의 메모리 고장을 이용해, "이름"을 저장하는 공간에 "비밀번호를 모두 삭제해라"라는 명령을 덮어씁니다.
• 결과: 웹사이트는 "안전하게 준비된 명령"을 실행한다고 믿고 있지만, 실제로는 해커가 명령을 바꿔치기한 것입니다. 안전장치가 무용지물이 됩니다.

② 서버 측 템플릿 주입 (SSTI - 서버 장악)

• 상황: WASM 이 "안전한 인증 번호 (Nonce)"를 만들어 웹사이트에 보냅니다. 웹사이트는 이 번호를 믿고 HTML 을 만듭니다.
• 공격: 해커는 WASM 의 메모리 고장을 이용해, 그 인증 번호 자리에 "서버를 해킹하는 코드"를 심어둡니다.
• 결과: 웹사이트는 "안전한 번호"라고 믿고 그 코드를 실행해버립니다. 웹사이트가 해커의 손에 넘어갑니다.

③ XS-Leaks (시간을 이용한 정보 탈취)

• 상황: 해커는 직접 데이터를 훔쳐볼 수 없습니다. 하지만 WASM 이 특정 작업을 할 때 걸리는 '시간'을 재면 됩니다.
• 공격: 해커는 WASM 에 "특정 패턴을 찾아라"라는 복잡한 명령을 보냅니다. 만약 비밀번호가 맞으면 WASM 이 더 오래 걸립니다.
• 결과: 해커는 "아, 0.5 초 걸렸네? 비밀번호 앞글자가 'A'구나"라고 추측합니다. 시간 차이를 이용해 비밀번호를 하나씩 알아냅니다.

4. 결론 및 해결책: 어떻게 방어할까요?

이 논문은 **"WASM 이라고 해서 완전히 안전하다고 생각하면 안 된다"**고 말합니다. WASM 은 C/C++ 의 위험한 버그를 그대로 물려받기 때문입니다.

개발자를 위한 조언 (방어 전략):

1. 신뢰하지 마세요: 자바스크립트와 WASM 이 데이터를 주고받을 때, "이 데이터가 안전할 거야"라고 믿지 말고 반드시 다시 검사하세요. (예: 숫자가 너무 크지 않은지, 글자 수가 너무 많지 않은지)
2. 문제를 미리 잡으세요: 프로그램을 만들 때 (컴파일할 때), 고장을 미리 잡아주는 도구들을 켜두세요. 속도가 조금 느려질 수 있지만, 해킹 위험은 훨씬 줄어듭니다.
3. 최소한의 권한: WASM 이 웹사이트와 대화할 수 있는 창구 (인터페이스) 를 최소한으로 줄이세요. 문이 적을수록 해커가 들어올 틈이 적습니다.

요약

이 논문은 **"빠른 속도 (WASM) 를 쫓다가, 안전장치 (보안) 를 잃어버리면 큰일 난다"**는 교훈을 줍니다.
웹어셈블리는 강력한 도구이지만, 개발자들은 그것이 가진 '고장 난 엔진'의 위험성을 인지하고, 웹사이트 전체를 보호하기 위한 이중, 삼중의 안전장치를 마련해야 한다고 강조합니다.

기술 요약

1. 문제 제기 (Problem Statement)

WebAssembly (WASM) 는 Figma, Google Earth 등 고성능 웹 애플리케이션의 핵심 기술로 빠르게 확산되고 있습니다. WASM 은 C, C++ 등의 언어로 작성된 코드를 웹 환경에서 네이티브에 가까운 속도로 실행할 수 있게 하지만, 기존의 저수준 메모리 보호 메커니즘 (스택 캐나리, ASLR, 안전한 unlinking 등) 이 부재하다는 치명적인 약점이 있습니다.

기존 연구들은 WASM 바이너리 자체의 취약점 (버퍼 오버플로우, Use-After-Free 등) 을 분석했으나, 이러한 저수준 바이너리 취약점이 어떻게 고수준 웹 애플리케이션의 보안 위협 (SQL 인젝션, XSS 등) 으로 전이되는지에 대한 연구는 부족했습니다. 본 논문은 WASM 모듈 내의 메모리 안전성 결함이 웹 레이어의 공격 벡터로 악용될 수 있음을 증명하고, 이를 통해 기존 웹 보안 방어 기법들이 무력화될 수 있음을 보여줍니다.

2. 연구 방법론 (Methodology)

저자들은 바이너리 취약점과 웹 보안 취약점 간의 인과관계를 입증하기 위해 다음과 같은 방법론을 사용했습니다.

• 취약점 분류 및 매핑:
  • 바이너리 취약점: 임의 쓰기 (Arbitrary Write), 임의 읽기 (Arbitrary Read) 원시 기능을 제공하는 4 가지 취약점 선정 (스택 기반 버퍼 오버플로우, Use-After-Free, 정수 오버플로우, 제어되지 않은 포맷 문자열).
  • 웹 보안 취약점: WASM 모듈의 출력물이 웹 애플리케이션에 어떻게 영향을 미치는지에 따라 분류.
    • 직접/연쇄 (Direct/Chained): WASM 출력물이 웹 실행 흐름에 직접 포함되는지 여부.
    • 블라인드/논블라인드 (Blind/Not-blind): 공격 성공 여부를 직접적인 출력으로 확인 가능한지, 또는 사이드 채널 (타이밍) 로 추론해야 하는지.
• PoC (Proof of Concept) 구축:
  • C 로 작성된 취약한 WASM 모듈을 Emscripten 으로 컴파일하여 Node.js/Express 기반의 웹 애플리케이션에 통합했습니다.
  • 시나리오 1 (SQL Injection): WASM 내 버퍼 오버플로우 등을 통해 쿼리 문자열을 조작하여 SQL 인젝션 발생.
  • 시나리오 2 (SSTI): WASM 이 생성한 토큰 (nonce) 을 템플릿 엔진이 신뢰하여 템플릿 주입 (SSTI) 발생.
  • 시나리오 3 (XS-Leaks): ReDoS(Regular Expression Denial of Service) 패턴을 주입하여 응답 시간 차이를 측정, 민감한 정보 유출.
• 재현성 확보: 모든 PoC 코드, 스크립트, Docker 컨테이너를 공개하여 연구 결과의 재현성을 보장했습니다.

3. 주요 기여 (Key Contributions)

1. 바이너리 취약점의 웹 레이어 전이 분석: 메모리 안전성 결함 (버퍼 오버플로우, UAF 등) 이 어떻게 SQLi, SSTI, XS-Leaks 와 같은 웹 공격으로 이어지는지 구체적인 시나리오를 제시했습니다.
2. 재현 가능한 연구 방법론 제안: 바이너리 버그를 웹 레이어 영향과 연결하는 체계적인 방법론 (취약점 선정, PoC 구축, 익스플로잇 자동화, 영향도 평가) 을 정립했습니다.
3. 구체적인 공격 시나리오 및 PoC 공개:
   • 버퍼 오버플로우를 통한 SQL 쿼리 조작.
   • WASM 출력물을 신뢰하는 템플릿 엔진을 통한 SSTI.
   • WASM VM 의 격리성을 우회한 ReDoS 기반 XS-Leaks.
4. 실무적 방어 전략 제시: 개발자가 WASM 모듈을 안전하게 통합하기 위한 컴파일러 옵션, 런타임 강화, 인터페이스 검증 등의 구체적인 가이드라인을 제공했습니다.

4. 실험 결과 및 발견 (Results & Findings)

4.1 SQL Injection (SQLi)

• 발견: WASM 모듈 내에서 버퍼 오버플로우가 발생하면, 준비된 문장 (Prepared Statements) 을 우회하여 SQL 쿼리 자체를 조작할 수 있습니다.
• 메커니즘:
  • 버퍼 오버플로우: 스택에 있는 쿼리 문자열 변수를 인접 버퍼로 덮어써 악성 쿼리로 변경.
  • 정수 오버플로우: JS(64-bit) 와 C(32-bit) 의 정수 크기 불일치를 이용해, JS 에서 유효한 ID 가 WASM 에서는 0 으로 오버플로우되어 접근 제한된 데이터를 조회.
  • UAF: 해제된 메모리를 재할당하여 쿼리 문자열을 악성 코드로 교체.

4.2 Server-Side Template Injection (SSTI)

• 발견: WASM 모듈이 생성한 데이터 (예: nonce) 를 웹 애플리케이션이 '신뢰할 수 있는 데이터'로 간주할 때, 바이너리 취약점으로 인해 템플릿 주입이 발생합니다.
• 메커니즘: 버퍼 오버플로우나 UAF 를 통해 WASM 내부의 'nonce' 변수를 템플릿 구문 (예: #{7*7}) 으로 덮어쓰면, 웹 서버가 이를 실행 가능한 코드로 해석하여 임의 코드 실행 (ACE) 을 유도합니다.

4.3 XS-Leaks (Cross-Site Leaks)

• 발견: WASM 내부의 민감한 데이터 (비밀번호 등) 를 직접 읽지 못하더라도, **응답 시간 (Timing Attack)**을 측정하여 정보를 유출할 수 있습니다.
• 메커니즘:
  • WASM 내의 검색 패턴 변수를 버퍼 오버플로우나 UAF 를 통해 악성 ReDoS 정규식 (예: ^secret_prefix(.+){21}) 으로 변경.
  • 공격자가 특정 패턴으로 검색을 요청할 때, 정규식 엔진이 복잡한 매칭을 시도하며 발생하는 지연 시간을 측정하여 사용자의 비밀 데이터가 해당 패턴으로 시작하는지 추론.
• 한계: 포맷 문자열 공격은 PCRE2 엔진의 불안정성으로 인해 ReDoS 공격에 실패했으나, 버퍼 오버플로우와 UAF 는 성공적으로 XS-Leaks 를 유발했습니다.

4.4 공격 난이도 비교

• 버퍼 오버플로우: 상대적으로 쉬움. 소스 코드 없이도 버퍼 크기를 추론하여 공격 가능.
• UAF: 난이도 중간. 힙 쉐이핑 (Heap Shaping) 이 필요하지만 가능.
• 제어되지 않은 포맷 문자열: 난이도 매우 높음. 정확한 메모리 주소와 많은 전제 조건이 필요하며, WASM 환경에서는 실행 중 크래시가 빈번함.

5. 의의 및 결론 (Significance & Conclusion)

• WASM 보안의 새로운 위협 인식: WASM 이 단순히 "안전한 샌드박스"가 아니라, C/C++ 의 메모리 취약점을 그대로 웹 애플리케이션으로 가져오는 경로가 될 수 있음을 경고합니다.
• 기존 방어 기법의 한계: 준비된 문장 (Prepared Statements) 이나 표준 웹 보안 정책 (SOP 등) 만으로는 WASM 내부의 바이너리 취약점으로 인한 공격을 막을 수 없습니다.
• 권장 방어 전략:
  1. JS-WASM 경계 검증: 두 환경 간 데이터 교환 시 타입, 범위, 문자열 길이를 엄격히 검증 (Sanitization).
  2. 인터페이스 최소화: WASM 모듈이 웹에 노출하는 함수와 메모리 영역을 최소화.
  3. 컴파일러/런타임 강화: Emscripten 등의 도구를 이용해 스택 smashing 감지, 범위 초과 검사, UAF 방지 기능을 활성화 (성능 저하 감수).
  4. 레이어드 방어: 입력 검증, 컴파일러 강화, 런타임 감시를 결합한 다층 방어 체계 구축.

결론적으로, 본 논문은 WASM 의 채택이 증가함에 따라 저수준 바이너리 보안과 고수준 웹 보안이 밀접하게 연관되어 있음을 증명하며, WASM 모듈을 네이티브 애플리케이션과 동일한 수준의 보안 엄격함으로 관리해야 할 필요성을 강조합니다.