앱 개발자를 위협하는 10가지 보안 위험과 대응 방법

국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하고 있을까요?

이번 글에서는 디지털 보안 솔루현 전문 기업 ‘잉카엔트웍스’의 ‘앱실링’ 서비스 팀이 웹 애플리케이션 보안 국제 비영리단체 오픈 웹 애플리케이션 보안 프로젝트(OWASP)가 꼽은 중요 보안 위험 표준 가이드라인 OWASP Top10을 소개하고 대응 방법을 제안합니다. 

모바일 앱 서비스 대부분은 ‘초개인화’에 집중하고 있습니다. 개인화된 제품이나 서비스를 제공해 고객 만족도를 높일 수 있기 때문인데요. 이를 위해서 앱에서는 유저의 은행 정보, 개인 식별 정보 등 개인 정보를 수집하게 됩니다. 특히 개인 정보는 경제적 가치가 있는 데이터라 탈취하려는 해커들의 위협도 날로 심각해지고 있습니다. 그리고 피해는 유저뿐 아니라 시스템, 데이터 등과 같이 기술적 부분에서도 발생해 결국 비즈니스 측면에 부정적 영향이 끼쳐집니다. 그렇기에 모바일 앱 개발자라면 다양한 모바일 앱 보안 위험에 대한 포괄적인 이해가 필수입니다!

미국의 비영리단체OWASP(Open Web Application Security Project)는 웹과 모바일 애플리케이션 보안과 취약점 등을 연구하며 10대 웹/모바일 애플리케이션 취약점(OWASP Top 10)을 발표하고 있습니다. 2016년 10대 모바일 위협에 대해 발표한 후, OWASP Mobile Top 10 2024를 아래와 같이 공개했습니다.

OWASP Mobile Top 10 2024

1. 부적절한 자격 증명 사용(Improper Credential Usage)
2. 불충분한 공급망 보안(Inadequate Supply Chain Security)
3. 보안에 취약한 인증 및 권한 부여(Insecure Authentication/Authorization)
4. 부족한 입력/출력 검증(Insufficient Input/Output Validation)
5. 안전하지 않은 통신(Insecure Communication)
6. 불충분한 개인 정보 보호 제어(Inadequate Privacy Controls)
7. 부족한 바이너리 보호(Insufficient Binary Protections)
8. 잘못된 보안 구성(Security Misconfiguration)
9. 안전하지 않은 데이터 저장소(Insecure Data Storage)
10. 불충분한 암호화(Insufficient Cryptography)

(참고) 업데이트 전후 비교표

1. 부적절한 자격 증명 사용

개요

하드코딩(코드 내부에 데이터를 직접 입력하는 것)된 자격 증명을 사용하거나 안전하지 않은 자격 증명 관리할 경우 위협에 노출됩니다. 다음과 같은 요소로 자격 증명을 관리하고 있다면, 여러분의 모바일 앱은 보안에 취약할 가능성이 높습니다.

보안 취약점이 나타나는 환경

• 하드코딩된 자격 증명: 모바일 앱에 소스 코드나 구성 파일 내에 하드코딩된 자격 증명을 포함하는 경우
• 불안전한 자격 증명 전송: 자격 증명이 암호화되지 않거나 보안이 보장되지 않는 채널을 통해 전송하는 경우
• 보안이 보장되지 않은 자격 증명 저장: 모바일 앱이 사용자 자격 증명을 안전하지 않은 방식으로 기기에 저장된 경우
• 약한 사용자 인증: 사용자 인증이 약한 프로토콜에 의존하거나 우회가 쉬운 경우

대응 방안

1. 하드코딩된 자격 증명 사용은 NO!
하드코딩된 자격 증명은 해커들에 의해 쉽게 발견되어 미승인된 유저에게 액세스 권한을 제공할 수 있습니다. 모바일 앱 코드나 구성 파일에 하드코딩된 자격 증명을 사용하지 않도록 노력해야 합니다.

2. 안전한 자격 증명 관리
사용자 자격 증명 관리는 안전하게 저장, 전송, 인증되어야 합니다. 전송 중에는 자격 증명을 반드시 암호화해야 하며, 기기에 바로 저장하지 않고, 안전하게 취소 가능한 액세스 토큰 사용을 고려해야 합니다. 또한 사용 중인 모든 API 키나 토큰은 정기적으로 업데이트하여 보안 위협을 완화할 수 있습니다.

