모든 응용 프로그램은 매니페스트 정의에 액세스 권한이 명시적으로 할당되지 않은 공개 구성 요소에 액세스할 수 있습니다.

Android 응용 프로그램의 작업, 수신자 및 서비스 구성 요소에 대한 exported 속성의 기본값은 intent-filter의 존재 여부에 따라 달라집니다. intent-filter의 존재는 구성 요소가 외부용으로 설계되었으므로 exported 속성을 true로 설정함을 의미합니다. 이제 Android 플랫폼의 모든 다른 응용 프로그램에서 이 구성 요소에 접근할 수 있습니다.

예제 1: 다음은 intent-filter가 존재하고 명시적 접근 권한 집합이 없는 Android 작업의 예입니다.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

이 활동은 악성 응용 프로그램에 의해 악용될 수 있습니다.

모든 응용 프로그램은 매니페스트 정의에 액세스 권한이 명시적으로 할당되지 않은 공개 구성 요소에 액세스할 수 있습니다. Android 컨텐츠 공급자는 android:minSdkVersion 또는 android:targetSdkVersion을 "16" 이하로 설정하는 응용 프로그램에서 기본적으로 내보내집니다. 이러한 속성 중 하나를 "17" 이상으로 설정하는 응용 프로그램의 경우 기본값은 "false"입니다.

예제 1: 다음은 명시적 접근 권한 또는 내보내는 플래그 없이 선언된 Android 콘텐트 공급자의 예입니다.

 <provider android:name=".ContentProvider"/> 

Android는 보안 공급자를 통해 보안 네트워크 통신을 제공합니다. 그러나 때때로 기본 보안 공급자에서 취약점이 발견됩니다. 이러한 취약점으로부터 보호하기 위해 Google Play 서비스는 장치의 보안 공급자를 자동으로 업데이트하여 알려진 익스플로이트으로부터 장치를 보호할 수 있도록 합니다. 앱에서 Google Play 서비스 메서드를 호출하여 알려진 익스플로이트를 차단하는 최신 업데이트가 앱을 실행하는 장치에서 실행되고 있는지 확인할 수 있습니다.

네트워크 보안 구성 기능을 사용하면 앱에서 앱 코드를 수정하지 않고도 안전한 선언적 구성 파일에서 네트워크 보안 설정을 사용자 지정할 수 있습니다. 특정 도메인과 특정 앱에 대해 이러한 설정을 구성할 수 있습니다. 이 기능의 주요 기능은 다음과 같습니다.
- 사용자 지정 트러스트 앵커: 앱의 보안 연결에서 신뢰할 수 있는 인증 기관(CA)을 사용자 지정합니다. 예를 들어 자체 서명된 특정 인증서를 신뢰하거나 앱이 신뢰하는 공개 CA 집합을 제한합니다.
- 디버그 전용 재정의: 설치 기반에 추가되는 위험 없이 앱의 보안 연결을 안전하게 디버그합니다.
- 일반 텍스트 트래픽 옵트아웃: 일반 텍스트 트래픽의 우발적인 사용으로부터 앱을 보호합니다.
- 인증서 고정: 앱의 보안 연결을 특정 인증서로 제한합니다.

수신자 권한 없이 보낸 브로드캐스트는 임의의 수신자에 접근할 수 없습니다. 이러한 브로드캐스트가 민감한 데이터를 포함하거나 악성 수신자에 도달하는 경우, 응용 프로그램에 위험을 끼칠 수 있습니다.

예제 1: 다음 코드는 수신자 권한을 지정하지 않고 브로드캐스트를 보냅니다.

...
context.sendBroadcast(intent);
...

시스템 브로드캐스트를 비공개 구성 요소로 보낼 수 있습니다. 타사로부터 비시스템 브로드캐스트를 수신하려면 구성 요소를 공개해야 합니다. 단일 구성 요소에서 시스템 브로드캐스트와 비시스템 브로드캐스트를 모두 수신하도록 등록하면 구성 요소의 일부 기능(시스템 부분)이 불필요하게 타사에 노출됩니다.

사용자 지정 권한을 선언할 때는 4가지 옵션을 사용하여 권한의 보호 수준을 지정할 수 있습니다. 즉, normal, dangerous, signature 및 signature or system입니다. Normal 권한은 권한을 요청하는 모든 응용 프로그램에 부여됩니다. Dangerous 권한은 사용자 확인 후에만 부여됩니다. Signature 권한은 권한을 정의하는 패키지와 동일한 개발자 키로 서명된 응용 프로그램에만 부여됩니다. Signature or system 권한은 signature 권한과 유사하지만 Android 시스템 이미지의 패키지에도 부여됩니다.

