⚽️ 목표
소스맵 파일을 제거하지 않아서 웹 브라우저에서 Human Readable(Uglify 되지않은) 상태로 코드가 확인 가능하다면?라는 고민에서 시작한 고찰
TLDR;
법적 강제성은 애매하지만 간단한 설정으로 막을 수 있으므로 제거를 추천한다.
•
코드작성 시 가독성, 재 사용성 전부다 때려친 손난독화를 한 코드면...Human Readable 코드라 해도 의미없는건 매한가지다. → 이런 코드면 애초에 문제가 있는 코드가 아닐까?
1. 들어가기전에
•
•
Transpile에 대한 결과(구형 브라우저 지원 + 압축)로 인해 Human Readable 코드가 아닌 난독화된 코드로 변경된다.
2. 어떻게 노출되는가?
소스맵 파일 존재 시
•
(설정에 따라 다르지만)소스맵 파일을 제거하지 않을 경우 배포 후 개발자 도구 이용 시 소스코드가 Human Readable 상태로 노출된다.
•
웹팩으로 번들링 하기 전 코드 또한 확인 가능 -> 컴포넌트 단위로 디렉터리 구조 또한 나뉘어져 있음
소스맵 파일이 존재하지 않을 시
•
소스맵 파일이 존재하여 완전 Human Readable 코드보다 상대적으로 코드 파악 및 분석이 어려움
•
디렉터리, 파일 구조 또한 번들링된 상태로 노출되어 코드 분석 및 파악이 더 어려움
3. 법적 강제성
주요정보통신기반시설 기준
•
매핑되는 취약점 없음
전자금융기반시설 기준
•
웹 - 매핑되는 취약점 없음
•
모바일 - 하이브리드 앱의 경우 소스코드 난독화 적용 여부 매핑 가능
4. 나눠지는 의견들
취약점이 아니다
"이게 취약점이 될까요? 어차피 프론트 코드는 브라우저상에 노출되는거고 Uglify 되어있다고 해도 시간 조금만 더들이면 바로 분석 및 우회 가능한거 아닌가요?" -보안 담당자 A 씨-
•
법적 강제성도 없으며 그나마 매핑되는 취약점도 모바일임. 웹에서만 서비스 하는 경우 해당사항이 아님
•
어차피 브라우저에서 돌아가는 코드임, 서버와는 전혀 상관 없음
취약점이 이다
"소스맵 파일이 굳이 프론트에 노출되어야할 이유가... 없지 않습니까? 오히려 노출되어서 잠재적 위험요소로 남겨 놓느니 제거하는 쪽으로 가는게 맞을거 같네요" -보안 담당자 B 씨-
•
모든 대응의 기준을 법적으로 따지기엔 너무 소극적인 태도이다, 법적 기준에는 최신 기술들의 적용이 항상 늦다, 유연하게 대응해야 한다. ex)주요정보통신기반시설 웹 진단기준에는 아직도 포멧스트링, 자동화 공격과 같은 취약점들이 존재한다
•
간단한 설정으로 내부 코드 유출 + 잠재적 위험 요소를 제거 할 수 있는 바겐 세일이 있는데... 이걸 안해?
5. 작성자의 의견
"모바일에 난독화가 안되어있는 코드면 다들 취약점이라고 난리인데... 모바일 보다 더 쉽게 접근 및 분석 가능한 웹에서 소스코드 난독화가 안이루어져 있는데... 이걸 왜 안잡아?"
•
모바일 애플리케이션 만큼의 권한은 아니지만 비슷할 정도로 권한을 가지고 있는 모던 브라우저 -> 비슷한 위험성을 가지고 있습니다.
•
보안은 무조건 백엔드지! 무슨 클라이언트 단 보안이야! 라는 소극적인 입장만으로는 다계층 보안을 구현하기 어렵습니다.
프로세스 차이
•
소스코드 난독화가 이루어져 있지 않은 웹/모바일 애플리케이션의 프로세스 복잡도 차이
•
모바일 애플리케이션은 훨씬더 많은 필요 조건이 동반되어야 함
◦
모바일 애플리케이션 소스코드 분석 프로세스
1.
앱다운로드
2.
모바일 기기와 PC 연결
3.
앱 추출
4.
IDA나 JEB에로 분석
5.
(추가) FRIDA와 같은 툴이 존재해야 동적 디버깅
(소스코드 직접 패치는... 쫌..)
(기기의 루팅이나 탈옥이 선행되지 않을 경우 그마저 힘듬)
◦
웹 소스코드 분석 / 변조 프로세스 → 단 두개의 프로세스!
1.
웹페이지 접속
2.
개발자 도구 켜기 (개발자 도구에서 소스코드 변조 및 동적 디버깅 가능)
치트키
웹팩 공식 문서에서 일반 이용자에게 전체 소스맵을 제공하지 말라했다구우우웃!
결론
"노출되면 안된다!"에 대한 법적 근거는 없지만 충분히 위험성을 가지고 있으며 대응이 어렵지 않은 취약점이므로 운영상에 문제가 되지 않으면 소스맵 파일을 제거하자!