Quyền tuỳ chỉnh

Danh mục OWASP: MASVS-CODE: Chất lượng mã

Tổng quan

Các rủi ro liên quan đến Quyền tuỳ chỉnh phát sinh khi định nghĩa quyền tuỳ chỉnh bị thiếu hoặc sai chính tả, hoặc khi thuộc tính android:protectionLevel tương ứng bị sử dụng sai mục đích trong Tệp kê khai.

Ví dụ: các rủi ro này có thể được khai thác bằng cách tạo một quyền tuỳ chỉnh có cùng tên, nhưng do một ứng dụng độc hại xác định và áp dụng các cấp độ bảo vệ khác nhau.

Quyền tuỳ chỉnh được thiết kế để cho phép chia sẻ tài nguyên và chức năng với các ứng dụng khác. Sau đây là một số ví dụ về việc sử dụng hợp pháp các quyền tuỳ chỉnh:

  • Kiểm soát hoạt động giao tiếp liên quy trình (IPC) giữa hai hoặc nhiều ứng dụng
  • Truy cập vào các dịch vụ của bên thứ ba
  • Hạn chế quyền truy cập vào dữ liệu được chia sẻ của một ứng dụng

Tác động

Tác động của việc khai thác lỗ hổng này là một ứng dụng độc hại có thể truy cập vào các tài nguyên ban đầu được bảo vệ. Hệ quả của lỗ hổng bảo mật phụ thuộc vào tài nguyên đang được bảo vệ và các quyền liên quan của dịch vụ ứng dụng ban đầu.

Rủi ro: Lỗi chính tả trong quyền tuỳ chỉnh

Bạn có thể khai báo một quyền tuỳ chỉnh trong Tệp kê khai, nhưng một quyền tuỳ chỉnh khác được dùng để bảo vệ các thành phần Android đã xuất, do lỗi chính tả. Ứng dụng độc hại có thể tận dụng các ứng dụng đã viết sai chính tả quyền bằng cách:

  • Trước tiên, hãy đăng ký quyền đó
  • Dự đoán chính tả trong các ứng dụng tiếp theo

Điều này có thể cho phép một ứng dụng truy cập trái phép vào tài nguyên hoặc kiểm soát ứng dụng nạn nhân.

Ví dụ: một ứng dụng dễ bị tấn công muốn bảo vệ một thành phần bằng cách sử dụng quyền READ_CONTACTS nhưng vô tình đánh sai chính tả quyền đó thành READ_CONACTS. Một ứng dụng độc hại có thể xác nhận quyền sở hữu READ_CONACTS vì không có ứng dụng nào (hoặc hệ thống) sở hữu ứng dụng đó và có quyền truy cập vào thành phần được bảo vệ. Một biến thể phổ biến khác của lỗ hổng này là android:permission=True. Các giá trị như true và false, bất kể cách viết hoa, đều là dữ liệu đầu vào không hợp lệ để khai báo quyền và được xử lý tương tự như các lỗi chính tả khác trong khai báo quyền tuỳ chỉnh. Để khắc phục vấn đề này, bạn phải thay đổi giá trị của thuộc tính android:permission thành chuỗi quyền hợp lệ. Ví dụ: nếu ứng dụng cần truy cập vào danh bạ của người dùng, thì giá trị của thuộc tính android:permission phải là android.permission.READ_CONTACTS.

Giải pháp giảm thiểu

Kiểm tra để tìm lỗi mã nguồn của Android

Khi khai báo quyền tuỳ chỉnh, hãy sử dụng tính năng kiểm tra tìm lỗi mã nguồn của Android để giúp bạn tìm thấy kiểu chữ và các lỗi tiềm ẩn khác trong mã.

Quy ước đặt tên

Sử dụng quy ước đặt tên nhất quán để giúp lỗi chính tả dễ nhận thấy hơn. Hãy kiểm tra kỹ nội dung khai báo quyền tuỳ chỉnh trong Tệp kê khai của ứng dụng để tìm lỗi chính tả.

Rủi ro: Quyền không có chủ sở hữu

Quyền được dùng để bảo vệ tài nguyên của ứng dụng. Có hai vị trí khác nhau mà ứng dụng có thể khai báo các quyền cần thiết để truy cập vào tài nguyên:

Tuy nhiên, đôi khi các quyền này không được xác định bằng thẻ <permission> tương ứng trong Tệp kê khai của tệp APK trên thiết bị. Trong trường hợp này, chúng được gọi là quyền mất nguồn gốc. Tình huống này có thể xảy ra vì một số lý do, chẳng hạn như:

  • Có thể xảy ra tình trạng không đồng bộ giữa các bản cập nhật trên Tệp kê khai và mã có tính năng kiểm tra quyền
  • Tệp APK có các quyền có thể không được đưa vào bản dựng hoặc có thể đưa vào phiên bản sai
  • Tên quyền trong bước kiểm tra hoặc trong Tệp kê khai có thể bị viết sai chính tả

Một ứng dụng độc hại có thể xác định và lấy một quyền đã mất đi. Nếu điều này xảy ra, các ứng dụng đặc quyền tin tưởng quyền bị bỏ rơi để bảo vệ một thành phần có thể bị xâm phạm.

