어제, 오늘 그리고 내일

android.os.FileUriExposedException: file:///storage/emulated/0/Download/viewData.pdf exposed beyond app through ClipData.Item.getUri()

파일 시스템 권한 변경

개인 파일의 보안을 강화하기 위해, Android 7.0 이상을 대상으로 하는 앱의 개인 디렉터리는 액세스가 제한됩니다(0700). 이 설정은 크기 또는 존재 여부와 같은 개인 파일의 메타데이터 유출을 막아줍니다. 이러한 권한 변경은 여러 가지 부작용이 있습니다.

▶ 소유자가 개인 파일의 파일 권한을 더 이상 완화해서는 안 되며, MODE_WORLD_READABLE 및/또는 MODE_WORLD_WRITEABLE을 사용하여 권한을 완화하려고 시도하면 SecurityException이 트리거됩니다.

▶ 패키지 도메인 외부에서 file:// URI를 전달하면 수신기가 액세스 불가능한 경로로 남아 있을 수 있습니다. 따라서 file:// URI를 전달하려고 시도하면 FileUriExposedException이 트리거됩니다. 개인 파일의 내용을 공유하기 위해 권장되는 방법은 FileProvider를 사용하는 것입니다.

▶ DownloadManager는 비공개로 저장된 파일을 더 이상 파일 이름별로 공유할 수 없습니다. 레거시 애플리케이션은 COLUMN_LOCAL_FILENAME에 액세스할 때 액세스가 불가능한 경로가 될 수 있습니다. Android 7.0 이상을 대상으로 하는 앱은 COLUMN_LOCAL_FILENAME에 액세스할 때 SecurityException을 트리거합니다. DownloadManager.Request.setDestinationInExternalFilesDir() 또는 DownloadManager.Request.setDestinationInExternalPublicDir()을 사용하여 다운로드위치를 공용 위치로 설정하는 레거시 애플리케이션은 COLUMN_LOCAL_FILENAME에 있는 경로에 여전히 액세스할 수 있지만, 이 메서드는 부득이한 경우가 아니라면 사용하지 않는 것이 좋습니다. DownloadManager에 의해 노출되는 파일에 액세스하는 좋은 방법은 ContentResolver.openFileDescriptor()를 사용하는 것입니다.

Android 7.0을 대상으로 하는 앱의 경우, Android 프레임워크는 앱 외부에서 file:// URI의 노출을 금지하는 StrictMode API 정책을 적용합니다. 파일 URI를 포함하는 인텐트가 앱을 떠나면 FileUriExposedException 예외와 함께 앱에 오류가 발생합니다.

<provider
    android:name="android.support.v4.content.FileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:permission="android.permission.MANAGE_DOCUMENTS"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_provider_path" />
</provider>

<?xml version="1.0" encoding="utf-8"?>
<paths>
    <external-path
        name="external"
        path="." />
    <external-files-path
        name="external_files"
        path="." />

    <files-path
        name="files"
        path="." />

</paths>

java.security.KeyStoreException: entries cannot be protected with passwords

     at android.security.keystore.AndroidKeyStoreSpi.engineSetKeyEntry(AndroidKeyStoreSpi.java:308)

     at java.security.KeyStore.setKeyEntry(KeyStore.java:1179)

Apparently despite the fact that the method takes a password parameter, the AndroidKeystoreimplementation does not support this, take a look at line 200 in the source.

In any case, a password, whether strong or weak that is stored anywhere on the device is unsafe. This is especially true of source code (including source code in general, non-android contexts). If I get my hands on your app's APK, I can use one of several excellent APK analysis tools to access the class's constant pool, which will contain the password in plain text. No amount of obfuscation could prevent this, or even make it more difficult. This is perhaps the reason that the AndroidKeystoreimplementation doesn't allow this.

The whole point of the key store service on android device (it's actually implemented as a separate process you can talk to via a unix socket) is to protect access to sensitive material by requiring a users passcode to unlock it, so there's no point in putting a password on your key pairs or other secrets.. In more recent phones, this is all implmented in hardware, which provides very strong security.