OWASP Mobile Top 10 : 모바일 개발자를 위한 리스크 대처 종합 가이드

Dustin Hong

5년 ago

다양한 활동에 대해서 보다 사용이 쉽고 편리한 것을 찾는 소비자와 이를 지원하는 모바일 애플리케이션 사용이 기하 급수적으로 증가함에 따라서, 모바일 앱과 관련된 보안 취약성의 빈도 또한 함께 증가하였습니다. OWASP Mobile Top 10은 각종 위협으로부터 모바일 앱을 지켜야하는 개발자가 반드시 인지해야 하는 보안 결함 및 취약성을 모아놓은 목록 중에 하나입니다.

왜 안전한 모바일 앱입니까?

전세계적으로 유명한 브랜드가 뒷받침하는 모바일 디바이스와 앱은 표면적으로 안전해 보일 수 있습니다. 하지만 현실은 그렇지 않습니다.

2019년 11월 모바일 보안 회사인 NowSecure는 250개의 인기있는 안드로이드 앱에 대해서 보안 테스트를 수행하였습니다. 그 결과 약 70%의 앱이 민감한 개인 데이터를 유출한 것으로 나타났습니다.

Javelin Strategy & Research의 2019 Identity Fraud Study에 따르면 약 1,440만명의 미국 사람들이 신원 도용의 희생자가 되었으며, 도용의 대부분은 손상된 모바일 디바이스 계정을 통해 발생했습니다.

대부분의 최신 모바일 앱은 개인화된 사용자 경험을 제공하기 위해서 사용자 자격 증명, 은행 정보 및 개인 식별 정보를 서비스에 이용하고 저장합니다. 복잡하고 다양한 보안 위협의 출현으로 개발자는 최신 위협과 함께 기존 위협에 대한 포괄적인 이해가 필요합니다. 여기 보안 전문가에게 필수적 도구인 OWASP Mobile Top 10 목록이 있습니다.

OWASP란 무엇입니까?

2001년에 설립된 OWASP(Open Web Application Security Project)는 웹 및 모바일 애플리케이션 보안 분야에 관한 방법론, 문서, 도구를 만들고 관련 기술을 연구하는 개발자 커뮤니티입니다. 상위 10개 위험 목록은 개발자 커뮤니티안에서 웹 및 모바일 애플리케이션에 대한 새로운 보안 위협에 대한 인식을 고취하기 위해 지속적으로 업데이트되는 일종의 리소스입니다. 여기에서 OWASP 전체 프로젝트 목록을 확인할 수 있습니다.

OWASP Mobile Top 10이란 무엇입니까?

OWASP Mobile Top 10은 전세계 모바일 앱이 직면한 보안 위험 유형을 식별하는 목록입니다. 2016년에 마지막으로 업데이트된 이 목록은 개발자가 안전한 애플리케이션을 구축하고 코딩 모범 사례와 통합할 수 있도록 도와주는 실무 가이드입니다. NowSecure에서 테스트 한 앱의 거의 85%가 OWASP Top 10 위험 중 하나 이상에 영향을 받는 것으로 확인된 만큼, 개발자는 각 목록의 위험 요소를 이해하고 가능하다면 해당 위험 발생을 차단하는 코딩 방법을 채택해야 합니다.

M1에서 M10까지 표시된 OWASP Mobile Top 10 위험 요소가 아래에 나열되어 있습니다.

M1: 부적절한 플랫폼 사용

이 위험에는 운영 체제 기능을 오용하거나 플랫폼의 보안 콘트롤 기능을 올바르게 사용하지 못하는 경우가 포함됩니다. 여기에는 안드로이드 인텐트, 플랫폼 퍼미션, 키체인 또는 플랫폼의 일부로 제공되는 보안 컨트롤이 포함될 수 있습니다. 이 위험은 일반적으로 발생하며, 평균 수준의 탐지 가능성을 나타내지만, 이 위험의 영향을 받은 앱은 심각한 피해를 입을 수 있습니다.

부적절한 플랫폼 사용 리스크

안드로이드 인텐트 활용한 데이터 유출

안드로이드 인텐트는 운영 체제내에서 다양한 Activity간의 통신을 허용하는 메시징 객체입니다. 이러한 작업에는 백그라운드 서비스와의 통신, 모바일 디바이스 또는 다른 앱의 서버에 저장된 데이터 접근, 이벤트 변경 중 메시지 브로드 캐스팅, 브라우저 또는 다른 앱 열기와 같은 Activity의 시작 또는 종료 등이 포함됩니다. 인텐트는 순환적 사용이 가능하기 때문에, 메시지 교환중 데이터 유출 가능성도 높아집니다.

안드로이드 인텐트 스니핑

안드로이드 생태계 내의 많은 앱은 주로 인텐트를 통해서 정보를 획득하도록 설계되었습니다. 이러한 앱을 통해서 합법적인 앱과 다른 안드로이드 구성요소 간에 통신이 이루어질 때 URL 패턴 또는 사용자 정보를 연구할 수 있습니다.

iOS 키체인 리스크

