일반 텍스트 통신

OWASP 카테고리: MASVS-NETWORK: 네트워크 커뮤니케이션

개요

Android 앱에서 일반 텍스트 네트워크 통신을 허용하면 네트워크 트래픽을 모니터링하는 모든 사용자가 전송되는 데이터를 보고 조작할 수 있습니다. 전송되는 데이터에 비밀번호, 신용카드 번호나 기타 개인 정보와 같은 민감한 정보가 포함되어 있으면 취약점이 됩니다.

민감한 정보를 전송하는지 여부와 관계없이 일반 텍스트를 사용하면 취약점이 될 수 있습니다. 일반 텍스트 트래픽은 ARP 또는 DNS 포이즌링과 같은 네트워크 공격을 통해 조작될 수 있으므로 공격자가 앱 동작에 영향을 줄 수 있기 때문입니다.

영향

Android 애플리케이션이 네트워크를 통해 일반 텍스트로 데이터를 보내거나 받으면 네트워크를 모니터링하는 누구나 이 데이터를 가로채 읽을 수 있습니다. 이 데이터에 비밀번호, 신용카드 번호, 개인 메시지 등의 민감한 정보가 포함되면 신원 도용, 금융 사기 및 여러 가지 심각한 문제가 발생할 수 있습니다.

예를 들어 앱에서 일반 텍스트로 비밀번호를 전송하면 트래픽을 가로채는 악의적인 행위자에게 이러한 사용자 인증 정보가 노출될 수 있습니다. 악의적인 행위자가 이 데이터를 사용해 사용자 계정에 무단으로 액세스할 수 있습니다.

위험: 암호화되지 않은 커뮤니케이션 채널

암호화되지 않은 통신 채널을 통해 데이터를 전송하면 기기와 애플리케이션 엔드포인트 간에 공유되는 데이터가 노출됩니다. 이러한 데이터는 공격자가 가로채고 수정할 수 있습니다.

완화 조치

데이터는 암호화된 통신 채널을 통해 전송되어야 합니다. 보안 프로토콜은 암호화 기능을 제공하지 않는 프로토콜의 대안으로 사용해야 합니다.

구체적인 위험

이 섹션에는 특수한 완화 전략이 필요한 위험, 또는 특정 SDK 수준에서 완화되었으므로 여기에는 완전성을 위해 포함된 위험이 정리되어 있습니다.

위험: HTTP

이 섹션의 안내는 Android 8.1 (API 수준 27) 이하를 타겟팅하는 앱에만 적용됩니다. Android 9 (API 수준 28)부터 URLConnection, Cronet, OkHttp와 같은 HTTP 클라이언트는 HTTPS 사용을 시행하므로 일반 텍스트 지원은 기본적으로 사용 중지됩니다. 그러나 Ktor와 같은 다른 HTTP 클라이언트 라이브러리는 일반 텍스트에 이러한 제한사항을 적용하지 않을 가능성이 높으므로 주의해서 사용해야 합니다.

완화 조치

NetworkSecurityConfig.xml 기능을 사용하여 일반 텍스트 트래픽을 선택 해제하고 앱에 HTTPS를 적용합니다. 단, 필요한 특정 도메인 (일반적으로 디버깅 목적)은 예외입니다.

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

이 옵션은 백엔드 서버 등의 외부 소스가 제공하는 URL의 변경사항으로 인해 앱에서 우연히 회귀가 일어나는 일을 방지합니다.

위험: FTP

FTP 프로토콜을 사용하여 기기 간에 파일을 교환하면 여러 가지 위험이 발생하며, 그중 가장 중요한 위험은 통신 채널에 암호화가 없다는 점입니다. SFTP 또는 HTTPS와 같은 더 안전한 대안을 대신 사용해야 합니다.

완화 조치