2. 불충분한 공급망 보안

개요

해커는 모바일 앱의 코드베이스에 악성 코드를 추가하거나, 빌드 프로세스 중 코드를 수정해 백도어, 스파이웨어 등 다른 악성 코드를 삽입하여 공격합니다. 이를 통해 앱 서명 키, 인증서가 악성 코드를 신뢰하게 됩니다. 해커는 데이터를 도용하거나 유저들을 감시하는 것은 물론 그들의 모바일 기기를 맘대로 통제할 수 있습니다. 특히 서드파티(3rd-party)에서 개발한 모바일 앱, 라이브러리 및 구성 요소에 의존하는 경우 더욱 취약점에 노출됩니다.

보안 취약점이 나타나는 환경

• 서드파티 구성 요소에서의 보안 부족: 모바일 앱 개발자가 서드파티 라이브러리나 프레임워크와 같은 구성 요소를 적절하게 검토하거나 업데이트하지 않는 경우
• 악의성 있는 내부 위협: 개발자가 공급망 프로세스에 적절한 보안 통제와 모니터링을 구현하지 않았을 경우
• 불충분한 테스트 및 검증: 개발자가 앱을 충분히 테스트하지 않거나 공급망 프로세스 보안을 검증하지 않은 경우
• 보안 인식 부족: 앱 개발자가 충분한 보안 인식을 가지고 있지 않다면, 공격에 대비하는 필수적인 보안 통제를 구현하지 못하는 경우

대응 방안

1. 안전한 코딩 관행 및 검토
모바일 앱 개발 주기 동안 안전한 코딩 관행, 코드 검토 및 테스팅을 실시하여 취약점을 식별합니다.

2. 앱 서명 및 배포 프로세스 보안
해커가 악성 코드를 배포하고 서명하는 것을 방지하기 위해 안전한 앱 서명 및 배포 프로세스를 구현합니다.

3. 신뢰할 수 있는 제 3자 라이브러리 사용
취약성의 위험을 줄이기 위해 신뢰할 수 있는 서드파티의 라이브러리나 구성 요소만 사용합니다.

4. 앱 업데이트 및 패치 보안 제어
앱의 취약점을 방지하기 위해 앱 업데이트, 패치 및 릴리스에 대한 보안 제어를 구현합니다.

5. 공급망 보안 사고 모니터링 및 대응
서드파티 공급망 보안 사고를 신속하게 감지하고 대응하기 위해 보안 테스팅, 스캔 또는 기타 기술을 사용합니다.

3. 보안에 취약한 인증 및 권한 부여

개요

모바일 앱 보안을 평가하는 데 있어 ‘인증’과 ‘권한’을 구별하는 것은 중요합니다. ‘인증’은 개인을 식별하고, ‘권한’은 특정 작업에 필요한 권한이 있는지 확인합니다. 즉, 모바일 기기에서 인증 요청하면 즉시 권한 확인으로 이어집니다.

보안 취약점이 나타나는 환경 – 인증

• 출처가 불분명한 백엔드 API 실행: 앱이 액세스 토큰 제공 없이 백엔드 API 서비스 요청을 실행하는 경우
• 비밀번호 로컬 저장: 앱이 장치에 비밀번호 등을 로컬로 저장
• 부실한 패스워드 정책: 암호 입력 과정을 간소화
• FaceID 또는 TouchID 기능 사용

보안 취약점이 나타나는 환경 – 권한 부여

• IDOR(Insecure Direct Object Reference, 부적절한 권한) 취약점의 존재: 코드가 적절한 권한 확인을 수행하지 않는 경우 IDOR 취약점 발견
• 숨겨진 엔드포인트:개발자가 백엔드의 숨겨진 기능에 대한 권한 확인을 무시할 경우
• 사용자 역할 혹은 권한 전달: 앱이 사용자의 역할이나 권한을 백엔드 시스템으로 전송하는 경우

대응 방안