키체인은 모바일 사용자가 기억하기 어려운 암호를 생성하여 해독하기 어려운 암호를 만들어 은행 및 전자 메일 계정과 같은 3rd party 계정을 모바일 장치에서 더욱 안전하게 사용할 수 있도록 하는 안전한 저장 시설입니다. iOS는 개발자가 자체 암호화 방법을 도입할 필요가 없도록 키체인 암호화를 제공합니다. 개발자는 액세스 제어 목록과 키체인 액세스 그룹을 사용하여 어떠한 앱과 데이터를 암호화 해야 하는지 또는 오픈해야 하는지의 상태를 결정할 수 있습니다. 사용자가 키체인 옵션을 선택하지 않으면 직관적으로 기억하기 쉬운 암호를 선택하는 경향이 있으며, 이는 해커에 의해서 악용되기가 쉽습니다.

iOS TouchID 리스크

iOS에서는 개발자가 TouchID 옵션을 사용하여 모바일 앱을 인증 할 수 있습니다. 만약 TouchID 옵션을 사용하지 않는다면, 인증 프로세스는 해킹시도에 취약할 것입니다.

M1: 부적절한 플랫폼 사용 예

부적절한 플랫폼 사용을 피하는 모범 사례

iOS 키체인 모범 사례

서버 경유를 통한 키체인 암호화는 허용하지 말고 암호화된 키를 하나의 디바이스에만 보관하여 다른 디바이스나 서버에서 악용할 수 없도록 하십시오.

전용 액세스 제어 목록을 가져야하는 앱의 비밀 정보를 저장하기 위해 키체인을 사용하여 앱을 보호하십시오. 액세스 제어 목록의 사용자 인증 정책은 OS에 의해 시행될 수 있습니다.

안드로이드 인텐트 모범 사례

퍼미션 제어를 통해서 다른 앱과 통신할 수 있는 앱을 제한함으로써, 허용되지 않은 트래픽의 모든 시도를 실질적으로 차단하십시오. 또 다른 옵션은 안드로이드 프레임워크를 사용하는 Activity와 서비스 및 브로드캐스트 리시버 등의 하나 또는 모두에 대하여 인텐트 내보내기 옵션을 허용하지 않음으로써 다른 앱과 통신할 이유가 없는 안드로이드 컴포넌트가 처음부터 유지됩니다.

안드로이드 인텐트 스니핑 모범 사례

이러한 유출은 인텐트 객체의 정의를 명확하게 하는 명시적인 인텐트에 의해서 제어 될 수 있습니다. 그에 따라서 모든 컴포넌트가 인텐트에 포함된 정보에 접근하는 것을 차단합니다. 또한 필요한 권한이 있는지 앱을 공개하기 전에 파일 퍼미션을 철저히 확인하십시오.

M2: 안전하지 않은 데이터 저장소

OWASP는 M2에 대해서 악용 가능성 “쉬운”, 유행 가능성 “일반적”, 탐지 가능성 “평균” 및 영향도 “심각한”으로 표시합니다. OWASP 목록의 이 위험은 공격자가 모바일 디바이스에서 안전하지 않은 데이터에 접근할 수 있는 쉬운 방법을 개발자 커뮤니티에 알려줍니다. 공격자는 도난당한 디바이스에 물리적으로 접근하거나 악성 소프트웨어 또는 재패키징된 앱을 사용하여 디바이스내에 접근할 수 있습니다.

디바이스에 물리적으로 접근하는 경우 디바이스를 컴퓨터에 연결 한 후 디바이스의 파일 시스템에 액세스 할 수 있습니다. 무료로 제공되는 많은 소프트웨어를 통해 공격자는 3rd party 애플리케이션 디렉토리 및 그 안에 포함된 개인 식별 데이터에 액세스 할 수 있습니다.

안전하지 않은 데이터 저장소 리스크

손상된 파일 시스템

손상된 파일 시스템의 명백한 결점은 사용자의 개인 정보가 손실되는 것이지만, 공격자가 모바일 악성 프로그램이나 조작된 앱 또는 포렌식 도구를 통해서 앱의 민감한 정보를 탈취할 가능성이 있어 모바일 앱 개발자나 소유자에게도 피해를 입힐 수 있습니다. 사용자 관점에서 볼 때 이러한 종류의 데이터 손상은 개인 정보 도용, 개인 정보 보호 위반 및 개인 사용자에 대한 기만으로 이어질 수 있으며, 비즈니스적으로는 해당 서비스의 평판 손상, 외부 정책 위반 및 이용자의 물질적인 손실을 발생시킬 수 있습니다.

공격자는 손상된 디바이스의 여러 위치에서 보안되지 않은 데이터를 찾습니다. 여기에는 SQL 데이터베이스, 로그 파일, XML 데이터 저장소, 바이너리 데이터 저장소, 쿠키 저장소, SD 카드 및 클라우드 동기화가 포함되며 운영 체제, 프레임 워크, 컴파일러 환경, 새 하드웨어, 루팅 및 탈옥 디바이스가 해당됩니다.

보안되지 않은 데이터의 악용