예제 1: 다음은 normal 보호 수준으로 선언된 사용자 지정 권한의 예입니다.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

결합된 읽기 및 쓰기 permission으로 선언된 콘텐트 공급자는 공급자에 대한 읽기 또는 쓰기 액세스를 요청하는 엔터티에 액세스할 수 있게 됩니다. 그러나 대부분의 경우 파일 시스템의 파일과 마찬가지로 공급자가 저장한 데이터에 대한 읽기 액세스 권한을 필요로 하는 엔터티는 데이터를 수정할 수 없어야 합니다. permission 속성을 설정해도 데이터의 무결성에 영향을 미치는 데이터 사용자와 상호 작용을 구분할 수는 없습니다.

예제 1: 다음은 결합된 읽기 및 쓰기 접근 permission으로 선언된 콘텐트 공급자의 예입니다.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

스티키 브로드캐스트는 권한을 사용하여 보안이 유지될 수 없어 임의의 수신자에 접근할 수 있습니다. 이러한 브로드캐스트가 민감한 데이터를 포함하거나 악성 수신자에 도달하는 경우, 응용 프로그램에 위험을 끼칠 수 있습니다.

예제 1: 다음 코드는 스티키 브로드캐스트(sticky broadcast)를 보냅니다.

...
context.sendStickyBroadcast(intent);
...

android.permission 네임스페이스에 새 권한을 정의하면 OS가 업데이트될 때 예기치 않은 결과가 발생할 수 있습니다. 최신 버전의 OS가 정확히 동일한 권한을 정의하는 경우 Android PMS(패키지 관리 서비스)는 사용자에게 묻지 않고 앱에 자동으로 권한을 부여하여 권한 에스컬레이션 공격을 허용합니다.

이 구성 요소는 다른 구성 요소가 아닌 시스템에서만 브로드캐스트 메시지를 수신해야 하므로 다른 구성 요소에서 접근하지 못하도록 비공개가 되어야 합니다.

쿠키는 RFC 2109에 따라 엄격하게 제한되는 HTTP 메커니즘입니다. file://을 비롯해, HTTP 이외의 프로토콜에서 작동한다고 기대할 합리적인 이유가 없습니다. 어떤 동작이 수행될지, 어떤 보안 분류 규칙이 적용될지가 분명하지 않습니다. 예를 들어 인터넷 공유에서 로컬 디스크로 HTML 파일을 다운로드해야 한다면 HTML 코드처럼 동일한 쿠키가 로컬에 설치됩니까?

개발자는 문서화되지 않았거나 숨겨진 API를 사용하여 응용 프로그램을 작성하지 않는 것이 좋습니다. 장래에 Google이 이러한 API를 제거하거나 변경하지 않는다는 보장이 없으므로 이러한 메서드나 필드를 사용하면 응용 프로그램이 손상될 위험이 크기 때문에 사용을 지양해야 합니다.

코드는 미리 릴리스한 후 Camera 개체를 사용하려 합니다. 리소스를 다시 획득하지 않은 Camera 개체에 대한 자세한 참조는 예외를 발생시키며 예외가 발생하지 않은 경우, 응용 프로그램 손상을 일으킬 수 있습니다.

예제: 다음 코드는 토글 버튼을 사용하여 카메라 미리보기를 토글 설정하거나 해제합니다. 사용자가 버튼을 한 번 누르고 나면 카메라 미리보기가 중단되고 카메라 리소스가 릴리스됩니다. 그러나 버튼을 다시 누르면 startPreview()가 미리 릴리스한 Camera 개체에서 호출됩니다.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

코드는 미리 릴리스한 후 미디어 개체를 사용하려 합니다. 리소스를 다시 획득하지 않고 미디어 개체에 대한 자세한 참조는 예외를 발생시키며 예외가 발생하지 않은 경우, 응용 프로그램 손상을 일으킬 수 있습니다.

예제: 다음 코드는 일시 중지 버튼을 사용하여 미디어 재생을 토글합니다. 사용자가 버튼을 한 번 누르고 나면 현재 노래나 비디오가 일시 중지되고 카메라 리소스가 릴리스됩니다. 그러나 버튼을 다시 누르면 start()가 미리 릴리스한 미디어 리소스에서 호출됩니다.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

코드는 미리 닫고 난 후 Android SQLite 데이터베이스 처리기를 사용하려고 합니다. 데이터베이스 연결을 다시 설정하지 않은 처리기에 대한 자세한 참조는 예외를 발생시키며, 예외가 발생하지 않은 경우 응용 프로그램 손상을 일으킬 수 있습니다.

