앱 보안, 이것만큼은 반드시 지키세요.

이 글은 케이플이 100개가 넘는 앱을 개발하고 운영하면서 듣고 겪은 실제 사례들을 기반으로 작성한 글이에요.

비밀번호를 자주 바꿔라. 이런 뻔한 주제는 다루지 않아요

비밀번호를 자주 바꿔라

비밀번호에 특수문자를 포함시켜라

비밀번호에 생년월일을 포함시키지 말아라

네. 모두 맞는 말이에요.

비밀번호가 복잡해지고 유추하기 힘들어질수록, 소위 말하는 때려 맞히는 게 어려워지거든요.

다만, 이렇게 비밀번호를 직접 찾아서 공격하는 건, 해커 입장에서도 쉬운 건 아니에요.

가능한 비밀번호 조합이 너무 많고, 사이트마다 비밀번호가 여러 번 틀리면 아예 잠겨버리는 등 여러 방어 장치들이 있기 때문이죠.

그럼 이렇게 비밀번호를 맞춰서 계정을 탈취하는 공격 방법 말고, 다른 공격 방법도 있을까요?

네. 너무 많아요.

저희가 아직 미처 모르는 방법까지 하면, 정말 많은 방법이 있을 거예요.

특히 금융권, 국가 시설 등 중요한 자료를 다루는 곳에는 얼마나 많은 공격이 들어올까요?

감히 상상도 안 되네요.

그럼 우리가 만드는 크고 작은 앱 정도는 해킹으로부터 안전하겠지?

누가 이런 앱 하나 털라고 공격하겠어?

과연 이럴까요?

답부터 말씀드리면, 그건 결코 아니에요.

그래서 저희가 실제로 겪었거나 들었던 몇 가지 사례들로 최대한 쉽고 재미있게 작성해 볼게요.

아차, 그리고 이 글은 개발 지식이 없는 사람도 충분히 읽을 수 있도록 최대한 쉽게 작성할게요.

1. 앱의 코드는 우리만 아는 비밀이 아니에요

앱의 설치 파일은 단순히 코드를 압축해둔 파일과 크게 다르지 않아요.

누군가 마음먹으면 충분히 압축을 풀고 내용을 확인할 수 있는 거죠.

이걸 방지하기 위해 개발사에서는 난독화라는 걸 적용해요.

압축을 풀더라도 사람이 읽기 어려운 코드로 만드는 거죠.

그럼에도 불구하고 해독을 완벽하게 방지하는 것은 힘든 게 사실이에요.

그래서 실제로 많은 앱들이 이런 공격을 받고 있고, 개발사들도 이걸 감안하고 만들어야 해요.

저희가 인수인계 받은 한 앱의 사례를 소개할게요.

이미지 내 텍스트를 추출하는(OCR) 기능을 포함하는 앱이었어요.

그리고 OCR은 외부 유료 서비스를 통해 구현되어 있었는데, 이걸 호출하는 키가 코드에 그대로 박혀 있었죠.

만약 누군가 그 키를 탈취했다면요?

그 사람은 오랫동안 그 키를 이용해 마음껏 무료로 OCR을 이용했을 거예요.

그리고 그 비용은 고스란히 당신에게 청구됐겠죠.

그럼 이 공격에 어떻게 방어할 수 있을까요?

가장 확실한 건 앱의 코드에 중요 정보를 일절 포함시키지 않는 거예요.

먼저 비밀번호나 키처럼 민감한 정보는 코드에 작성하면 안 돼요.

관리자 비밀번호, 외부 호출 키 등 모든 민감 정보 말이에요.

그리고 관리자에게만 보이는 비밀 버튼도 구현하지 않는 것이 좋아요.

어차피 코드를 보면 이 버튼이 이런 역할을 하는구나. 라고 확인할 수 있으니까요.

그래서 관리자 전용 기능은 별도의 관리자 앱으로 개발하는 것이 좋아요.

혹시 이런 민감한 정보가 앱 코드에 포함되어 있는지, 지금이라도 당장 개발사에 문의해 보시는 건 어떨까요?

2. 우리 앱만 우리 서버로 요청하는 게 아니에요

이걸 설명하기 위해 API라는 게 뭔지 설명해야 할 것 같아요.

쉽게 말해 API는 이렇게 통신하자고 약속하는 것을 의미해요.

당신이 누군가에게 편지를 보낸다고 생각해봐요.

받는 사람 주소를 적고, 우표를 붙이고, 우편함에 넣겠죠?

저희 막내 팀원은 우표 안 붙여봤다던데…. 세월이..

그 이후 편지는 수거되고, 우체국을 거쳐서 최종적으로 받는 분에게 도착하겠죠.

최종적으로 편지를 받은 그 분이 당신에게 답장을 보낼 거예요.

이때 편지가 어떻게 수거되고 어떻게 전달되는지 상세하게 알 수도 없고, 알 필요도 없죠?

API도 마찬가지예요.

요청을 보낼 주소와 내용을 필요로 해요.

요청을 보내면 응답을 받는 것도 마찬가지죠.

물론 그 안에서 어떻게 동작하는지까지는 알 수 없어요.

더 정확하게 말해서는, 알 수 있으면 안 돼요.

가령 회원가입과 로그인 API는 다음과 같아요.

그리고 앱은 이런 API를 이용해 서버와 통신하며 동작하게 돼요.

지금까지 별 문제 없어 보이죠?

아직까지는요.

하지만 위에서 앱의 코드는 공개될 수 있다고 했죠?

그럼 API 주소, 내용, 심지어 예상 응답까지도 알 수가 있어요.

그럼 앱이 아닌 다른 곳에서도 이 API로 요청할 수 있게 되는 거예요.

비밀번호를 무작위로 대입해 보거나, 숨겨진 리워드 지급을 요청하거나..