디바이스내에서 캐시 데이터, 이미지, 키 클릭 및 버퍼를 어떻게 저장하는지에 대해서 제대로 알지 못하는 개발자로 인해 보안되지 않은 데이터는 악용될 수 있습니다. 분석가들은 운영 체제 및 개발 프레임 워크 수준에서 이러한 프로세스에 대한 적절한 기술 문서가 부족한 것이 개발자가 이러한 보안 프로세스를 중요시 여기지 않는 주요한 원인이라고 이야기합니다. 결국 이러한 문제는 해커가 디바이스의 데이터 또는 프로세스를 조작 할 수 있는 핸들을 제공합니다.

M2: 안전하지 않은 데이터 저장소 예

Best Practices to Avoid Insecure Data Storage

iGoat iOS

OWASP는 iOS 디바이스의 경우 iGoat와 같이 의도적으로 취약하게 만든 모바일 앱을 사용하여 앱 및 개발 프레임 워크 위협 모델을 만드는 것을 추천하고 있습니다. 이 프로세스를 통해 개발자는 API가 URL 캐싱, 키 클릭 캐싱, 버퍼 캐싱, 키 체인 사용, 애플리케이션 백그라운드, 로깅, 데이터 스토리지, 브라우저 쿠키 관리, 서버 통신 및 3rd party로 전송된 트래픽과 같은 정보 에셋 및 앱 프로세스를 처리하는 방법을 이해할 수 있습니다.

ADB(Android Debug Bridge)

안드로이드 개발자는 ADB(Android Debug Bridge) 쉘을 사용하여 타겟 앱의 파일 권한을 확인하거나 sqlite3와 같은 데이터베이스 관리 시스템을 통하여 데이터베이스 암호화 여부를 확인할 수 있습니다. ADB는 또한 ‘logcat’과 같은 명령을 제공하여 개발자가 안드로이드 로그에 포함된 오류 로그를 확인하여 민감한 정보나 보안이 필요한 정보가 악성 소프트웨어로 유출되는지 여부를 확인할 수 있습니다. 광범위한 오류 로그는 개발 과정에서 개발자에게 도움이되지만, 만약 로그를 방치하면 앱 또는 데이터가 손상의 원인이 될 수 있습니다. 또한 안드로이드 개발자는 Android Device Monitor 및 Memory Analysis Tool과 같은 도구를 사용하여 디바이스 메모리에 지정되지 않은 기간 동안 의도하지 않은 데이터가 있는지를 확인해야 합니다. 이러한 데이터는 해커나 디바이스에 물리적 접근 권한이 없는 사람에 의해서 악용될 수 있기 때문입니다.

M3: 안전하지 않은 통신

모바일 앱간의 데이터 전송은 일반적으로 통신 사업자 또는 인터넷을 통해 이루어집니다. 해커는 손상된 Wi-Fi 네트워크, 라우터, 셀룰러 타워, 프록시 서버 등을 통해서 사용자의 LAN에 접속하거나 악성 프로그램이 포함된 감염된 앱을 악용하여 데이터를 가로챕니다.

안전하지 않은 통신의 리스크

정보 도용

이러한 범주 중 손상되거나 보안이 허술한 Wi-Fi 네트워크를 통해 트래픽을 모니터링하는 것이 공격자가 정보를 도용하는 가장 쉬운 방법입니다. 하지만 OWASP는 개발자가 TCP/IP, Wi-Fi, Bluetooth / Bluetooth-LE, NFC, 오디오, 적외선, GSM, 3G, SMS 등 모바일 디바이스에 대한 모든 아웃 바운드 및 인바운드 트래픽을 감시할 것을 요구합니다.

중간자(MITM; Man in the Middle) 공격

모바일 개발자는 일반적으로 인증을 위해 SSL/TLS를 사용하는 것을 알고 있는 반면에, 이러한 인증서의 유효성을 올바르게 검사를 수행하지 않아 공격자가 MITM 공격을 수행 할 수 있는 여지를 남겨 놓는 실수를 하곤 합니다. 이러한 공격을 통해 공격자는 앱과 해당 서버간에 전송된 트래픽을 보고 수정하거나 세션 ID를 가로 챌 수 있습니다. 보안용 인증서는 도메인별로 다르므로 테스트 서버에서는 사용할 수 없습니다. 개발자는 코드를 테스트 할 때 프로덕션 서버에서 자체 서명된 인증서를 수락하는 경향이 있습니다. 자체 서명된 인증서는 암호화되지 않은 일반 텍스트로 통신하는 수준과 유사하기 때문에 MITM 공격에 헛점이 있습니다. 개발자가 자체 서명된 인증서를 허용하지 않는 경우에는 공격자는 개발자가 푸시한 접속 허용 호스트 이름 확인 옵션을 악용하는 경향을 나타냅니다. 만약 모든 호스트 이름이 허용되면, 공격자는 단순히 인증 기관에서 발급한 유효한 인증서를 사용하여 앱 서버 트래픽을 제어 할 수 있습니다.

관리자 계정 손상

MITM 공격의 더 큰 위험은 공격자가 사용자 데이터를 도용할 때가 아니라 안전하지 않은 통신으로 인해 관리자 계정의 데이터 도난이 발생할 수 있다는 것입니다. 이로 인해 전체 웹 사이트와 모든 중요한 데이터가 해킹 될 수 있습니다. 이러한 공격은 암호화 키, 비밀번호, 개인 사용자 정보, 계정 세부 정보, 세션 토큰, 문서, 메타 데이터 및 바이너리 등에 영향을 주거나 도용하는데 사용됩니다.

