Các phương pháp hay nhất để bảo mật ứng dụng

Phần này chứa các đề xuất để đảm bảo tính bảo mật của ứng dụng trên thiết bị Android.

Xem xét mã nguồn

Quy trình xem xét mã nguồn có thể phát hiện nhiều vấn đề bảo mật, bao gồm cả những vấn đề được xác định trong tài liệu này. Android khuyến khích mạnh mẽ cả quy trình xem xét mã nguồn thủ công và tự động.

  • Làm theo hướng dẫn toàn diện về bảo mật khi tiến hành xem xét để đảm bảo phạm vi. Sử dụng các tiêu chuẩn nội bộ hoặc bên ngoài có liên quan để đảm bảo quy trình xem xét nhất quán và đầy đủ.
  • Chạy trình kiểm tra lỗi mã nguồn (linter), chẳng hạn như trình kiểm tra lỗi mã nguồn của Android Studio, trên tất cả mã ứng dụng bằng SDK Android và sửa mọi vấn đề được xác định.
  • Phân tích mã gốc bằng một công cụ tự động có thể phát hiện các vấn đề về quản lý bộ nhớ, chẳng hạn như lỗi tràn bộ đệm và lỗi lệch một.
  • Hệ thống xây dựng Android hỗ trợ nhiều trình dọn dẹp LLVM, chẳng hạn như AddressSanitizerUndefinedBehaviorSanitizer. Bạn có thể sử dụng các trình dọn dẹp này để phân tích các vấn đề liên quan đến bộ nhớ trong thời gian chạy. Khi kết hợp với fuzzing (được hỗ trợ trong Android thông qua libFuzzer), các trình dọn dẹp có thể phát hiện các trường hợp biên bất thường cần điều tra thêm.
  • Một chuyên gia đánh giá bảo mật am hiểu nên xem xét mã có rủi ro cao hơn, chẳng hạn như mã liên quan đến tiền mã hoá, xử lý thanh toán và xử lý thông tin nhận dạng cá nhân (PII).

Kiểm thử tự động

Quy trình kiểm thử tự động có thể giúp phát hiện nhiều vấn đề bảo mật và bạn nên thực hiện quy trình này thường xuyên.

  • Thường xuyên chạy phiên bản CTS mới nhất trong suốt quá trình phát triển để phát hiện sớm các vấn đề và giảm thời gian sửa lỗi. Android sử dụng CTS như một phần của quy trình tích hợp liên tục trong quy trình xây dựng tự động của chúng tôi. Quy trình này xây dựng nhiều lần mỗi ngày.
  • Tự động hoá quy trình kiểm thử bảo mật của các giao diện, bao gồm cả quy trình kiểm thử bằng dữ liệu đầu vào bị lỗi (kiểm thử fuzz). Hệ thống xây dựng của Android hỗ trợ libFuzzer để viết các bài kiểm thử fuzz tests.

Quét lỗ hổng

Quy trình quét lỗ hổng có thể giúp đảm bảo rằng các ứng dụng được cài đặt sẵn không có các lỗ hổng bảo mật đã biết. Tính năng phát hiện nâng cao có thể giảm thời gian và chi phí cần thiết để giải quyết các lỗ hổng này và ngăn ngừa rủi ro cho người dùng và thiết bị.

  • Quét tất cả các ứng dụng được cài đặt sẵn bằng một công cụ quét lỗ hổng ứng dụng được ngành công nhận và giải quyết các lỗ hổng được phát hiện.

Ứng dụng có thể gây hại

Điều quan trọng là đảm bảo rằng các ứng dụng được cài đặt sẵn trên thiết bị của bạn không phải là Ứng dụng có thể gây hại (PHA). Bạn chịu trách nhiệm về hành vi của tất cả các ứng dụng có trên thiết bị của mình. Trước khi ra mắt thiết bị, hãy quét tất cả các ứng dụng được tải sẵn để tìm lỗ hổng.

Để biết thêm thông tin về PHA và cách Google chống lại các ứng dụng này trong Cửa hàng Play, hãy xem tài liệu dành cho nhà phát triển của Google Play Protect.

Cài đặt ứng dụng và quyền

Việc cấp quá nhiều quyền cho các ứng dụng được cài đặt sẵn có thể gây ra rủi ro về bảo mật. Hạn chế các ứng dụng được cài đặt sẵn ở mức quyền tối thiểu cần thiết và đảm bảo rằng các ứng dụng này không có quyền truy cập vào các quyền hoặc đặc quyền không cần thiết. Quyền cho ứng dụng được mô tả trong tệp AndroidManifest.xml.

  • Không cấp các quyền hoặc đặc quyền không cần thiết cho các ứng dụng được cài đặt sẵn. Xem xét kỹ lưỡng các ứng dụng có đặc quyền hệ thống vì các ứng dụng này có thể có các quyền rất nhạy cảm.
  • Đảm bảo rằng tất cả các quyền được yêu cầu đều có liên quan và cần thiết cho chức năng của ứng dụng cụ thể đó.
  • Đảm bảo rằng tất cả các ứng dụng được cài đặt sẵn sử dụng quyền INSTALL_PACKAGES đều có thông báo cho người dùng.
  • Đảm bảo rằng nhà phát triển có nghĩa vụ theo hợp đồng là không cài đặt bất kỳ ứng dụng nào dưới dạng UID 0.
  • Đánh giá các quyền được khai báo trong tệp kê khai của tất cả các ứng dụng sẽ được cài đặt thông qua mạng của nhà phát triển.
  • Đảm bảo rằng nhà phát triển có nghĩa vụ theo hợp đồng là quét tất cả các URL tải xuống của các ứng dụng trình cài đặt và trình cập nhật tự động bằng API Duyệt web an toàn của Google trước khi phân phát ứng dụng cho thiết bị.

