본문 바로가기
Mobile App

[안드로이드] webview 메모리 덤프 평문 노출

by Jman 2023. 6. 30.

이번 글은 회사에서 겪었던 이슈를 정리할 예정이다.

보안팀에서 외주분들과 함께 자사 서비스를 모의해킹 했다. 여러 보안 취약점이 발생했고, 그 중 한 가지인 의도적으로 메모리 덤프 했을 시에 '중요한 정보' 가 Hex(16진수) 코드들 사이에 그대로 평문 노출되는 것을 보안해야 하는 상황이였다.

 

해당 이슈를 해결하기 위해 찾아보는데, 내가 찾는 케이스가 존재하지 않았다.

우리 UI/UX 개발팀에서 Android native 만 담당하고, WebView 작업은 다른 사업팀에서 관리를 한다. 해당 보안 취약점 이슈를 어느 사업팀에서 처리를 해야 하는지 이야기가 오가는데, 서로 자기 쪽이 아니라고 한다. 정말 아리송하지 않는가..?

 

Android Native 에서 WebView 를 연 뒤, Webview 에서 '중요한 정보'를 input 받은 뒤, 암호화하여 서버로 보내어 저장한다.

웹뷰를 관리하는 다른 팀원 주장은 input 받은 값을 저장하지 않고, 데이터를 AES-256 암호화 하여 jQeury-Ajax 데이터 통신하여 서버로 보낸다고 한다. 그러니 저장하지 않았고, Native 단에서 대응해야 할 이슈라고 한다.

 

아니.. input 받아서 처리하는 로직이 있다면 변수에 저장을 하지 않아도 의심해서 수정을 하겠는데 어찌하겠는가? input 받는 로직 자체가 없는데..

 

결과적으로 일단 우린 이렇게 대응하기로 했다.

WebView 코드 쪽 jQuery-confirm input-type password 로 받은 데이터가 참조타입으로 데이터가 오는 걸 확인하여,

값을 저장하는 로직이 없더라도, 해당 로직을 참조타입이 아닌, 원시타입으로 바꾸어 값 초기화하는 과정으로 대응하기로 했다.

 

여기서 왜? 참조타입이 아닌, 원시타입일까? 즉 String 이 아닌 CharArray 로 데이터를 받아 처리하는 방법이다.

참조타입으로 변수에 담아 사용한 후, null 로 변수를 초기화 하더라도, 메모리에 password 가 여전히 평문으로 남는다. 그 이유는 null 로 초기화된 다른 주소 값을 갖기 때문이다.

 

이 외에 다른 방법으론 

WebView 를 띄운 View 를 죽이는 방법일 것 같다.

 

그게 아니면 뭐.. 보안솔루션을 돈주고 써야겠지..?

일단 올해 하반기 또는 내년 상반기 다시 모의해킹할 때, 해당 이슈가 다시 발생하는 지 지켜봐야할 것 같다.