1. 불안정한 모바일 애플리케이션 인증 패턴 피하기
웹 애플리케이션을 모바일로 이전하는 경우, 모바일 애플리케이션의 인증 요구사항이 웹 애플리케이션 구성 요소와 일치해야 합니다. 애플리케이션이 데이터를 로컬로 저장하면 사용자 인증을 클라이언트 측에서 우회할 수 있고, 런타임 조작이나 바이너리 수정을 통해 탈옥된 기기에서 이뤄지는 인증 방법 또한 우회될 수 있습니다. 클라이언트 측에 데이터 저장이 필요하다면, 유저의 로그인 자격 증명에서 안전하게 파생된 암호화 키를 사용해 암호화해야 합니다. 또한 사용자별 인증 토큰을 사용해야 하고, 사용자가 모바일 애플리케이션 내에서 폐기할 수 있도록 합니다. 장치에 비밀번호에 저장하는 것 또한 지양할 수 있도록 유도해야 합니다.

2. 인증 강화
개발자는 클라이언트 측의 인증과 권한 부여는 악의적인 유저에 의해 우회될 수 있음을 항상 염두해야 합니다. 그렇기에 인증과 권한 부여 컨트롤은 서버 쪽에 강화해 두어야 합니다. 오프라인 환경에서 모바일 앱이 로컬 인증이나 권한 확인을 수행해야 할 경우, 로컬 무결성을 확인해야 개발자 권한 없이 코드가 변경되는 것을 감지할 수 있습니다.

3. 불안정한 권한 부여 방지
백엔드 시스템의 인증과 권한 부여는 독립적으로 검증되어야 합니다. 또한 모든 클라이언트 측 권한이 우회될 수 있다고 가정하고, 서버 측 권한 부여 컨트롤을 강화하는 것이 좋습니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
권한 제어 차단 기능을 통해 애플리케이션의 적법성과 토큰을 안전하게 저장할 수 있습니다.

4. 부족한 입력/출력 검증

개요

사용자가 입력하거나 네트워크 데이터 등 외부 소스 데이터에 대한 충분한 검증을 하지 않으면 심각한 보안 취약점이 발생하게 됩니다. 이는 SQL 인젝션(가장 흔한 웹 해킹 공격법으로 공격자가 조작된 SQL 질의문을 삽입해 웹 서버 DB 정보를 열람하고 정보를 유출 및 조작), 커맨드 인젝션(웹 요청에 시스템 명령어를 보내 실행하도록 하는 공격) 그리고 사이트 간 스크립팅(웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점, XSS)과 같은 모바일 환경에 특화된 공격을 통해 악용될 수 있습니다. 민감한 데이터에 해커가 무단 액세스하고 앱 기능을 조작하며 전체 모바일 시스템 침해할 수 있습니다.

보안 취약점이 나타나는 환경

• 입력 검증 부재
• 출력 정보에 대한 보안 부족
• 맥락별 검증 부족: 맥락이나 데이터 형식을 고려하지 않으면 SQL 인젝션이나 경로 순회 공격, 파일에 무단 액세스 등 취약점이 발생
• 데이터 무결성 검증 미흡: 데이터 손상이나 무단 수정의 결과를 낳음
• 안전한 코딩 관행 부재: 매개변수화 된 쿼리를 사용하지 않거나 데이터의 이스케이핑, 인코딩 등을 무시하면 입력/출력 유효성 검사 취약점이 발생

 대응 방안

1. 입력 검증
엄격한 검증 기법을 사용하여 사용자 입력을 검증해야 합니다. 입력 길이 등을 제한해 악의적인 데이터는 거부될 수 있도록 합니다.

2. 출력 정보에 대한 보안
사이트 간 스크립팅(XSS) 공격을 방지하기 위해 출력 정보에 대한 보안은 필수입니다.

3. 맥락별 검증
데이터 맥락에 기반한 검증을 수행해 경로 순회 등 공격으로부터 예방합니다.

4. 안전한 코딩 관행
매개변수화된 쿼리 및 명령문을 사용하는 등 보안 코딩 방법에 따라야 합니다.