Ký ứng dụng

Chữ ký ứng dụng đóng vai trò quan trọng trong việc bảo mật thiết bị và được dùng để kiểm tra quyền và cập nhật phần mềm. Khi chọn một khoá để dùng cho việc ký ứng dụng, bạn cần cân nhắc xem một ứng dụng chỉ có trên một thiết bị hay phổ biến trên nhiều thiết bị.

  • Đảm bảo rằng các ứng dụng không được ký bằng một khoá được công khai, chẳng hạn như khoá nhà phát triển AOSP.
  • Đảm bảo rằng các khoá dùng để ký ứng dụng được quản lý theo cách phù hợp với các phương pháp tiêu chuẩn trong ngành để xử lý các khoá nhạy cảm, bao gồm cả mô-đun bảo mật phần cứng (HSM) cung cấp quyền truy cập có thể kiểm tra và hạn chế.
  • Đảm bảo rằng các ứng dụng không được ký bằng khoá nền tảng. Việc này cho phép ứng dụng truy cập vào các quyền chữ ký nền tảng. Các quyền này rất mạnh mẽ và chỉ dành cho các thành phần của hệ điều hành. Các ứng dụng hệ thống nên sử dụng các quyền đặc quyền.
  • Đảm bảo rằng các ứng dụng có cùng tên gói không được ký bằng các khoá khác nhau. Điều này thường xảy ra khi tạo một ứng dụng cho các thiết bị khác nhau, đặc biệt là khi sử dụng khoá nền tảng. Nếu ứng dụng không phụ thuộc vào thiết bị, hãy sử dụng cùng một khoá trên các thiết bị. Nếu ứng dụng dành riêng cho thiết bị, hãy tạo tên gói riêng cho mỗi thiết bị và khoá.

Tách biệt ứng dụng và quy trình

Mô hình hộp cát của Android cung cấp thêm tính bảo mật cho các ứng dụng và quy trình khi được sử dụng đúng cách.

Tách biệt các quy trình gốc

Các quy trình gốc là mục tiêu thường xuyên nhất của các cuộc tấn công leo thang đặc quyền; việc giảm số lượng quy trình gốc sẽ giảm rủi ro leo thang đặc quyền.

  • Đảm bảo rằng các thiết bị chạy mã tối thiểu cần thiết dưới dạng gốc. Nếu có thể, hãy sử dụng quy trình Android thông thường thay vì quy trình gốc. Nếu một quy trình phải chạy dưới dạng gốc trên một thiết bị, hãy ghi lại quy trình đó trong yêu cầu về tính năng AOSP để công khai xem xét.
  • Nếu có thể, mã gốc phải được tách biệt với dữ liệu không đáng tin cậy và được truy cập thông qua giao tiếp liên quy trình (IPC). Ví dụ: giảm chức năng gốc xuống một dịch vụ nhỏ có thể truy cập thông qua Binder và hiển thị dịch vụ bằng quyền chữ ký cho một ứng dụng có ít hoặc không có đặc quyền để xử lý lưu lượng truy cập mạng.
  • Các quy trình gốc không được theo dõi trên ổ cắm mạng.
  • Các quy trình gốc không được bao gồm thời gian chạy đa năng, chẳng hạn như Java VM.

Tách biệt các ứng dụng hệ thống

Nói chung, các ứng dụng được cài đặt sẵn không được chạy với mã nhận dạng duy nhất (UID) của hệ thống dùng chung. Nếu cần thiết để một ứng dụng sử dụng UID dùng chung của hệ thống hoặc một dịch vụ đặc quyền khác (ví dụ: điện thoại), thì ứng dụng đó không được xuất bất kỳ dịch vụ, broadcast receiver hoặc nhà cung cấp nội dung nào mà các ứng dụng bên thứ ba do người dùng cài đặt có thể truy cập.

  • Đảm bảo rằng các thiết bị chạy mã tối thiểu cần thiết dưới dạng hệ thống. Nếu có thể, hãy sử dụng quy trình Android có UID riêng thay vì sử dụng lại UID hệ thống.
  • Nếu có thể, mã hệ thống phải được tách biệt với dữ liệu không đáng tin cậy và hiển thị IPC chỉ cho các quy trình đáng tin cậy khác.
  • Các quy trình hệ thống không được theo dõi trên ổ cắm mạng. Đây là yêu cầu của CTS requirement.

Tách biệt các quy trình

Hộp cát của ứng dụng Android cung cấp cho các ứng dụng kỳ vọng về việc tách biệt với các quy trình khác trên hệ thống, bao gồm cả các quy trình gốc và trình gỡ lỗi. Trừ phi ứng dụng và người dùng bật cụ thể tính năng gỡ lỗi, không ứng dụng nào được vi phạm kỳ vọng đó.

  • Đảm bảo rằng các quy trình gốc không truy cập vào dữ liệu trong các thư mục dữ liệu ứng dụng riêng lẻ, trừ phi sử dụng phương thức gỡ lỗi Android được ghi lại.
  • Đảm bảo rằng các quy trình gốc không truy cập vào bộ nhớ của ứng dụng, trừ phi sử dụng một phương thức gỡ lỗi Android được ghi lại.
  • Đảm bảo rằng các thiết bị không chứa bất kỳ ứng dụng nào truy cập vào dữ liệu hoặc bộ nhớ của các ứng dụng hoặc quy trình khác.