M3: 안전하지 않은 통신 예

Rapid7의 모의 침투 테스터들은 어린이 GPS 시계의 잠재적 허점을 식별하기 위해 해킹을 수행했습니다.

안전하지 않은 통신을 피하는 모범 사례

개발자는 안전하지 않은 통신을 처리하기 위해 OWASP의 다음 제안을 실행해야 합니다.

네트워크 계층은 안전하지 않으며 도청에 취약하다고 가정합니다.
앱과 서버간에 통신되는 트래픽에 대한 누출을 항상 주지하십시오. 또한 앱을 설치된 디바이스와 유선 네트워크를 포함한 로컬 네트워크를 통한 다른 로컬 디바이스와의 트래픽을 감시합니다.
모바일 앱이 민감한 정보, 세션 토큰 또는 기타 민감한 데이터를 백엔드 API 또는 웹 서비스로 전송하는데 사용하는 채널은 SSL/TLS를 적용합니다.
애플리케이션이 브라우저 또는 웹킷을 통해 실행될 때 SSL 버전을 사용하여 3rd party 분석 회사나 소셜 네트워크 등과 같은 외부 엔티티에 대해서 설명합니다.
사용자의 세션 ID가 노출될 수 있으므로 SSL 세션을 혼합하여 사용하지 마십시오.
적절한 키 길이를 가진 강력한 업계 표준 암호 제품군을 사용하십시오.
신뢰할 수있는 CA 제공 업체가 서명한 인증서 사용하십시오.
키 체인내에 신뢰할 수 있는 인증서를 사용하여 엔드 포인트 서버의 ID를 확인한 후에만 보안 연결을 설정하십시오.
모바일 앱이 잘못된 인증서를 감지하면 UI를 통해 사용자에게 경고하십시오.
대체 채널(예 : SMS, MMS 또는 알림)을 통해 중요한 데이터를 보내지 마십시오.
가능하다면 SSL 채널에 제공되기 전에 중요한 데이터에 별도의 암호화 계층을 적용하십시오. SSL 구현에서 향후 취약점이 발견될 경우 암호화된 데이터는 기밀성 침해에 대한 2차 방어를 제공합니다.

M4: 안전하지 않은 인증

이 문제는 모바일 디바이스가 사용자를 올바르게 인식하지 못하고, 공격자가 기본 자격 증명으로 앱에 로그인 할 수 있는 경우에 발생됩니다. 이는 일반적으로 인증 프로토콜이 누락되거나 잘못 구현될 때 해커에 의해서 해당 과정이 우회되거나 위조가 발생될 수 있습니다. 또한 모바일 디바이스에 있는 악성 소프트웨어나 봇넷을 이용하여 서버와 직접 통신하는, 즉 앱과의 직접적인 통신이 발생하지 않는 경우에 발생합니다.

안전하지 않은 인증의 리스크

입력 폼 팩터

앱 제작자와 모바일 플랫폼은 사용자들로부터 쉽게 접근할 수 있도록 4자리 또는 6자리 비밀번호를 사용하는 경향이 있습니다. 이러한 입력 폼 팩터는 쉽게 접근이 가능하고 보안적으로 취약하기 때문에 모바일 디바이스의 일반적인 공격 시작점으로 사용됩니다. 취약한 입력 폼 팩터 외에도 모바일 디바이스에서 신뢰할 수 없는 인터넷 접근을 허용하는 것은 개발자가 세션을 인증하기 위해 오프라인-온라인 접근 방식을 채택하도록 합니다.

안전하지 않은 사용자 자격 증명

안전하지 않은 인증의 기술적인 영향은 앱이 사용자 자격 증명을 제대로 확인할 수 없는 경우 사용자 활동을 올바르게 기록 할 수 없다는 것입니다. 이러한 사용자가 디바이스와 주고받는 데이터 또는 코드를 악용하는 경우 보안팀은 공격의 출처와 특성을 올바르게 확인할 수 없습니다. 또한 운영 체제가 제대로 인증되지 않은 사용자에게 어떤 역할을 할당해야 하는지 정확히 알 수 없기 때문에 안전하지 않은 인증은 디바이스내의 사용자 권한에 혼란을 초래합니다.

M4: 안전하지 않은 인증 예

안전하지 않은 인증을 피하는 모범 사례

앱의 인증 체계를 신중하게 연구하고 오프라인 모드에서 바이너리 공격 테스트를 수행하여 잠재적으로 악용될 수 있는 여지를 확인하십시오. 보안팀은 앱이 POST/GET 명령을 실행하여 액세스 토큰없이 서버와의 연결을 설정하고 있는지 확인해야 합니다. 만약 연결에 성공된다면, 앱은 취약하다고 할 수 있습니다. 개발자는 비밀번호 및 보안 키가 모바일 디바이스에 로컬로 저장되어 있지 않은지 확인해야 합니다. 로컬에 저장된 데이터는 조작이 매우 쉽습니다.

보안팀은 안전하지 않은 인증으로부터 모바일 앱을 보호하기 위해 다음과 같은 많은 방법을 구현해야 합니다.