Trong trường hợp ứng dụng có đặc quyền sử dụng quyền để bảo vệ hoặc hạn chế một thành phần bất kỳ, thì việc này có thể cấp cho ứng dụng độc hại quyền truy cập vào thành phần đó. Ví dụ bao gồm việc chạy các hoạt động được bảo vệ bằng một quyền, truy cập vào một nhà cung cấp nội dung hoặc truyền tin đến một broadcast receiver được bảo vệ bằng quyền bị bỏ rơi.

Điều này cũng có thể tạo ra tình huống ứng dụng đặc quyền bị lừa nghi ngờ ứng dụng độc hại là ứng dụng hợp pháp và do đó tải các tệp hoặc nội dung.

Giải pháp giảm thiểu

Đảm bảo rằng tất cả các quyền tuỳ chỉnh mà ứng dụng của bạn sử dụng để bảo vệ các thành phần cũng được xác định trong Tệp kê khai.

Ứng dụng sử dụng các quyền tuỳ chỉnh my.app.provider.READ và my.app.provider.WRITE để bảo vệ quyền truy cập vào một nhà cung cấp nội dung:

XML

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

Ứng dụng cũng xác định và sử dụng các quyền tuỳ chỉnh này, do đó, ngăn các ứng dụng độc hại khác làm như vậy:

XML

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

Rủi ro: Sử dụng sai android:protectionLevel

Thuộc tính này mô tả mức độ rủi ro tiềm ẩn trong quyền và cho biết quy trình mà hệ thống nên tuân theo khi quyết định có cấp quyền hay không.

Giải pháp giảm thiểu

Tránh cấp độ bảo vệ Thông thường hoặc Nguy hiểm

Việc sử dụng protectionLevel thông thường hoặc nguy hiểm cho các quyền của bạn có nghĩa là hầu hết ứng dụng đều có thể yêu cầu và nhận được quyền:

  • "bình thường" chỉ yêu cầu khai báo
  • "nguy hiểm" sẽ được nhiều người dùng phê duyệt

Do đó, những protectionLevels này có ít khả năng bảo mật.

Sử dụng Quyền chữ ký (Android >= 10)

Sử dụng các cấp độ bảo vệ chữ ký bất cứ khi nào có thể. Việc sử dụng tính năng này đảm bảo rằng chỉ những ứng dụng khác được ký bằng cùng một chứng chỉ với ứng dụng đã tạo quyền mới có thể truy cập vào các tính năng được bảo vệ đó. Hãy đảm bảo bạn đang sử dụng một chứng chỉ ký chuyên biệt (không sử dụng lại) và lưu trữ chứng chỉ đó an toàn trong một kho khoá.

Xác định quyền tuỳ chỉnh như sau trong Tệp kê khai:

XML

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

Chỉ cho phép những ứng dụng có quyền tuỳ chỉnh này truy cập vào một hoạt động, chẳng hạn như sau:

XML

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

Sau đó, mọi ứng dụng khác được ký bằng cùng một chứng chỉ với ứng dụng đã khai báo quyền tuỳ chỉnh này sẽ được cấp quyền truy cập vào hoạt động .MyActivity và cần khai báo quyền đó như sau trong Tệp kê khai:

XML

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

Cảnh giác với Quyền tuỳ chỉnh chữ ký (Android < 10)

Nếu ứng dụng của bạn nhắm đến Android < 10, thì bất cứ khi nào các quyền tuỳ chỉnh của ứng dụng bị xoá do gỡ cài đặt hoặc cập nhật, có thể có các ứng dụng độc hại vẫn có thể sử dụng các quyền tuỳ chỉnh đó và do đó bỏ qua các bước kiểm tra. Điều này là do một lỗ hổng báo cáo đặc quyền (CVE-2019-2200) đã được khắc phục trong Android 10.

Đây là một trong những lý do (cùng với nguy cơ xảy ra tình trạng tương tranh) khiến bạn nên sử dụng tính năng kiểm tra chữ ký thay vì quyền tuỳ chỉnh.

Rủi ro: Tình huống tương tranh

Nếu một ứng dụng hợp pháp A xác định quyền tuỳ chỉnh chữ ký mà các ứng dụng X khác dùng nhưng sau đó bị gỡ cài đặt, thì ứng dụng độc hại B có thể xác định quyền tuỳ chỉnh đó với một protectionLevel khác, ví dụ: bình thường. Bằng cách này, B có quyền truy cập vào tất cả thành phần được bảo vệ bằng quyền tuỳ chỉnh đó trong các ứng dụng X mà không cần ký bằng cùng một chứng chỉ như ứng dụng A.

Điều tương tự cũng xảy ra nếu B được cài đặt trước A.

Giải pháp giảm thiểu

Nếu muốn chỉ cung cấp một thành phần cho những ứng dụng được ký bằng chữ ký giống như ứng dụng cung cấp, bạn có thể tránh được việc xác định quyền tuỳ chỉnh để hạn chế quyền truy cập vào thành phần đó. Trong trường hợp này, bạn có thể sử dụng tính năng kiểm tra chữ ký. Khi một trong các ứng dụng của bạn đưa ra yêu cầu cho một ứng dụng khác, ứng dụng thứ hai có thể xác minh rằng cả hai ứng dụng đều được ký bằng cùng một chứng chỉ trước khi tuân thủ yêu cầu đó.

Tài nguyên