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 bị sai chính tả, hoặc khi thuộc tính android:protectionLevel tương ứng bị sử dụng sai 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 dùng chung 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ệ. Mức độ nghiêm trọng của lỗ hổng phụ thuộc vào tài nguyên đang được bảo vệ và các quyền liên kết 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ể viết hoa hay viết thường, đều là dữ liệu đầu vào không hợp lệ cho nội dung khai báo quyền và được xử lý tương tự như các lỗi chính tả khác trong nội dung khai báo quyền tuỳ chỉnh. Để khắc phục vấn đề này, bạn nên thay đổi giá trị của thuộc tính android:permission thành một 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 trên 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 lỗi chính tả 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, các quyền này được gọi là quyền không có chủ sở hữu. 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 không chính xác
  • Tên quyền trong quy trình kiểm tra hoặc Tệp kê khai có thể được viết sai chính tả

Ứng dụng độc hại có thể xác định một quyền không được liên kết và lấy quyền đó. 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 quyền sử dụng quyền để bảo vệ hoặc hạn chế bất kỳ thành phần nào, điều 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 khởi 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 thực hiện việc nà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 đó, các protectionLevels này cung cấp ít tính 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ệ đó. Đảm bảo bạn đang sử dụng một chứng chỉ ký chuyên dụng (không được sử dụng lại) và lưu trữ chứng chỉ đó một cá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. Nguyên nhân là do một lỗ hổng nâng cao đặ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 một quyền tuỳ chỉnh chữ ký mà các ứng dụng X khác sử dụng nhưng sau đó bị gỡ cài đặt, thì một ứng dụng độc hại B có thể xác định cùng một quyền tuỳ chỉnh đó bằng 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ả các thành phần được bảo vệ bằng quyền tuỳ chỉnh đó trong ứng dụng X mà không cần phải được ký bằng cùng một chứng chỉ với ứ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 những ứng dụng của bạn đưa ra yêu cầu với ứ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