28. WASM 리버싱으로 웹 보안 포인트 찾기

WebAssembly는 소스 코드를 숨기는 금고가 아니다. 브라우저가 실행해야 하는 모듈인 만큼 다운로드되고, import·export와 메모리 계약이 관찰된다. 보안 검토의 질문은 “얼마나 어렵게 읽히는가”가 아니라 “클라이언트가 결정해도 되는 값을 서버가 믿고 있는가”여야 한다. 분석은 소유한 앱이나 승인된 실습 대상으로 한정한다.

모듈을 기능이 아니라 경계로 읽기

DevTools Network에서 .wasm 파일과 JavaScript glue 코드를 함께 저장한다. wasm-objdump -x module.wasm으로 import/export와 메모리 정보를 확인하고, 필요할 때 wasm2wat module.wasm -o module.wat으로 구조를 읽는다. WAT의 함수 이름이나 문자열은 힌트일 뿐이며, 최적화된 모듈에서는 이름이 없거나 로직이 조각나 있을 수 있다.

다음으로 JS와 WASM 사이의 입력·출력 계약을 표로 만든다. 포인터와 길이, 정수의 부호, 반환 코드, 선형 메모리의 수명, 예외 처리 방식이 핵심이다. 토큰 생성이나 가격 계산 같은 로직을 찾았더라도 그 값이 권한·결제·접근 제어를 결정한다면 서버에서 독립적으로 재검증해야 한다.

동적 관찰의 한계

브라우저 디버거에서 export 호출의 인자와 반환값을 확인하거나, 개발 빌드에 계측을 넣어 경계 값을 기록할 수 있다. 민감한 평문과 세션 토큰은 수집하지 말고 합성 데이터로 재현한다. 클라이언트에서 반환값을 바꿔도 서버의 결정이 달라지지 않아야 한다. 달라진다면 WASM의 난독화 정도가 아니라 신뢰 경계가 잘못된 것이다.

방어 판단

키·장기 비밀·권한 판정은 WASM에 넣지 않는다. 모듈 무결성에는 HTTPS와 적절한 배포 정책을 사용하되, 무결성이 기밀성을 제공한다고 설명하지 않는다. 서버는 입력의 범위와 상태를 검증하고, replay 방지와 rate limit을 별도로 둔다. WASM은 성능과 배포 단위로 평가하고 보안성은 위협 모델과 서버 검증으로 평가해야 한다.