이번 글은 회사에서 겪었던 이슈를 정리할 예정이다.
보안팀에서 외주분들과 함께 자사 서비스를 모의해킹 했다. 여러 보안 취약점이 발생했고, 그 중 한 가지인 의도적으로 메모리 덤프 했을 시에 '중요한 정보' 가 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 를 죽이는 방법일 것 같다.
그게 아니면 뭐.. 보안솔루션을 돈주고 써야겠지..?
일단 올해 하반기 또는 내년 상반기 다시 모의해킹할 때, 해당 이슈가 다시 발생하는 지 지켜봐야할 것 같다.
'Mobile App' 카테고리의 다른 글
[안드로이드] Circle ImageView 원형 이미지 (Custom ImageView, ShapeableImageView, CircleImageView) (0) | 2023.08.31 |
---|---|
[안드로이드] xml 파일 id 속성값이 지속적인 에러가 발생한다면? (0) | 2023.08.30 |
[안드로이드] - MVC 패턴과 안드로이드 MVC 패턴 (0) | 2023.02.15 |
[안드로이드] MVVM 패턴과 안드로이드 MVVM 패턴 (0) | 2023.02.11 |
[안드로이드] - ListAdapter (0) | 2023.02.02 |