웹 앱의 보안 프로토콜은 복잡성 및 인증 방법 측면에서 모바일 앱의 보안 프로토콜과 일치해야 합니다.
웹 브라우저에서와 마찬가지로 온라인 인증 방법을 사용하십시오. 모바일 디바이스에서 액세스 용이성이 우선하는 경우 M10 리스크에 자세히 설명된 바이너리 공격으로부터 보호하십시오.
서버에서 사용자 세션을 인증하지 않은 경우 앱의 데이터 로딩을 허용하지 마십시오. 앱 데이터를 로컬로 저장하면 로딩 속도가 빨라지지만 사용자 보안이 저하 될 수 있습니다.
데이터의 로컬 저장소는 결국에는 사용자의 로그인 자격 증명에서 파생된 암호화 된 키로 암호화되어, 앱이 데이터를 필요로 할때 한 번 이상 인증하도록 합니다.
영구 인증 요청은 로컬이 아닌 서버에 저장해야 합니다. 사용자가 remember-me 옵션을 선택할 때 항상 주의해야 합니다.
도난된 디바이스내의 앱은 보안적으로 취약해 지기 때문에, 앱내에서 디바이스 중심의 인증 토큰 사용할 때 보안팀은 특히 주의해야 합니다. 앱의 디바이스 중심 인증 토큰은 디바이스의 새 소유자가 디바이스 접근 비밀번호를 변경하는 경우 앱에 접근할 수 없도록 합니다.
모바일 디바이스에 대한 권한 없이 물리적 접근 행위가 일반적이므로 보안팀은 사용자 자격 증명을 주기적으로 인증하고 인증 받은 사용자에 대한 로그 아웃을 서버측에서 수행해야 합니다.
사용자가 비밀번호로 영문자와 숫자를 선택하도록 해야 합니다. 이것은 단순한 문자 조합보다 안전합니다. 또한 개발자는 앱에 대한 액세스를 허용하기 전에 사용자에게 이미지 또는 단어를 식별하도록 할 수 있습니다. 2단계 인증 방법이 빠르게 확산되고 있습니다.

M5: 불충분한 암호화

모바일 앱내의 데이터는 낮은 강도의 암호화/복호화 프로세스 또는 결함 있는 암호화/복호화 트리거 알고리즘으로 인해 취약해집니다. 해커는 모바일 디바이스에 물리적으로 접근하여 네트워크 트래픽을 감시하거나 디바이스내의 악성앱을 사용하여 암호화된 데이터에 접근할 수 있습니다. 암호화 프로세스의 결함을 사용하여 데이터를 원래 형식으로 복호화하여 데이터를 훔치거나 또는 적대적인 프로세스를 통하여 암호화 후 합법적인 사용자가 이를 사용할 수 없도록하는 것이 목표입니다.

불충분한 암호화의 리스크

앱 및 사용자 데이터 도용

안드로이드와 iOS는 모두 신뢰할 수 있는 출처에서 발급한 인증서를 사용하여 앱 코드를 강제로 암호화 합니다. 사용자가 앱을 호출할 때 인증서를 이용하여 암호화 서명을 확인한 후 문제가 없다면 디바이스 메모리내에서 해독 후 실행됩니다. 하지만 이러한 절차를 우회할 수 있는 일반적으로 사용 가능한 많은 도구가 있습니다. 이 도구를 사용하면 탈옥된 디바이스에서 앱을 다운로드하여 해독하고, 사용자가 앱을 실행하기 전에 해독된 앱의 스냅샷을 원래 디바이스의 메모리로 되돌릴 수 있습니다. 앱이 손상된 상태에서 실행되면 해커는 앱을 추가로 분석하여 바이너리 공격을 수행하거나 사용자 및 앱 데이터를 탈취합니다. 운영 체제에서 제공하는 기본 암호화 프로세스에만 의존하여 만들어진 앱은 코드 조작의 위험에 놓여있습니다.

암호화된 파일 액세스

많은 개발자들이 암호화 키를 잘못 관리하고 있습니다. 이것은 뛰어난 최상의 알고리즘을 사용하여 보안을 유지하더라도 해커에 의해서 암호화된 파일이 제어당할 수 있다는 의미입니다. 개발자는 암호화된 데이터와 동일한 디렉토리에 암호화 키를 배치하는 경향이 있습니다. 이를 통해 해커가 키에 쉽게 액세스하고 암호 해독에 사용할 수 있습니다.

M5: 불충분한 암호화 예

불충분한 암호화를 피하는 모범 사례

최신 암호화 알고리즘을 선택하여 앱을 암호화 하십시오. 신뢰할 수 있는 소스의 암호화 알고리즘은 일반적으로 보안 커뮤니티에서 자주 테스트하므로 이러한 알고리즘을 선택하면 취약점을 상당 부분 해결할 수 있습니다.
미국 정부의 국립 표준 기술 연구소(NIST)는 때때로 암호화 표준을 발표하고 암호화 알고리즘을 권장합니다. 개발자는 새로운 위협에 주의하기 위해 이 문서를 주의 깊게 살펴봐야 합니다.

M6: 안전하지 않은 승인