5. 정기적인 보안 테스트
침투 테스트 및 코드 검토 등 정기적인 보안 평가를 수행합니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
런타임 애플리케이션 자체 보호(Runtime Application Self Protection, RASP)는 애플리케이션 구성 요소의 데이터 흐름, 내부 아키텍처 및 실행 흐름에 대한 가시성으로 애플리케이션 내부에서 실시간 보호합니다. 이를 통해 SQL 인젝션, 악성 코드, XSS 등에 대한 보호 계층을 제공받을 수 있습니다.

5. 안전하지 않은 통신

개요

모바일 애플리케이션은 하나 이상의 원격 서버와 데이터를 교환합니다. 모바일 vs 모바일 통신, 앱 vs 서버 통신, 모바일 vs 다른 통신을 포함하며, 여기서 언급하는 통신은 TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, 오디오, 적외선, GSM, 3G, SMS 등 모바일 장치에서 사용할 수 있는 모든 통신 기술을 의미합니다. 해커는 이 접점을 통해 중간자 공격(Man In The Middle, MITM)으로 두 명 이상의 당사자 간 대화를 손쉽게 도청하거나 읽을 수 있습니다.

보안 취약점이 나타나는 환경

• 민감한 데이터를 패키징해 장치 안팎으로 전송: 민감한 데이터(암호화 키, 비밀번호, 사용자 정보, 세션 토큰 등)는 다양한 루트를 통해 교환되므로 그 사이에 일부 데이터가 탈취
• TLS 연결을 부적절하게 설정 및 검증: 인증서 확인, 약한 암호화, 기타 TLS 구성 문제 등은 안전하지 않은 통신에서 발생

대응 방안

1. SSL/TLS를 적용해 데이터 전송
네트워크 계층은 안전하지 않고 도청에 취약하다고 가정하고, 모바일 앱이 백엔드 API 또는 웹 서비스로 데이터를 전송할 때 SSL/TLS를 적용하도록 합니다. 브라우저/webkit을 통해 응용 프로그램이 실행될 때 외부 엔터티(서드파티 분석 업체, 소셜 네트워크 등)를 고려해 그들의 SSL 버전을 사용하고, 믹스된 SSL 세션은 사용자의 세션 ID를 노출시킬 수 있으므로 피합니다.

2. 적절한 키 및 신뢰할 수 있는 인증서 사용
적절한 키 길이와 강력하고 업계 표준 암호화 제품군을 사용해야 합니다. 신뢰할 수 있는 CA(Certificate Authority) 제공자에 의해 서명된 인증서를 사용하고 자체 서명이나 만료, 신뢰할 수 없는 루트, 잘못된 호스트 등의 올바르지 않은 인증서는 허용하지 않습니다. 모바일 앱에서 잘못된 인증서를 감지하면 사용자에게 경고할 수 있도록 합니다.

3. 민감한 데이터 전송 지양
민감한 데이터를 대체 채널(SMS, MMS, 또는 알림)을 통해 전송하지 않습니다. SSL 채널에 민감한 데이터가 제공되기 전에 별도의 암호화 계층을 적용하여 추후 SSL 구현에서 취약점이 발견되더라도 암호화된 데이터는 유출에 방어할 대안이 될 수 있습니다. 개발 중 불가피하게 신뢰할 수 없는 인증서를 허용하려면 자체 서명된 인증서나 신뢰할 수 있는 CA 공급자가 제공하는 인증서를 이용합니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
패킷 스니핑, 위변조 도구 탐지 기능을 통해 구현 계층에서 앱의 실행 여부와 상관없이 상시 안전한 통신 환경을 보장합니다.

6. 불충분한 개인 정보 보호 제어

개요

개인 식별 정보(Personally Identifiable Information, PII)를 보호하는 것과 관련이 있으며 이름과 주소, 신용 카드 정보, 이메일 및 IP 주소, 건강 정보, 종교, 성적 성향 및 정치적 의견 등이 대상입니다. 해커들은 정보를 이용해 불법 행위를 하고, 피해자에게 불이익을 주거나 자산 강탈 등 피해를 입힙니다. 앱에서 특정 형태의 개인 식별 정보를 처리하는 경우 이러한 위험에 노출됩니다. 앱에서의 PII는 서버에서 확인할 수 있는 클라이언트 앱의 IP 주소, 앱 사용 로그 등 메타데이터 대부분입니다.

