실제 사례를 통해 OWASP Mobile 상위 10가지 위험 이해

게시 됨: 2020-01-28

100% 해킹 방지 애플리케이션을 개발한 업계 기록을 보유하는 것은 우리 이름으로 개발된 디지털 솔루션 중 어느 것도 보안 침해에 직면하지 않을 것이라는 책임과 기본 보장을 수반합니다.

이를 달성하기 위한 방법으로 Appinventiv의 품질 보증 팀은 앱이 직면할 수 있는 모든 가능한 보안 위험에 대해 잘 알고 있습니다. 위험을 알면 함정을 쉽게 무시하고 안전한 앱을 작성할 수 있습니다.

OWASP 보안 코딩 사례 (Open Web Application Security Project) 에 대한 완전한 지식을 갖추는 것은 보안을 보장할 때 최고의 자리에 설 수 있도록 돕는 것입니다 . 보안 모바일 및 웹 애플리케이션을 구축하기 위한 무료 문서, 학습 자료 및 도구를 개발한 보안 전문가의 온라인 커뮤니티입니다.

다른 것들과 함께 모바일 애플리케이션의 OWASP Mobile Top 10 보안 위협 목록도 작성했습니다.

OWASP 보안 관행 문서는 상당히 명확 하지만 기업이 실제 사례와 연결하기 어려울 수 있습니다.

이 기사에서는 상위 10가지 모바일 보안 위험에 대한 기본 개요를 제공하고 각 위험에 대해 실제로 공개된 취약점의 예를 제공합니다. 이것은 Appinventiv가 귀하의 애플리케이션을 작업할 때 무엇을 준비하는지에 대한 통찰력을 제공할 것입니다.

위험을 살펴보기 전에 통계를 살펴보겠습니다.

NowSecure 는 Google Play 스토어 및 앱 스토어에서 앱을 조사한 결과 85% 이상의 앱이 위험 중 하나를 위반하는 것으로 나타났습니다.

이러한 애플리케이션 중 50%는 안전하지 않은 데이터 저장소를 가지고 있었고 어딘가에서 동일한 수의 앱이 안전하지 않은 통신 위험 과 함께 작동하고 있었습니다 . 다음은 OWASP Mobile Top 10 위험 의 발생 비율을 보여주는 그래프입니다.

owasp mobile top 10 voilation rates

모바일 애플리케이션에 대한 가장 일반적인 10가지 위협 및 이를 방지하기 위한 모범 사례 목록

M1: 부적절한 플랫폼 사용

OWASP 보안 테스트 의 범주는 장치 기능의 오용 또는 플랫폼의 보안 제어 사용 시 실패 사례로 구성됩니다. 여기에는 플랫폼 권한, Android 의도, TouchID 오용, 키체인 등이 포함될 수 있습니다.

실제 사례:

세 가지 iOS 앱 : "피트니스 균형 앱", "심박수 모니터" 및 "칼로리 추적기 앱"이 Apple의 Touch ID를 우회하기 위해 빛을 발했습니다. 그들은 사용자에게 지문을 사용하여 피트니스 정보를 얻으라고 요청하고 앱 스토어에서 돈을 청구하는 데 사용했습니다.

피해야 할 모범 사례:

개발자는 서버 경로를 통한 키체인 암호화를 허용하지 않고 키를 한 장치에만 보관하여 다른 서버나 장치에서 악용되지 않도록 해야 합니다.
개발자는 전용 액세스 제어 목록이 있는 앱의 비밀을 저장하기 위해 키체인을 통해 앱을 보호해야 합니다.
개발자는 자신의 애플리케이션과 통신할 수 있는 앱을 제한하는 권한을 받아야 합니다.
개발자는 명시적 의도를 정의하고 의도에 있는 정보에 액세스하는 다른 모든 구성 요소를 차단하여 OWASP Mobile Top 10 목록의 첫 번째 항목을 제어해야 합니다.

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

OWASP는 누군가가 분실/도난된 모바일 장치에 액세스하거나 맬웨어 또는 다른 재패키지 앱이 공격자를 대신하여 행동하기 시작하고 모바일 장치에서 작업을 실행할 때 위협으로 간주합니다.

안전하지 않은 데이터 저장 취약점은 일반적으로 다음과 같은 위험을 초래합니다.

사기
신분 도용
물질적 손실.
평판 손상
외부 정책 위반(PCI)

실제 사례 :