많은 사람들이 M4 위험을 M6 위험과 혼동합니다. 둘 다 사용자 자격 증명에 관한 것입니다. 안전하지 않은 승인은 공격자가 권한부여 프로세스의 취약점을 이용하여 합법적인 사용자로 로그인하려는 것인 반면, 안전하지 않은 인증은 공격자가 익명 사용자로 로그인하여 인증 절차를 우회하려는 것임을 개발자는 인지해야 합니다.

안전하지 않은 승인의 리스크

관리 엔드포인트에 대한 규제되지 않은 접근

M6 위험에 따라 공격자가 합법적인 사용자로 앱에 액세스하면 다음 작업은 관리자 명령을 실행할 수있는 엔드 포인트를 강제 탐색하여 관리자 접근 권한을 얻는 것입니다. 공격자는 일반적으로 모바일 디바이스에서 봇넷 또는 악성 프로그램을 사용하여 승인 취약점을 해킹합니다. 이러한 보안 손상의 결과로 공격자는 오프라인 모드에서 디바이스의 바이너리 공격을 수행할 수 있습니다.

안전하지 않은 직접 객체 참조(IDOR) 접근

경우에 따라 승인 체계를 통해 공격자는 사용자가 제공한 입력값을 이용하여 데이터베이스 또는 파일과 같은 객체에 대한 접근 권한을 얻을 수 있는 IDOR로 일반적으로 알려진 안전하지 않은 직접 객체 참조를 실행할 수 있습니다. 이러한 누출은 전체 운영 체제를 불안정하게 만들거나 데이터 및 평판 손실을 이끌 수 있습니다.

M6: 안전하지 않은 승인 예

안전하지 않은 승인을 피하는 모범 사례

높은 권한을 가진 사용자를 위해 예약된 민감한 명령에 대해 낮은 권한의 세션 토큰을 실행하여 사용자 권한을 지속적으로 테스트 하십시오. 만약 명령을 성공적으로 실행할 수 있다면, 앱의 승인 체계를 즉시 확인하십시오.
일반적으로 사용자 승인 체계는 오프라인 모드에서는 잘못된다는 점을 개발자는 명심해야 합니다. 하지만 경우에 따라서 개발자가 사용자 권한 및 역할을 서버로 전송하도록 허용하는 것이 승인 체계 취약점 발생의 원인이 될 수도 있습니다.
승인의 실행은 모바일 디바이스가 아닌 서버에서 인증된 사용자에 대한 역할과 권한을 확인하는 것입니다. 인증된 사용자의 높은 권한 기능을 악용하는 가능성은 백엔드에서 검증된 사용자 관리 체계를 이용하는 것이 모바일 장치 내에서 검증하는 것보다 상대적으로 줄어듭니다.

M7: 열악한 코드 품질

M7 위험은 개발팀의 각 구성원이 서로 다른 코딩 방법을 따르면서 최종 코드에서 불일치를 만들어 내는 일관성이 부재하고 조악한 코딩을 하거나 또는 다른 사람이 따라야 할 충분한 문서를 작성하지 않은 경우에 발생합니다. 여기서 한가지 개발자를 위한 별 볼일 없는 장점은 이 위험의 유행 가능성은 일반적이라는 것이며, 그 탐지 가능성이 낮습니다. 해커는 열악한 코딩 패턴을 쉽게 연구 할 수 없으며 종종 수동 분석이 필요합니다. 이러한 과정은 결코 쉽지 않습니다. 퍼지 테스트를 사용하여 메모리 누수 또는 버퍼 오버플로우를 식별하는데 사용되는 자동화 도구는 정보 액세스에는 도움이 되지만 모바일 디바이스에서 외부 코드의 실행을 쉽게 허용하지는 않습니다.

열악한 코드 품질의 리스크

안전한 웹 코드가 모바일내에서 손상됨

모바일 코드는 모바일 디바이스내에서 코드 하위 집합이 호출될 때마다 위협원(threat agent)이 신뢰할 수 없는 입력을 푸시하도록 하여 웹 브라우저에서 잘 작동하는 안전한 앱을 손상시킬 수 있습니다. 그와 같은 모바일 코드는 악의적이지 않지만 디바이스에서 신뢰할 수 없는 코드를 실행하게 함으로써 사용자 정보를 심각하게 손상시킬 수 있습니다. 이 범주의 일반적인 취약점에는 메모리 누수 및 버퍼 오버플로우가 포함됩니다.

3rd party 라이브러리의 빈틈

개발자는 널리 사용되는 라이브러리를 앱에 통합할 때 주의해야 합니다. 기존에 사용 경험이 있는 플레이어 조차도 실수로 앱 소유자에게 보안 문제가 발생할 수 있는 라이브러리를 제공할 수도 있습니다. 종종 개발자는 3rd party 라이브러리 개발자가 이전 버전의 잘못된 코드를 수정했을 수 있는 라이브러리의 최신 버전을 지속적으로 추적하지 않아서, 공격자가 쉽게 보호된 앱을 악용할 수 있는 빌미를 제공하기도 합니다.

클라이언트 입력 불안정