예제: 다음 코드는 메모리의 사용자 값을 일시적으로 캐시하는 프로그램에서 나올 수 있지만 flushUpdates()를 호출하여 디스크에 대한 변경 내용을 커밋할 수 있습니다. 메서드는 데이터베이스에 업데이트를 작성한 후 데이터베이스 처리기를 올바르게 닫습니다. 그러나 flushUpdates()가 다시 호출될 경우, 재초기화 전에 데이터베이스 개체를 다시 참조합니다.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

하드웨어 및 장치 관련 ID는 데이터를 지우고 공장 기본값으로 재설정한 후에도 유지됩니다. 따라서 이러한 ID에 의존하여 사용자에게 권한을 부여하거나 사용자를 인증하는 데 사용되는 고유 ID를 생성하지 않아야 합니다.

또한 개인 정보와 관련될 수 있는 UUID(Universally Unique Identifier)의 누출은 사용자 개인 정보 및 보안에 위협이 됩니다.

Android 클래스 로드 하이재킹 취약점은 다음 두 가지 형태로 나타납니다.

- 프로그램이 클래스를 로드하기 위해 검색하는 디렉터리의 이름을 공격자가 변경하여 자신이 제어권을 가진 디렉터리를 가리키도록 할 수 있습니다. 즉, 클래스를 검색할 경로를 공격자가 명시적으로 제어합니다.

- 클래스가 로드되는 환경을 공격자가 변경할 수 있습니다. 즉, 공격자가 암시적으로 경로 이름의 의미를 제어합니다.

이 경우에는 공격자가 로드할 클래스를 검색하는 디렉터리를 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이러한 유형의 Android 클래스 로드 하이재킹 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.



2. 데이터는 로드할 클래스를 찾을 라이브러리 디렉터리를 나타내는 문자열 또는 문자열의 일부로 사용됩니다.



3. 응용 프로그램은 라이브러리 경로의 코드를 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 사용자가 변경 가능한 userClassPath를 사용하여 로드할 클래스를 검색할 디렉터리를 결정합니다.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

이 코드를 통해 공격자는 userClassPath의 결과를 자신이 제어하는 다른 경로를 가리키도록 수정할 수 있기 때문에 공격자가 라이브러리를 로드하고 응용 프로그램의 높은 권한으로 임의 코드를 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에 공격자가 userClassPath의 값을 제어할 수 있으면, 공격자가 제어하는 디렉터리를 가리키도록 응용 프로그램을 속일 수 있고 이에 따라 공격자가 정의한 클래스를 원래 응용 프로그램과 동일한 권한으로 로드할 수 있습니다.

예제 2: 다음 코드는 사용자가 변경 가능한 userOutput를 사용하여 로드할 클래스를 검색할 디렉터리를 결정합니다.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

이 코드에서는 공격자가 ODEX(Optimized DEX) 파일의 출력 디렉터리를 지정하는 것이 가능합니다. 그러면 악의적인 사용자가 userOutput의 값을 외부 저장소와 같은 자신이 제어하는 디렉터리로 변경할 수 있습니다. 이렇게 되면 출력된 ODEX 파일을 악의적 ODEX 파일로 바꾸기만 하면 원래 응용 프로그램과 동일한 권한으로 실행됩니다.

디버그 바이너리를 생성하도록 Android 응용 프로그램을 구성할 수 있습니다. 이러한 바이너리는 자세한 디버깅 메시지를 제공하므로 운영 환경에서 사용해서는 안 됩니다. <application> 태그의 debuggable 속성은 컴파일된 바이너리에 디버깅 정보를 포함할지 여부를 정의합니다.

디버그 바이너리를 사용하면 응용 프로그램이 사용자에게 가능한 한 많은 정보를 제공하게 됩니다. 디버그 바이너리는 개발 또는 테스트 환경에서 사용하기 위한 것이며 운영 환경에 배포할 경우 보안 위험을 초래할 수 있습니다. 공격자는 디버깅 출력에서 얻은 자세한 정보를 이용하여 응용 프로그램이 사용하는 프레임워크, 데이터베이스 또는 기타 리소스를 공격할 수 있습니다.

Apache Axis 2는 Java 애플릿을 통해 들어오고 나가는 SOAP 메시지를 모니터링할 수 있는 개발자 유틸리티를 제공합니다. SOAP Monitor는 웹 서비스를 호출하는 데 사용되는 모든 SOAP 메시지를 보여줍니다. 공격자는 이 유틸리티를 사용하여 웹 서비스와 해당 클라이언트 간의 트래픽을 도청할 수 있습니다.