Tinder, OKCupid 및 Bumble과 같은 데이트 앱은 안전하지 않은 데이터 저장 방식으로 인해 계속해서 조사를 받았습니다. 이러한 앱에 존재하는 보안 결함은 실행 가능성, 심각도 및 실행 가능성에 따라 다르며, 다른 개인 계정 활동 외에도 사용자 이름, 로그인 세부 정보, 메시지 기록 및 위치까지 노출될 수 있습니다.

피해야 할 모범 사례:

iOS의 경우 OWASP 보안 관행 은 개발 프레임워크와 앱을 위협 모델로 삼기 위해 iGoat와 같이 의도적으로 만들어진 취약한 앱을 사용할 것을 권장합니다. 이것은 ios 앱 개발자 가 API가 앱 프로세스 및 정보 자산을 처리하는 방법을 이해하는 데 도움이 됩니다.
Android 앱 개발자 는 Android 디버그 브리지 셸을 사용하여 대상 앱의 파일 권한을 확인하고 DBMS를 사용하여 데이터베이스 암호화를 확인할 수 있습니다. 또한 메모리 분석 도구 및 Android Device Monitor를 사용하여 기기 메모리에 의도하지 않은 데이터가 없는지 확인해야 합니다.

M3: 불안정한 통신

모바일 앱을 개발할 때 데이터는 클라이언트-서버 모델로 교환됩니다. 따라서 데이터가 전송될 때 먼저 장치의 통신사 네트워크와 인터넷을 통과해야 합니다. 위협 에이전트는 유선을 통해 이동하는 동안 취약점을 악용하고 민감한 데이터를 가로챌 수 있습니다. 존재하는 다양한 위협 에이전트는 다음과 같습니다.

로컬 네트워크를 공유하는 공격자 – 손상된 Wi-Fi
네트워크 또는 캐리어 장치 – 기지국, 프록시, 라우터 등
모바일 장치의 맬웨어.

통신 채널을 통한 민감한 데이터 가로채기는 개인정보 침해로 이어지며 다음과 같은 결과를 초래할 수 있습니다.

신분 도용
사기
평판 손상.

실제 사례:

Rapid7 보안 회사 는 어린이용 스마트워치에 부착된 몇 가지 취약점을 공개했습니다 . 그 시계는 부모가 자녀를 추적하고 메시지를 보내거나 스마트 워치로 전화를 걸기 위해 사용하는 것으로 판매되었습니다.

화이트리스트 방식으로 승인된 연락처로 시계에 연락을 하기로 되어 있었는데 회사에서 필터가 작동하지 않는다는 사실을 알게 되었습니다. 이 시계는 문자 메시지를 통한 구성 명령도 수락했습니다. 이는 해커가 시계 설정을 변경하고 어린이를 위험에 빠뜨릴 수 있음을 의미했습니다.

Rapid7의 IoT 연구 책임자인 Deral Heiland는 "전화나 아이가 어디에 있는지 식별하고 오디오에 액세스하거나 어린이에게 전화를 걸 수 있습니다.

피해야 할 모범 사례:

개발자는 앱과 서버 간에 통신하는 트래픽의 누출뿐만 아니라 앱과 다른 장치 또는 로컬 네트워크를 보유하는 장치도 찾아야 합니다.
채널 전송에 TLS/SSL을 적용하는 것도 민감한 정보 및 기타 민감한 데이터를 전송할 때 고려해야 할 모바일 앱 보안 모범 사례 중 하나입니다.
신뢰할 수 있는 SSL 체인 확인에서 제공한 인증서를 사용합니다.
MMS, SMS 또는 푸시 알림과 같은 대체 채널을 통해 민감한 데이터를 보내지 마십시오.
SSL 채널에 제공하기 전에 민감한 데이터에 별도의 암호화 계층을 적용합니다.

M4: 안전하지 않은 인증

인증 취약점을 악용하는 위협 에이전트는 맞춤형 또는 사용 가능한 도구를 사용하는 자동화된 공격을 통해 그렇게 합니다.

M4가 비즈니스에 미치는 영향은 다음과 같습니다.

정보 도용
평판 손상
데이터에 대한 무단 액세스.

실제 사례 :

2019년 미국 은행은 은행의 웹사이트 결함을 이용하여 계정 보호를 위해 구현된 2단계 인증을 우회한 사이버 공격자에 의해 해킹을 당했습니다.