보안 취약점이 나타나는 환경

• 안전하지 않은 데이터 저장소 및 통신
• 부적절한 자격 증명 및 보안에 취약한 인증 및 권한 부여
• 앱의 샌드박스에 대한 내부자 공격

대응 방안

1. 처리되는 PII를 최소화

앱 내에서 처리해야 하는 PII를 최소화하기 위해 정보 업데이트 시간 단위를 늘리거나 만료 기간이 지나면 빠르게 삭제하여 필수 사항을 제외하고 저장, 전송하지 않도록 합니다.

2. 중요한 데이터에 대한 심층 방어 고려

적절한 인증 및 권한 부여를 통해 보호되어야 합니다. 예를 들어 건강 데이터는 앱의 샌드박스 내 저장뿐만 아니라 기기의 TPM(Trusted Platform Module)에 봉인된 키로 암호화되어야 합니다. 이를 통해 공격자가 샌드박스 제한을 무시하는 경우에도 데이터는 판독되지 않습니다.

7. 부족한 바이너리 보호

개요

모든 앱은 바이너리 공격에 취약합니다. 일반적으로 앱스토어에서 다운로드하거나 모바일 기기에서 복사할 수 있어 바이너리 공격 설정이 쉽습니다. 앱 바이너리는 리버스 엔지니어링, 코드 변조와 같은 공격으로 나타납니다. 특히 인기 있는 앱은 앱스토어를 통해 조작되고 재배포될 가능성이 높습니다.

보안 취약점이 나타나는 환경

• 기본적으로 모든 앱은 바이너리 공격에 취약
• 하드코딩된 민감한 데이터나 알고리즘이 포함된 경우

대응 방안

1. 리버스 엔지니어링 대응
공격자들이 앱 바이너리를 이해할 수 없도록 해야 합니다. 이는 코드 암호화, 난독화 도구를 활용해 대응할 수 있습니다.

2. 보안 메커니즘 파괴
공격자들은 보안 검사를 건너뛰기 위해 앱의 전반적인 흐름을 이해해야 합니다. 암호화/난독화를 통해 보안에 큰 도움이 될 수 있습니다. 또한 로컬 보안 검사는 백엔드에서 강화해야 합니다. 예를 들어 요구된 리소스에 대한 검사가 로컬이나 백엔드에서 성공한 경우에만 다운로드를 허용하도록 합니다.

3. 무결성 검사
앱 시작 시 무결성 검사를 통해 앱 바이너리의 재배포 및 코드 조작을 감지할 수 있습니다. 이러한 위반 사항은 앱스토어에서 승인되지 않은 앱 복사본이 퍼지기 전에 제거하고 자동으로 보고할 수 있습니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
리버스 엔지니어링은 강력한 공격 감지 및 예방 전략은 물론 공격받은 애플리케이션을 비활성화하고 사용할 수 없도록 조치로 대응해야 하며, 아래 기능을 통해 구현할 수 있습니다.

 

• 정적 코드 암호화
• 동적 코드 암호화(메모리에 로드된 코드)
• 런타임 애플리케이션 자체 보호(Run-time Application Self Protection, RASP)
• 성공적인 앱 로딩 후 메모리에서 민감한 정보 제거
• 안티 디버깅
• 안티 메모리 덤프
• 안티 메모리 치트 (예: Gameguardian, Lucky Patcher, Freedom apk)
• 안티 후킹
• 안티 Frida 프레임워크
• 안티 Xposed 프레임워크

 

코드 변조 또한 자체 방어 기능, 적극적인 위협 감지 및 장치 바인딩은 다음을 통해 구현될 수 있습니다.

• 변조에 대한 보호
• 성능 변경에 대한 보호
• 바이너리 패치(바이너리의 내용을 수정해 다르게 동작하게 하는 것) 감지(무결성 확인)
• 동적 메모리 수정 감지
• 인앱 결제 크랙 감지

8. 잘못된 보안 구성

개요

무단 액세스로 이어질 수 있는 적절하지 않은 보안 설정, 권한과 제어 구성의 부적절함을 의미합니다. 약한 암호화, 해싱 알고리즘도 민감한 정보에 액세스 하는 것에 악용됩니다.