특정 클라이언트용으로 만들어진 앱에서 개발자는 모든 입력을 안전한 것으로 받아들이는 코드를 작성합니다. 콘텐츠 프로바이더 호출 과정에 중요한 정보가 포함될 수 있기 때문에, 이러한 코딩 방법은 콘텐츠 공급자 공격으로 이어질 수 있습니다. 따라서 공격자는 콘텐츠 프로바이더 호출을 이용하여 보안되지 않은 정보에 대한 액세스 권한을 얻을 수 있습니다.

M7: 열악한 코드 품질 예

열악한 코드 품질을 피하는 모범 사례

모바일 전용 코드

이 문제를 해결하는 가장 간단한 해결책은 서버 쪽에서 문제를 해결하기 보다는 모바일 디바이스에서 코드를 다시 작성하는 것입니다. 개발자는 서버측의 불량 코딩이 클라이언트측의 불량 코딩과는 다르다는 점을 명심해야 합니다. 서버 측의 코드 문제는 앱의 웹 뷰에도 반영되지만 모바일 측 불량 코딩은 모바일 사용자에게만 영향을 미칩니다.

정적 분석

개발자는 메모리 누수와 버퍼 오버플로우를 식별할 수 있는 3rd party 정적 분석 도구를 지속적으로 사용해야 합니다. 개발팀은 수신 버퍼 데이터 길이와 타겟 버퍼 사이의 불일치를 근절해야 합니다.

코드 로직

해커가 iOS 및 안드로이드 디바이스내에서 가장 좋아하는 것으로 알려진 단순한 코드 로직을 개발자는 피해야 합니다. 해커는 간단한 로직으로 코드의 값을 변경하고 전체 보안 장치를 우회할 수 있습니다. 이러한 코드는 어셈블리 및 런타임 수준에서 공격받을 수 있습니다. 개발자는 신뢰할 수 없는 세션이 디바이스 레벨에서 권한을 갖지 못하게 하고, 대신 이를 서버에서 활성화함으로써 이와같은 누수를 제어할 수 있습니다. OTP, 비밀 질문이나 과제를 사용하여 세션 인증이 완료될 때까지 권한을 보류하는 것이 좋습니다.

라이브러리 버전

개발팀은 신뢰할 수 있는 출처의 라이브러리만 사용한 경우에도 앱에 사용된 모든 3rd party 라이브러리 목록을 만들고 최신 버전을 정기적으로 확인해야 합니다.

콘텐츠 프로바이더

개발자는 모든 클라이언트 입력을 신뢰할 수 없는 것으로 간주하고 그 입력이 앱 또는 사용자인지에 관계없이 유효성을 항상 검사해야 합니다. 모든 승인 없는 액세스를 중지하려면 콘텐츠 프로바이더 권한 플래그를 신중하게 설정해야 합니다.

M8: 코드 변조

해커는 앱이나 사용자 행동 또는 전체 모바일 디바이스에 대한 무제한 접근 권한을 얻을 수 있기 때문에 다른 형태의 조작보다 앱의 코드 변조를 선호합니다. 해커는 피싱 공격과 오해의 소지가 있는 광고를 이용해서 3rd party 앱스토어에서 인기있는 앱의 변조된 버전을 다운로드 하도록 사용자들을 유도하는 경향이 있습니다.

코드 변조의 리스크

악성 코드 주입

사용자가 변조된 앱을 다운로드 하였다는 메시지를 본다면, 이는 코어 바이너리가 조작되었거나 리소스 패키지가 조작된 변조된 앱을 다운로드하여 설치한 것입니다. 해커는 변조된 앱을 통해 시스템 API를 변경하여 모바일 디바이스에서 악의적인 외부 코드를 실행할 수 있습니다. 해커는 바이너리 패치, 디바이스의 상주 코드 수정, 메모리 수정 및 데이터 탈취를 수행하는 경향이 있습니다.

데이터 도난

원래 앱에는 존재하지 않은 추가 기능이 변조된 앱에는 제공되는 경우가 많습니다. 이는 사용자가 변조된 앱을 사용하는 동기가 되기도 합니다. 변조된 앱의 보급은 매우 일반적이므로 회사는 앱 스토어에서 중복된 앱을 감지 및 제거하고 가능한 데이터 도난 시나리오에 대해 사용자를 교육하는데 많은 양의 리소스를 투자합니다.

그러나 앱의 코드는 외부에서 살펴볼 수 없는 환경에 있어야 합니다. 해커는 운영 체제의 빈틈을 악용하여 합법적인 앱의 코드에 영향을 줄 수 있습니다. 또한 사용자가 디바이스의 루팅 또는 탈옥을 허용하는 경우 의도적으로 3rd party 라이브러리가 디바이스내에 상주하도록 코드를 조작하기도 합니다.

개발자는 모든 변조가 바람직하지 않다는 결론을 내리지 않아야 합니다. 어떤 경우에는 결과가 중요하지 않을 수 있지만, 어떤 경우에는 사용자가 일부러 고의적으로 사용할 수 있습니다. 그러나 금융 또는 게임앱의 경우 개발자는 더욱 주의해야 합니다. 예를 들어 게임앱에서 변조된 기능을 통해 사용자는 부분유료화(freemium) 옵션을 우회하여 반드시 결제를 해야만 도달할 수 있는 다음 단계로 바로 넘어갈 수 있습니다. 해커는 사용자에게 유리한 제안을 통해 스파이웨어를 디바이스에 쉽게 설치하고 사용자 정보를 훔칠 수 있습니다.