공격자는 도난당한 피해자 자격 증명을 통해 시스템에 로그인했으며 PIN 또는 보안 응답을 입력해야 하는 페이지에 도달한 후 공격자는 웹 URL에서 조작된 문자열을 사용하여 컴퓨터를 인식된 것으로 설정했습니다. 이를 통해 그는 무대를 건너 전신 송금을 시작할 수 있었습니다.

피해야 할 모범 사례:

앱 보안팀은 앱 인증을 연구하고 악용 가능 여부를 판별하기 위해 오프라인 모드에서 바이너리 공격을 통해 테스트해야 합니다.
OWASP 웹 애플리케이션 테스트 보안 프로토콜은 모바일 앱 의 보안 프로토콜과 일치해야 합니다.
웹 브라우저의 경우와 마찬가지로 최대한 온라인 인증 방식을 사용합니다.
서버가 사용자 세션을 인증할 때까지 앱 데이터 로드를 활성화하지 마십시오.
로컬 데이터가 최종적으로 사용되는 위치에서 사용자 로그인 자격 증명에서 파생된 암호화된 키를 통해 암호화되었는지 확인합니다.
영구 인증 요청도 서버에 저장해야 합니다.
보안 팀은 앱에서 기기 중심 인증 토큰에 주의해야 합니다. 기기를 도난당하면 앱이 취약해질 수 있기 때문입니다.
장치에 대한 무단 물리적 액세스가 일반적이므로 보안 팀은 서버 측에서 정기적인 사용자 자격 증명 인증을 시행해야 합니다.

M5: 불충분한 암호화 위험

이 경우 위협원은 잘못 암호화된 데이터에 물리적으로 접근하는 사람입니다. 또는 악성코드가 공격자를 대신하여 행동하는 경우.

깨진 암호화는 일반적으로 다음과 같은 경우를 초래합니다.

정보 도용
지적 재산권 도용
코드 도용
개인정보 침해
평판 손상.

실제 사례 :

때때로 DHS Industrial Control Systems의 사이버 비상 대응 팀과 Philips 권고의 경고는 Philips HealthSuite Health Android 앱 의 가능한 취약성에 대해 사용자에게 경고 했습니다.

부적절한 암호화 강도로 추적된 문제는 사용자의 심박수 활동, 혈압, 수면 상태, 체중 및 체성분 분석 등에 액세스할 수 있는 해커에게 앱을 열었습니다.

피해야 할 모범 사례:

가장 일반적으로 발생하는 OWASP Top 10 Mobile 위험 중 하나를 해결하려면 개발자는 앱 암호화를 위한 최신 암호화 알고리즘을 선택해야 합니다. 알고리즘의 선택은 취약성을 상당 부분 처리합니다.
개발자가 보안 전문가가 아닌 경우 자체 암호화 코드 생성을 자제해야 합니다.

M6: 안전하지 않은 승인 위험

이 경우 위협 에이전트는 일반적으로 맞춤형 또는 사용 가능한 도구를 사용하는 자동화된 공격을 통해 다른 사람의 애플리케이션에 액세스할 수 있습니다.

다음과 같은 문제가 발생할 수 있습니다.

정보 도용
평판 손상
사기

실제 사례 :

Pen Test Partners의 정보 보안 전문가 는 스마트 자동차 경보 시스템인 Pandora 를 해킹 했습니다. 이론적으로 애플리케이션은 자동차를 추적하고 도난당한 경우 엔진을 차단하고 경찰이 도착할 때까지 잠그는 데 사용됩니다.

동전의 다른 면에서 해커는 계정을 가로채고 모든 데이터와 스마트 알람 기능에 액세스할 수 있습니다. 또한 다음을 수행할 수 있습니다.

차량 움직임 추적
경보 시스템 활성화 및 비활성화
자동차 도어 잠금 및 잠금 해제
엔진을 잘라
Pandora의 경우 해커는 도난 방지 시스템의 마이크를 통해 차 안에서 이야기되는 모든 것에 접근할 수 있었습니다.

피해야 할 모범 사례:

QA 팀 은 민감한 명령에 대해 낮은 권한 세션 토큰을 실행하여 사용자 권한을 정기적으로 테스트해야 합니다.
개발자는 오프라인 모드에서 사용자 인증 체계가 잘못된다는 점에 유의해야 합니다.
이러한 위험을 방지하는 가장 좋은 방법은 모바일 장치 대신 서버에서 인증된 사용자의 권한 및 역할에 대한 권한 부여 검사를 실행하는 것입니다.

M7: 불량한 코드 품질 위험