보안 취약점이 나타나는 환경

• 기본 설정 검토 무시: 보안 설정, 권한 및 기본 자격 증명을 검토하지 않고 기본 구성을 사용하는 경우
• 안전한 통신 부재: 암호화되지 않거나 약하게 암호화된 통신 채널 사용
• 취약하거나 존재하지 않는 액세스 제어: 민감한 기능 또는 데이터에 무단 액세스 허용
• 업데이트 또는 패치 실패: 앱이나 기본 구성 요소에 필요한 보안 업데이트 또는 패치를 적용하지 않은 경우
• 민감한 데이터의 부적절한 저장: 민감한 데이터를 약한 보호 형태로 저장
• 내부 사용 목적으로 애플리케이션 리소스에 무단 액세스 허용한 경우

대응 방안

1. 보안 기본 구성 검토
기본 설정 및 구성이 올바르게 보안되어 있는지 확인하고 중요한 정보를 노출시키거나 불필요한 사용 권한을 제공하지 않도록 합니다.

2. 자격 증명 및 권한 검토
하드코드화된 기본 자격 증명을 사용하지 말고, 지나치게 허용되는 권한을 가진 응용 프로그램 파일을 저장하지 않습니다. 응용프로그램의 적절한 작동을 위해 필요한 권한만 요청합니다.

3. 보안 네트워크 구성 검토
클리어 텍스트 트래픽을 허용하지 않으며 가능한 경우 인증서 고정하여 사용합니다.

4. 디버깅 비활성화
프로덕션으로 출시할 버전의 앱은 디버깅 기능을 비활성화합니다.

5. 백업 모드 비활성화(Android)
안드로이드 기기에서 백업 모드를 비활성화해 기기 백업에 앱 데이터가 포함되지 않도록 합니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
설정 검토와 로그 디버깅 혹은 분석을 통해 무단으로 데이터에 액세스해 유출하는 것을 방지할 수 있습니다.

 

• 철저한 애플리케이션 보안 스캔
• 엔드포인트가 봉쇄되어 있는지 확인 등 정밀한 체크

9. 안전하지 않은 데이터 저장소

개요

공격자는 취약성을 악용하여 중요한 정보에 무단 액세스하는 것을 목표로 합니다. 취약한 암호화, 안전하지 않은 데이터 저장 메커니즘, 유저 자격 증명의 부적절한 처리 등은 보안에 매우 취약합니다.

보안 취약점이 나타나는 환경

• 액세스 제어 부족: 애플리케이션 내 액세스 제어가 불충분하면 권한이 없는 사용자나 공격자가 장치 또는 앱의 데이터베이스에 저장된 중요한 데이터에 액세스할 수 있는 경우
• 부적절한 암호화: 중요한 데이터를 제대로 암호화하지 못하면 공격자가 저장 위치에 액세스 할 경우 의도하지 않은 데이터 유출이 발생
• 디버그 기능을 통한 의도하지 않은 데이터 노출: 모바일 응용 프로그램은 응용 프로그램 로그, 오류 메시지 또는 디버그 기능을 통해 데이터가 노출
• 부실한 세션 관리: 세션 토큰이나 사용자 인증 정보가 적절히 보호되거나 관리되지 않을 경우
• 불충분한 입력 유효성 검사: 공격자는 이를 이용해 악의적인 스크립트를 주입하거나 입력 필드를 조작하여 중요한 데이터를 검색
• 클라우드 스토리지 잘못된 구성: 모바일 애플리케이션이 데이터 저장을 위해 클라우드 스토리지 서비스를 사용하는 경우 구성이 잘못 관리 및 구성되는 경우
• 타사 라이브러리 취약성
• 의도하지 않은 데이터 공유: 애플리케이션 내에서 데이터 공유 기능을 잘못 처리하면 의도하지 않은 데이터 유출 발생

대응 방안

1. 강력한 암호화 사용
저장된 데이터와 전송 중인 데이터를 보호하기 위한 강력한 암호화 알고리즘을 구현해야 합니다.

2. 보안 데이터 전송
모바일 애플리케이션과 백엔드 서버 간 전송 중 데이터 보호를 위해 보안 통신 프로토콜(예: HTTPS, SSL/TLS)을 사용합니다.