애플리케이션에서 인터넷을 통해 데이터 교환 메커니즘을 구현할 때는 HTTPS와 같은 안전한 프로토콜을 사용해야 합니다. Android에서는 개발자가 클라이언트-서버 로직을 만들 수 있는 API 집합을 제공합니다. 이는 전송 계층 보안 (TLS)을 사용하여 보호할 수 있으므로 두 엔드포인트 간의 데이터 교환이 암호화되므로 악의적인 사용자가 통신을 도청하고 민감한 정보를 검색하는 것을 방지할 수 있습니다.

일반적으로 클라이언트-서버 아키텍처는 개발자가 소유한 API를 사용합니다. 애플리케이션이 일련의 API 엔드포인트를 사용하는 경우 HTTPS 통신을 보호하기 위한 다음 보안 권장사항에 따라 심층적인 보안을 보장합니다.

  • 인증: 사용자는 OAuth 2.0과 같은 안전한 메커니즘을 사용하여 본인 인증을 해야 합니다. 기본 인증은 세션 관리 메커니즘을 제공하지 않으며 사용자 인증 정보가 부적절하게 저장된 경우 Base64에서 디코딩될 수 있으므로 일반적으로 권장되지 않습니다.
  • 승인 – 사용자는 최소 권한의 원칙에 따라 의도한 리소스에만 액세스할 수 있도록 제한되어야 합니다. 이는 애플리케이션의 애셋에 신중한 액세스 제어 솔루션을 채택하여 구현할 수 있습니다.
  • 보안 권장사항에 따라 신중하게 최신 암호화 스위트를 사용해야 합니다. 예를 들어 필요한 경우 HTTPS 통신을 위해 이전 버전과의 호환성을 갖춘 TLSv1.3 프로토콜을 지원해 보세요.

위험: 맞춤 커뮤니케이션 프로토콜

맞춤 통신 프로토콜을 구현하거나 잘 알려진 프로토콜을 수동으로 구현하려고 하면 위험할 수 있습니다.

맞춤 프로토콜을 사용하면 개발자가 의도한 요구사항에 맞게 고유한 솔루션을 조정할 수 있지만 개발 프로세스 중에 오류가 발생하면 보안 취약점이 발생할 수 있습니다. 예를 들어 세션 처리 메커니즘을 개발할 때 오류가 발생하면 공격자가 통신을 도청하고 민감한 정보를 즉시 검색할 수 있습니다.

반면에 OS나 잘 관리된 서드 파티 라이브러리를 사용하지 않고 HTTPS와 같은 잘 알려진 프로토콜을 구현하면 코딩 오류가 발생할 가능성이 높아져 필요할 때 구현한 프로토콜을 업데이트하기가 어려워질 수 있습니다. 또한 맞춤 프로토콜을 사용할 때와 동일한 종류의 보안 취약점이 발생할 수 있습니다.

완화 조치

유지관리되는 라이브러리를 사용하여 잘 알려진 통신 프로토콜 구현

애플리케이션에서 HTTPS와 같은 잘 알려진 프로토콜을 구현하려면 OS 라이브러리 또는 유지관리되는 서드 파티 라이브러리를 사용해야 합니다.

이를 통해 개발자는 철저하게 테스트되고 시간이 지남에 따라 개선되었으며 일반적인 취약점을 수정하기 위한 보안 업데이트를 지속적으로 수신하는 솔루션을 선택할 수 있습니다.

또한 잘 알려진 프로토콜을 선택하면 개발자는 다양한 시스템, 플랫폼, IDE 간에 광범위한 호환성을 활용할 수 있으므로 개발 프로세스 중에 인적 오류가 발생할 가능성이 줄어듭니다.

SFTP 사용

이 프로토콜은 전송 중인 데이터를 암호화합니다. 이러한 종류의 파일 교환 프로토콜을 사용할 때는 추가 조치를 고려해야 합니다.

  • SFTP는 다양한 종류의 인증을 지원합니다. 비밀번호 기반 인증 대신 공개 키 인증 방법을 사용해야 합니다. 이러한 키는 안전하게 생성하고 저장해야 하며, 이 목적으로는 Android 키 저장소를 사용하는 것이 좋습니다.
  • 지원되는 암호화 알고리즘이 보안 권장사항을 준수하는지 확인합니다.

리소스