Skip to content

Insecure Filesystem Access

Insecure Filesystem Access

Description

The application handles files using insecure permissions (world-readable or world-writable) or is targeting external memory devices like SD card with weak permissions.

According to Android security designing idea, files are used only for making information persistence and temporarily saved (cache), and it should be private in principle. Exchanging information between applications should not be direct access to files, but it should be exchanged by an inter-application linkage system, like Content Provider or Service. By using this, inter-application access control can be achieved.

World readable permission

World readable may present a risk if they store sensitive information that may present a risk if accessed by an unauthorized party, like bank account statement or session key storage file.

World writable permission

World writable may present a risk if it is to perform sensitive actions, like URL list or session parameters.

External storage

Accessing External storage in apps targeting Android 9 (API level 28) and lower using getExternalFilesDir() gives other apps the right to read and change those files.

The method that apps access files in the external storage of devices running Android 10 (API level 29) or higher has been changed. For apps targeting Android 10, a filtered view for displaying files in external storage is provided by default. Each app can save the app files in the app-specific directory and constantly has read-write access permissions for created files, and so permission does not need to be declared.

Recommendation

  • File Must Be Created as a Private File in Principle: Regardless of the contents of the information to be stored, files should be set private, in principle. From Android security designing point of view, exchanging information and its access control should be done in Android system like Content Provider and Service, etc., and in case there’s a reason that is impossible, it should be considered to be substituted by file access permission as alternative method.

  • Must Not Create Files that Be Allowed to Read/Write Access from Other Applications: When permitting other applications to read/write files, information stored in files cannot be controlled. So, sharing information by using read/write public files should not be considered from both security and function/designing points of view.

  • Using Files Stored in External Device (e.g. SD Card) Should Be Requisite Minimum: Storing files in external memory device like SD card, leads to holding the potential problems from security and functional points of view

    • Sensitive information should not be saved in a file of external memory device, in principle
    • In case sensitive information is saved in a file of external memory device, it should be encrypted.
    • In case saving in a file of external memory device information that will be trouble if it’s tampered by other application or users, it should be saved with electrical signature.
    • When reading in files in external memory device, use data after verifying the safety of data to read in.
    • Application should be designed supposing that files in external memory device can be always deleted.

  • Use of world access permissions should be used only when strictly required. Other means of sharing data between applications are recommended instead of sharing file using insecure permissions.

  • Application Should Be Designed Considering the Scope of File

Standards

  • OWASP_MASVS_L1:
    • MSTG_STORAGE_2
  • OWASP_MASVS_L2:
    • MSTG_STORAGE_2
  • CWE_TOP_25:
    • CWE_276
  • PCI_STANDARDS:
    • REQ_2_2
    • REQ_6_2
    • REQ_6_3
    • REQ_7_3
    • REQ_11_3
  • OWASP_MASVS_v2_1:
    • MASVS_STORAGE_2
  • SOC2_CONTROLS:
    • CC_2_1
    • CC_4_1
    • CC_6_1
    • CC_7_1
    • CC_7_2
    • CC_7_4
    • CC_7_5