3. 권한 없는 사용자가 액세스 할 수 없는 보안 스토리지에 데이터 저장
모바일 운영 체제에서 제공하는 플랫폼별 보안 스토리지 메커니즘(iOS – 키체인, 안드로이드 – 키스토어)을 사용합니다.

4. 입력 데이터 검증, 보안 세션 관리 적용
인젝션 공격을 방지하고 유효하고 예상되는 데이터만 저장될 수 있도록 합니다. 사용자 입력 유효성 검사를 수행하여 악성 코드 인젝션, 데이터 유출의 위험을 완화합니다. 또한 무작위로 생성된 세션 토큰을 사용하고 세션 시간 초과를 적절하게 설정해 클라이언트 및 서버 측에 세션 데이터를 안전하게 저장하는 등 보안 세션 관리 기법을 구현합니다.

5. 정기적인 업데이트
모든 라이브러리, 프레임워크 및 타사 종속성을 최신 상태로 유지합니다. 각 공급업체에서 제공하는 보안 패치 및 업데이트를 정기적으로 적용합니다.

10. 불충분한 암호화

개요

정보의 기밀성, 무결성, 신뢰성을 훼손할 수 있습니다. 해커들은 민감한 데이터를 해독하고 암호화 알고리즘을 구현해 탈취하고 사이버 범죄를 범합니다. 유저는 물론 앱 개발사의 비즈니스에 치명적인 악영향을 끼칩니다.

보안 취약점이 나타나는 환경

• 약한 암호화 알고리즘
• 부족한 키 길이 및 부적절한 키 관리: 모바일 앱에서 짧거나 쉽게 추측할 수 있는 암호화 키를 사용하면 공격자가 무차별 대입하거나 기타 암호화 공격에 타깃이 됨
• 결함 있는 암호화 구현: 암호화/복호화 프로세스 자체가 잘못 구현되거나 프로그래밍 결함이 포함된 경우
• 안전하지 않은 데이터/암호화 키 저장
• 보안 전송 계층 부족: HTTPS와 같은 보안 전송 계층 프로토콜은 네트워크를 통해 암호화된 데이터를 전송할 때 매우 중요한데, 모바일 앱에서 보안 전송 프로토콜을 구현하지 못할 경우
• 불충분한 유효성 검사 및 인증: 암호화 과정에 관여한 당사자에 대한 부적절한 유효성 검사 및 인증
• 솔팅 부족: 솔팅은 패스워드에 랜덤 문자열을 추가해 처리하는 것을 말하며, 공격자가 미리 계산한 테이블을 사용해 비밀번호를 해독하는 것을 어렵게 만듦

대응 방안

1. 강력한 암호화 알고리즘
AES(Advanced Encryption Standard), RSA(Rivest-Shamir-Adleman) 또는 ECC(Eliptic Curve Cryptography)와 같은 널리 인정되고 안전한 암호화 알고리즘을 구현합니다. 현재의 암호화 표준을 최신 상태로 유지해 취약한 알고리즘을 방지합니다.

2. 충분한 키 길이 보장 및 보안 키 관리 방법 준수
강력한 암호화를 보장하기 위해 적절한 길이의 암호화 키를 보장하고, 사용되는 특정 암호화 알고리즘을 고려하여 업계 권장 사항에 맞는 키 길이를 보장합니다. 또한 키 볼트 또는 HSM(Hardware Security Module)을 사용하여 암호화 키를 안전하게 저장하는 등 보안 키 관리 기술을 사용합니다. 권한 있는 직원에 대한 액세스 제한, 정지된 키 암호화 및 보안 키 배포 메커니즘 사용을 포함하여 키를 무단 액세스로부터 보호할 수 있습니다.

3. 올바른 암호화 구현
기존 암호화 라이브러리 및 프레임워크를 준수하면서, 모바일 애플리케이션에서 암호화 및 복호화 프로세스를 신중하게 구현해야 합니다. 사용자가 정의하는 암호화는 오류 및 취약성이 발생하므로 지양해야 합니다.

