보안 코딩 기법: 사용자 지정 권한 문제

모바일 개발 시 애플리케이션은 종종 시스템에 특정 권한을 요청해야 합니다. 사용자 연락처나 블루투스 연결에 액세스해야 하거나 SMS 메시지를 보낼 수 있는 기능이 필요할 수 있습니다. 위에서 언급한 모든 권한은 안드로이드 프레임워크에 의해 정의된 플랫폼 권한입니다.

하지만 이러한 권한만으로는 부족하여 애플리케이션이 자체적인 사용자 지정 권한을 정의해야 하는 경우가 있습니다. 우리 회사를 예로 들어보겠습니다. Secure Code Warrior는 사용자의 SCW 플랫폼 성과를 포함하여 프로필의 일부로 개인 데이터를 저장하는 앱을 만들 수 있습니다. 그리고 사용자가 허용할 경우, 다른 보안 교육 앱인 DevTrainer가 이 데이터를 사용하도록 허용하고 싶을 수 있습니다. 이는 민감한 데이터이므로 사용자는 아무나 이 정보를 알기를 원치 않겠지만, SCWApp은 유용할 수 있는 이 데이터를 완전히 숨기거나 보호해서는 안 됩니다. 따라서 사용자가 이를 제어할 수 있도록 하고 싶습니다. 바로 이때 사용자 지정 권한이 필요합니다.

SCWApp이 사용자 지정 권한을 생성하면 DevTrainer가 이 권한을 요청하고, 사용자는 이를 허용할지 여부를 결정할 수 있습니다. 이는 일반적인 관행이며 화이트리스트에 등록된 애플리케이션에 대한 액세스를 제한하는 좋은 방법입니다.

안타깝게도 사용자 지정 권한과 관련하여 직관적이지 않은 동작이 일부 존재하며, 이는 보안 관점에서 위험을 초래합니다. 구체적으로, 사용자 지정 권한은 어떤 앱에서든 언제든지 정의할 수 있으며 "먼저 정의한 앱이 우선권을 갖는(first one wins)" 전략이 적용되는데, 이 전략에는 몇 가지 결과가 따릅니다.

다음 시나리오를 위해 위에서 소개한 두 가지 앱 프로필을 정의하겠습니다(이 모든 애플리케이션은 설명을 위한 가상의 앱입니다).

1. SCWApp: 사용자 지정 권한을 정의하고 이 권한을 사용하여 구성 요소를 보호하는 앱.

2. DevTrainer: SCWApp과 동일한 권한을 정의하고 사용자에게 이 권한을 보유하고 싶다고 선언하는 앱.

이는 '피어 앱 사례(Peer Apps Case)'라고 불리는 일반적인 시나리오입니다. DevTrainer 앱이 SCWApp의 플러그인에 불과했다면 사용자 지정 권한을 정의할 필요가 없었을 것입니다. 이 경우 SCWApp이 DevTrainer보다 먼저 설치되어 예상치 못한 동작이 발생하지 않을 것이라고 가정합니다. 만약 사용자가 DevTrainer를 먼저 설치하면 권한 요청에 대한 알림을 받지 못합니다. 그 후 사용자가 나중에 SCWApp을 설치하더라도 DevTrainer에는 소급하여 권한이 부여되지 않으므로, DevTrainer 앱이 보호된 구성 요소를 사용하려는 시도는 실패하게 됩니다.

여기서 '피어 앱 사례(Peers App Case)'가 등장합니다. 어떤 경우에는 한 앱이 다른 앱보다 먼저 설치될 것이라고 기대할 수 없습니다. 예를 들어 페이스북과 트위터가 서로의 구성 요소를 사용하려는 경우, 각자의 사용자 지정 권한을 서로 정의해야 합니다.

하지만 여기서 문제가 복잡해집니다. DevTrainer 앱이 먼저 설치되면 사용자는 사용자 지정 권한 요청에 대한 알림을 받지 못합니다. 이 시점에서 사용자는 알림을 받지 못했음에도 불구하고 DevTrainer는 사용자 지정 권한을 보유하게 되며 보호된 구성 요소에 액세스할 수 있게 됩니다.

더 복잡한 문제는 DevTrainer 앱이 권한 보호 수준을 변경할 수 있다는 점입니다. 안드로이드는 보호를 제공하는 앱의 보호 수준을 사용하는 것이 아니라 가장 먼저 정의된 보호 수준을 사용합니다. 즉, 먼저 설치된 앱이 보호 수준을 결정하게 됩니다. 따라서 DevTrainer가 권한 수준을 'normal'로 변경하면, 이후 이 권한을 요청하는 모든 앱은 사용자의 확인을 거칠 필요 없이 자동으로 액세스 권한을 부여받게 됩니다.

이 시나리오는 cwac-security github에서 발견된 이 문제에 대한 설명에서 영감을 받았습니다.

"먼저 정의한 앱이 우선권을 갖는" 전략은 위험한 결과를 초래할 수 있으며, 이러한 동작을 알지 못하면 개발자가 신뢰할 수 없는 입력을 기반으로 보안 결정을 내려 의도하지 않은 앱이 민감한 데이터나 보호된 서비스에 액세스하도록 허용할 수 있습니다. 신뢰할 수 없는 입력을 통한 보안 결정을 피하는 방법에 대해 자세히 알아보려면 저희 플랫폼을 방문하세요. 이 동작은 안드로이드 5.0(롤리팝)부터 변경되었습니다. 하지만 현재 22% 이상의 안드로이드 기기가 여전히 이전 버전의 안드로이드를 실행 중이므로 앱에서 원래 동작으로 인한 위험을 완화하는 것이 중요합니다. 앱을 처음 실행할 때 권한이 이미 정의되어 있는지 확인하고, 정의되어 있다면 보안 위험을 해결하기 위해 적절한 조치를 취하십시오.

즐거운 코딩 되세요. 다음 주에 뵙겠습니다!

사용자 지정 권한을 정의하면 앱은 자신의 리소스와 기능을 다른 앱과 공유할 수 있습니다.

https://developer.android.com/guide/topics/permissions/defining.html