보안적으로 위험할 수 있겠죠.

그렇기 때문에 API는 단순히 요청을 처리하는 것뿐만 아니라, 누가 이 요청을 했는지 검증할 필요가 있어요.

우리가 개발한 앱이나 웹에서 요청한 것만 처리하겠다.

이걸 “오리진 체크”라고 해요.

그럼 우리가 실제로 겪었던 한 앱의 사례를 소개할게요.

저희에게 고도화를 맡긴 앱인데, 이벤트를 진행하고 있었어요.

게시물을 읽고 좋아요를 누를 때마다 포인트를 지급했죠.

근데 이 API에 오리진 체크가 활성화되어 있지 않았어요.

만약 API를 반복적으로 호출하는 봇을 만들면, 앱을 이용하지 않고도 악의적으로 포인트를 받아갈 수 있는 상황이었던 거죠.

다행히 빠르게 조치해서 악용되지는 않았어요.

그러니 이 오리진 체크가 되어있는지, 지금이라도 당장 개발사에 문의해 보시는 건 어떨까요?

3. Firebase의 RemoteConfig는 안전하지 않아요

벌써 어렵죠?

Firebase는 뭐고, RemoteConfig는 뭔지.

Firebase는 앱을 빠르게 만들 수 있도록 구글에서 제공하는 여러 가지 도구 모음이라고 생각하시면 쉬워요.

그러면 RemoteConfig는 앱 내 구성요소를 실시간으로 변경할 수 있도록 해주는 도구라고 하면 좋겠네요.

가령 앱 내의 “회원가입” 버튼을 “시작하기”로 글자만 바꾸고 싶다고 가정해봐요.

앱 코드를 변경하고, 심사에 다시 제출하는 등 복잡한 과정이 필요해요.

심지어 심사에서 어떤 이유로 반려되면, 무의미하게 3~4일이 지나기도 하죠.

반면에 이 RemoteConfig를 이용하면, 매우 간단하게 실시간으로 변경할 수 있어요.

값만 바꾸면 되거든요.

회원 가입 버튼 라벨: “회원가입” → “시작하기”

비슷한 원리로 앱에 긴급 점검 공지를 띄울 수도 있고, 업데이트 안내 팝업창을 띄울 수도 있어요.

긴급 점검 여부: “아니오” → “예”

앱 최신 버전: “1.0.4” → “1.0.5”

이런 놀라운 기능들로 인해, 실제로 저희도 이걸 매우 애용하고 있어요.

하지만 보안적으로도 안전할까요?

그랬다면 이 글을 쓰고 있지 않겠죠.

Firebase(구글) 공식 문서에서도 RemoteConfig의 값은 노출될 수 있다고 경고하고 있어요.

그리고 심지어 해커가 본인의 폰에 저장된 저 값들을 무단으로 수정할 수도 있어요.

그럼 과연 천하의 구글이 실력이 부족해서 그럴까요?

아니에요.

애초에 그걸 감안하고 사용하도록 만들어졌기 때문이에요.

따라서 이 RemoteConfig에는 민감한 정보를 넣으면 안 되겠죠?

하지만 이걸 모르는 업체도 있는 것이 사실이에요.

정확히는 모르는 건지, 귀찮아서 그런 건지는 모르는 게 맞겠죠.

저희가 인수받아 경험한 한 앱에서 있었던 실제 사례를 소개해 드릴게요.

앱에서는 판매하고 있는 상품의 할인율, 할인 기간 등을 이 RemoteConfig로 관리하고 있었어요.

만약 해커가 이 정보를 훔쳐보고 조작했다면, 해커는 99% 할인된 가격으로 구매할 수도 있던 거였어요.

왜 이렇게 설계했는지는 이해가 돼요.

실시간으로 할인율이나 기간을 조절할 수 있었으면 했겠죠.

하지만 보안까지 생각했다면, 서버 측에서 추가 검증하는 것까지 구현해야 했어요.

서버도 이 값들을 조회할 수 있기에, 충분히 값이 맞는지 대조할 수 있거든요.

하지만 거기까지 해놓지는 않았더라고요.

다행히 실제로 악용되지는 않았지만, 정말 큰일 날 뻔했어요.

만약 내 앱에서 Firebase의 RemoteConfig를 사용하고 있다면, 지금 바로 점검해 달라고 하는 건 어떨까요?

정리

위에서 언급한 내용 말고도 저희가 보안 측면에서 신경 쓰고 있는 부분은 굉장히 많아요.

SSL/TLS 인증서

env 파일 관리

액세스 키별 권한 관리

Rate Limit 설정

CAPTCHA 설정

등

그리고 그게 당연하다고 생각하고 있고, 오히려 아직도 부족하다고 생각해요.

그러니 내 앱에는 해당되지 않겠지.

라고 생각하지 않으셨으면 좋겠어요.

보안 문제 하나로 돌이킬 수 없이 막대한 금전 피해를 볼 수도 있어요.

그리고 무엇보다 앱이 그동안 쌓아왔던 모든 신뢰가 한 번에 사라질 수도 있기 때문이에요.

또한 이렇게 보안을 신경을 쓰지 않는 개발 업체가 과연 얼마나 앱을 진심으로 만들까요?

이건 고민해 보셔야 할 부분이지 않을까 싶어요.

보통 하나를 보면 열을 알 수 있으니까요.

기능만 만든다고 끝나는 것이 아니라, 그게 오랫동안 안전하게 작동하게 만드는 것— 이게 저희가 생각하는 진짜 파트너의 일이에요.

프로젝트 문의는 언제든 환영이에요

새로 앱을 개발하실 때 보안적으로 걱정하고 싶지 않다면, 언제든 편하게 연락 주세요.

👉 케이플에 문의하기