4. 암호화 키의 보안 저장
암호화 키가 모바일 장치에 안전하게 저장되는지 확인해야 합니다. 키를 쉽게 접근할 수 있는 위치에 저장하면 안 됩니다. 운영 체제에서 제공하는 보안 저장 메커니즘을 사용하거나 하드웨어 기반 보안 저장 옵션을 활용하는 것을 고려하십시오.

5. 보안 전송 계층 활용
HTTPS(HTTP Secure)와 같은 보안 전송 계층 프로토콜을 사용하여 네트워크를 통해 암호화된 데이터를 전송합니다. 적절한 인증서 검증을 구현하고 모바일 앱과 백엔드 시스템 간의 보안 통신 채널을 보장할 수 있어야 합니다.

6. 검증 및 인증
암호화 과정에 참여하는 당사자의 무결성 및 진위를 확인하기 위해 강력한 검증 및 인증 메커니즘을 구현해야 합니다. 인증에 사용되는 인증서, 디지털 서명 또는 기타 메커니즘의 적절한 검증을 수행합니다.

7. 정기적인 보안 조치 업데이트
암호화 라이브러리, 프레임워크 및 플랫폼의 서드파티 공급자가 제공하는 보안 업데이트, 패치 및 권장 사항에 대한 정보를 확인해야 합니다. 애플리케이션 및 기본 암호화 구성 요소를 최신 상태로 유지합니다.

8. 보안 테스트 수행
암호 취약점 평가, 침투 테스트, 코드 검토 등 철저한 보안 테스트를 수행합니다. 테스트 과정에서 발견된 취약점이나 취약점을 파악하고 해결합니다.

9. 업계 표준 및 모범 사례 준수
NIST(National Institute of Standards and Technology) 및 IETF(Internet Engineering Task Force)와 같은 조직에서는 안전한 암호화 방식에 대한 지침과 권장 사항을 제공하고 있으니 참고하십시오.

10. 강력한 해시 함수 사용
SHA-256 또는 bcrypt와 같이 널리 알려져 있고 암호화된 안전한 해시 함수를 선택해야 합니다. 이러한 알고리즘은 공격에 저항하고 높은 수준의 보안을 제공하도록 설계되었습니다.

11. 솔팅 구현
강력한 무작위 솔트를 사용해 비밀번호를 해싱합니다. 솔팅은 공격자가 미리 계산된 테이블을 사용하여 비밀번호를 해독하는 것을 더 어렵게 만들어 보안 레벨을 강화합니다.

12. KDF(Key Derivation Functions) 사용
PBKDF2, bcrypt 또는 scrypt와 같은 키 파생 함수를 사용해 비밀번호를 해싱할 수 있습니다. 비밀번호에서 암호화 키를 안전하게 파생하도록 특별히 설계되었으며, 무차별 대입 공격을 늦추기 위한 추가 보안 기능을 제공합니다.

앱 보안 솔루션으로 이렇게 보호할 수 있어요!
로컬 데이터가 쉽게 복제되지 않기 위해 아래 기능을 통해 강력한 보안 메커니즘을 적용할 수 있습니다.

 

• 정적 코드 암호화(예: DEX, DLL, SO, 민감한 라이브러리 파일)
• 동적 코드 암호화(메모리에 로드된 코드)
• 화이트박스(응용 프로그램 내부 구조와 동작을 검사하는 방식으로 소프트웨어 내부 소스 코드를 테스트하는 기법) 암호화

이번 리스트에는 사용자 인증 및 권한 부여나 개인 정보 보호 제어 등 유저의 정보나 데이터 유출에 대한 우려가 추가되었습니다. 모바일 애플리케이션에 민감한 개인 정보가 다수 포함될 수밖에 없기에 앱 클라이언트 보안 강화에 대한 항목이 추가된 것으로 보입니다. 

또한 모바일 기기에는 각기 다른 보안 수준을 갖는 다수의 응용 프로그램이 존재하고, 다양한 환경에서 앱이 실행됩니다. 따라서 클라이언트 단에서 보호가 실시간으로 이뤄지는 인앱(In-app) 보안 솔루션은 필수입니다.

<원문>

OWASP Top 10 Mobile 2024: 앱 개발자를 위협하는 10가지 보안 위험과 대응 방법

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.