M8: 코드 변조 예

코드 변조 방지를 위한 모범 사례

런타임 감지

개발자는 앱이 런타임에 코드 변경을 감지 할 수 있도록 만들어야 합니다. 만약 루팅 및 탈옥된 디바이스에서 구동하는 변조된 앱의 경우, 개발자가 이러한 종류의 실행을 허용하지 않으려면 런타임시에 서버에 이러한 손상을 보고하도록 하는 것이 가장 좋습니다. RASP는 개발자가 실시간으로 공격 경로를 탐지하고 저지하는 데 사용할 수 있는 기술 중 하나입니다.

체크섬 변경

개발자는 체크섬을 사용하고 디지털 서명을 평가하여 파일 변조가 발생했는지 확인해야 합니다. 코드와 파일 변조는 거의 항상 체크섬 값을 변경하기 때문에 악의적인 행위 여부를 결정하는 가장 쉬운 방법입니다.

데이터 삭제

변조가 감지되면 앱 코드, 키 및 데이터가 지워지도록 보장하십시오. 이러한 조항은 해커가 동일한 앱을 다시 대상으로 삼는 것을 방해하고 해킹의 근본 원인을 파괴합니다.

M9: 리버스 엔지니어링

일반적으로 모바일 코드를 악용하기 위해서 리버스 엔지니어링 기술을 사용합니다. 해커는 IDA Pro, Hopper, otool 등과 같이 일반적으로 사용 가능한 외부 바이너리 검사 도구를 사용하여 원본 앱의 코드 패턴과 서버 프로세스와의 링크를 연구합니다.

리버스 엔지니어링의 리스크

런타임시 동적 검사

Java, .NET, Objective C, Swift와 같은 일부 언어는 런타임시 동적 검사가 가능하기 때문에 다른 언어보다 리버스 엔지니어링에 더 취약합니다. 리버싱된 코드는 서버의 보안, 모바일 디바이스에 포함된 데이터의 보안 및 탈옥 또는 루팅된 디바이스를 감지하는 서버의 기능에 영향을 줄 수 있습니다.

코드 절도

앱 서비스 업체는 리버스 엔지니어링을 사용하여 경쟁사 앱의 기능을 파악하고 일부 기능을 몰래 복사 할 수도 있습니다. 이런 방식으로 새로운 코드 개발 비용은 절감될 수 있습니다.

프리미엄(Premium) 기능

해커는 리버스 엔지니어링 기술을 사용하여 인증 프로세스를 우회하여 앱의 프리미엄 기능에 액세스 할 수 있습니다. 게임 치트는 이러한 기술을 사용하여 경쟁자에 비해 불공평 한 이점을 얻는 행위를 의미합니다.

M9: 리버스 엔지니어링 예

리버스 엔지니어링을 피하는 모범 사례

유사한 도구 사용

리버스 엔지니어링으로부터 앱을 보호하는 가장 좋은 방법은 해커가 리버스 엔지니어링을 시도하는데 사용하는 것과 동일한 도구를 사용하는 것입니다. 이러한 도구가 앱의 문자열 테이블, 제어 흐름 경로, 서버와의 상호 작용, 암호화 상수 및 비밀번호, 메타 데이터 등을 쉽게 분석 할 수 있으면 코드가 손상된다고 여길 수 있습니다. 개발자는 앱실링(https://www.appsealing.com)과 같은 도구를 사용하여 실시간 리버스 엔지니어링 시도를 감지할 수도 있습니다.

코드 난독화

난독화 프로세스는 소스 코드와 문자열 테이블 및 코드 성능에 가장 영향을 덜 미치는 메소드의 특정 세그먼트를 대상으로 해야 합니다. 개발자는 공격자가 IDA Pro 및 Hopper와 같은 역난독화(de-obfuscation) 도구를 사용하여 난독화된 코드를 쉽게 원래 코드로 바꿀 수 없도록 해야 합니다.

C 언어 사용

런타임 변조에 큰 도움이 될 수 있는 C 및 C++ 사용을 고려하십시오. 이 두 언어의 많은 라이브러리가 Objective C와 쉽게 통합 됩니다. 안드로이드 앱에 대한 유사한 접근 방식은 JNI(Java Native Interface)를 사용하는 것입니다. C 및 C++ 라이브러리를 사용하는 목적은 class-dump, class-dump-z, Cycript 또는 Frida와 같은 런타임 또는 리버스 엔지니어링 도구로부터 보호하기 위함입니다.

M10: 관련없는 기능

앱을 상품화할 준비가 되기 전에, 개발팀은 백엔드 서버에 쉽게 액세스하고 오류 분석을 용이하게 하기 위한 로그를 만들거나 스테이징 정보 및 테스트 세부 정보를 전달하기 위한 코드를 종종 만듭니다. 이 코드는 앱의 기능과 관련이 없습니다. 즉, 앱이 제작되고 개발주기 동안에만 사용될 뿐, 의도적으로 사용자를 위해서 해당 기능을 사용하지 않습니다.