이러한 경우 신뢰할 수 없는 입력은 엔터티에 의해 모바일 코드에서 수행된 메서드 호출로 전달됩니다. 그 결과 성능 저하, 과도한 메모리 사용 및 작동하지 않는 프런트 엔드 아키텍처로 이어질 수 있는 기술적인 문제가 발생할 수 있습니다.

실제 사례 :

WhatsApp 은 작년에 해커가 스마트폰에 Pegasus Spyware라는 감시 멀웨어를 설치하기 위해 악용하는 취약점을 패치했습니다. 대상 전화번호로 WhatsApp 음성 통화를 하기만 하면 됩니다.

간단한 몇 단계 만에 해커가 사용자의 장치에 침입하여 원격으로 액세스할 수 있었습니다.

피해야 할 모범 사례:

OWASP 보안 코딩 관행 에 따르면 코드는 서버 측에서 수정하는 대신 모바일 장치에서 다시 작성해야 합니다. 개발자는 서버 측의 잘못된 코딩과 클라이언트 수준의 잘못된 코딩이 매우 다르다는 점에 유의해야 합니다. 즉, 약한 서버 측 컨트롤 과 클라이언트 측 컨트롤 모두 별도의 주의를 기울여야 합니다.
개발자는 버퍼 오버플로 및 메모리 누수를 식별하기 위해 정적 분석을 위한 타사 도구를 사용해야 합니다.
팀은 타사 라이브러리 목록을 만들고 정기적으로 최신 버전을 확인해야 합니다.
개발자는 모든 클라이언트 입력을 신뢰할 수 없는 것으로 보고 사용자 또는 앱에서 왔는지 여부에 관계없이 유효성을 검사해야 합니다.

M8: 코드 변조 위험

일반적으로 이 경우 공격자는 타사 앱 스토어에서 호스팅되는 악성 형태의 앱을 통해 코드 수정을 악용합니다. 또한 사용자가 피싱 공격을 통해 애플리케이션을 설치하도록 속일 수도 있습니다.

피해야 할 모범 사례:

개발자는 앱이 런타임에 코드 변경 사항을 감지할 수 있는지 확인해야 합니다.
Android에 비공식 ROM이 있는지 확인하고 기기가 루팅되었는지 확인하려면 build.prop 파일을 확인해야 합니다.
개발자는 체크섬을 사용하고 디지털 서명을 평가하여 파일 변조가 발생했는지 확인해야 합니다.
코더는 변조가 발견되면 앱 키, 코드 및 데이터가 제거되었는지 확인할 수 있습니다.

M9: 리버스 엔지니어링 위험

공격자는 일반적으로 앱 스토어에서 대상 앱을 다운로드하고 다양한 도구 모음을 사용하여 로컬 환경 내에서 이를 분석합니다. 그런 다음 코드를 변경하고 앱 기능을 다르게 만들 수 있습니다.

실제 사례 :

Pokemon Go 는 최근 사용자가 앱을 리버스 엔지니어링하여 포켓몬 주변을 알고 몇 분 만에 잡는 것으로 밝혀졌을 때 보안 침해 눈에 직면했습니다.

피해야 할 모범 사례:

OWASP 모바일 보안 에 따르면 위험으로부터 앱을 보호하는 가장 좋은 방법 은 해커가 리버스 엔지니어링에 사용하는 것과 동일한 도구를 사용하는 것입니다.
또한 개발자는 소스 코드를 난독화하여 읽기 어렵게 만든 다음 리버스 엔지니어링해야 합니다.

M10: 관련 없는 기능 위험

일반적으로 해커는 백엔드 시스템의 숨겨진 기능을 찾기 위해 모바일 앱 내부의 관련 없는 기능을 살펴봅니다. 공격자는 최종 사용자의 개입 없이 자체 시스템의 관련 없는 기능을 악용합니다.

실제 사례 :

Wifi 파일 전송 앱의 아이디어는 Android에서 포트를 열고 컴퓨터에서 연결할 수 있도록 하는 것이었습니다. 문제 ? 암호와 같은 인증이 없으면 누구나 장치에 연결하여 전체 액세스 권한을 얻을 수 있습니다.

피해야 할 모범 사례:

최종 빌드에 테스트 코드가 없는지 확인
구성 설정에 숨겨진 스위치가 없는지 확인하십시오.
로그에는 백엔드 서버 프로세스 설명이 포함되어서는 안 됩니다.
전체 시스템 로그가 OEM에 의해 앱에 노출되지 않도록 합니다.
API 끝점은 잘 문서화되어야 합니다.