Bảo mật ứng dụng trong kỷ nguyên AI tác nhân

Chào bạn! Tôi là Kristen.

Chào bạn, tôi là Sabs.

Hôm nay, chúng tôi sẽ trao đổi với bạn về vấn đề bảo mật trong kỷ nguyên tác nhân AI.

Trong năm qua, chúng tôi đã trao hơn 2 triệu đô la Mỹ tiền thưởng cho chương trình Android Bug Hunters và hơn 200 nghìn đô la Mỹ cho chương trình Mobile Bug Hunters.

Trong kỷ nguyên tác nhân ngày nay, tính bảo mật của ứng dụng không ngừng phát triển.

Vì vậy, hãy cùng tìm hiểu về các công cụ giúp chúng ta giải quyết những vấn đề này một cách nhanh chóng và hiệu quả.

Để cải thiện hiệu suất của tác nhân đối với bảo mật Android, câu trả lời không phải là một câu lệnh tốt hơn.

Đây là các công cụ và quy trình làm việc giúp tác nhân phần mềm hiểu rõ chuỗi công cụ và API của chúng tôi để giúp giữ an toàn cho ứng dụng của bạn.

Vậy là 4:30 chiều.

Vào thứ Năm.

Bạn đang cắt một bản phát hành và CI chuyển sang màu đỏ, chỉ có một lỗi: Bộ nhận tín hiệu truyền tin đã đăng ký mà không có cờ xuất.

Vì vậy, cho dù bạn đang ở trong một nhóm nhỏ, đảm nhận mọi vai trò hay trong một nhóm lớn, nơi các bước kiểm tra bảo mật diễn ra khi bạn đang phát hành, thì thực tế vẫn như vậy.

Chúng tôi là kỹ sư sản phẩm, cung cấp các tính năng chất lượng cao một cách nhanh chóng và không nhất thiết phải là nhà nghiên cứu bảo mật.

Vậy, bản năng tự nhiên là gì?

Vì vậy, chúng tôi chuyển cảnh báo đó cho một công cụ tác nhân và yêu cầu tác nhân khắc phục.

Tuy nhiên, công cụ tác nhân, hoạt động mà không có bối cảnh dự án, có ba điểm mù.

Có thể hệ thống không biết ứng dụng của bạn được tạo từ các mô-đun tính năng động hay gói nhiều tệp APK.

Nó thấy một tệp, chứ không phải một cấu phần phần mềm được vận chuyển.

Công cụ này có thể không biết, không thể theo dõi luồng dữ liệu từ giao diện người dùng Kotlin đến logic dùng chung KMP vào các lệnh gọi JNI C++ gốc.

Nó chỉ nhìn thấy một lớp.

Cuối cùng nhưng không kém phần quan trọng, Gemini có thể không biết về SDK tối thiểu hoặc phiên bản bản dựng Gradle của bạn.

Vì vậy, chúng tôi đã chỉ định một tác nhân cho ứng dụng và yêu cầu kiểm tra bảo mật.

Có 6 kết quả được trả về.

Và đây là vấn đề.

Mọi cuộc tấn công.

Chúng có thể được bảo vệ, nhưng chỉ một trong số đó là lỗi mà chúng ta thực sự bắt đầu.

Phần còn lại là sự kết hợp giữa các phương pháp hay nhất, những điều cần tìm hiểu thêm, suy đoán và những điều có thể không áp dụng được.

Vì vậy, giờ đây, bạn mở rộng quy mô thành một toàn bộ mã nguồn thực, có nhiều cảnh báo hơn và trong mọi yêu cầu kéo, bạn sẽ muốn sử dụng tính năng chặn tìm lỗi mã nguồn.

Bạn sẽ phải thay đổi để hợp nhất thay đổi đó, hoặc thậm chí có thể bỏ lỡ hoàn toàn một lỗ hổng bảo mật.

Và đó là cách các lỗ hổng thực sự lọt qua.

Công cụ này không bất cẩn mà rất cẩn thận, nhưng cẩn thận không đồng nghĩa với hữu ích.

Hãy cùng xem xét một ví dụ cụ thể.

Giả sử bạn yêu cầu tác nhân: "Kiểm tra mọi thành phần được xuất trong ứng dụng này để tìm lệnh chuyển hướng ý định của ứng dụng".

Đó là một nhiệm vụ bảo mật thực sự và đối với một ứng dụng nhiều mô-đun, đây là một nhiệm vụ lớn.

Đó là loại yêu cầu mà chi phí thực sự xuất hiện.

Nếu không có hướng dẫn cụ thể về Android, tác nhân sẽ không có chiến lược cho câu hỏi đó.

Vì vậy, nó sử dụng phương pháp brute force.

Phương thức này có thể đọc các mô-đun không xuất bất kỳ nội dung nào.

Nó có thể lấy lại từ nguyên tắc đầu tiên những gì làm cho một lệnh chuyển hướng ý định có thể khai thác được.

Nó có thể đi theo các đường dẫn chưa bao giờ truy cập được.

Bạn đang trả tiền cho việc khám phá, chứ không phải phân tích.

Kỹ năng là yếu tố giúp bạn có được chiến lược còn thiếu.

Ví dụ: các kỹ năng bảo mật của Android cung cấp cho tác nhân của bạn hướng dẫn tuân theo hướng dẫn hiện tại, cùng một trình tự các bước mà nhà nghiên cứu bảo mật thực sự sẽ làm theo và tác nhân sẽ ngừng đoán.

Trợ lý không khám phá lại các quy tắc vì các quy tắc này do kỹ năng cung cấp.

Hiện tại, chúng tôi đã ra mắt hai kỹ năng bảo mật: Bảo mật ý định và Quyền.

Bảo mật ý định liên quan đến những việc mà các ứng dụng khác có thể khiến ứng dụng của bạn thực hiện.

Ứng dụng của bạn có các quyền và phiên đăng nhập mà họ không có.

Vì vậy, mọi thành phần được xuất và mọi ý định đang chờ xử lý mà bạn đưa ra đều có thể là cách để ai đó hành động thông qua bạn.

Kỹ năng này giúp bảo vệ chống lại điều này.

Kỹ năng về quyền giúp thu hẹp khoảng cách giữa quyền được khai báo và quyền thực sự được thực thi.

Công cụ này có thể giúp bạn viết mã kiểm tra quyền phù hợp.

Việc này giúp xác định xem một nhà cung cấp có đường dẫn ký tự đại diện có cấp quyền truy cập vào toàn bộ cơ sở dữ liệu thay vì một thư mục hay không.

Công cụ này cũng phát hiện các quyền được yêu cầu quá mức.

Ví dụ: yêu cầu quyền truy cập rộng rãi trong khi chỉ cần dùng công cụ chọn ảnh.

Sử dụng công cụ này với Android CLI, sau đó hỏi: "Kiểm tra bảo mật ý định".

Không có cấu hình.

Không điều chỉnh quy tắc.

Do đó, kết quả sẽ không phải là một loạt cảnh báo.

Đây là một bài đánh giá.

Đây là lỗi, đây là lý do lỗi này ảnh hưởng đến ứng dụng của bạn và đây là cách khắc phục.

Sau đây là mẹo nâng cao.

Sử dụng Android CLI giúp bạn dễ dàng tìm và cài đặt.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

Và vì kỹ năng này biết chính xác những gì cần tìm trong dự án của bạn, nên kỹ năng này sẽ thấy ứng dụng của bạn theo đúng cách ứng dụng được vận chuyển.

Công cụ này tuân thủ SDK tối thiểu của bạn để bản sửa lỗi biên dịch, đường dẫn tệp thực, số dòng thực.

Sau đây là bài đánh giá bạn nhận được.

Nó chỉ ra chính xác tệp và dòng, giải thích mối đe doạ thực sự và giải thích cho thay đổi, chứ không chỉ là Lint nói như vậy.

Gemini sẽ trích dẫn kỹ năng đã sử dụng.

Công cụ này đọc cấu hình bản dựng, thấy SDK tối thiểu là 26 và chọn ContextCompat để bản sửa lỗi hoạt động, sau đó cung cấp cho bạn một bản vá để bạn có thể áp dụng.

Đó là cảnh báo mà chúng ta đã mở, nhưng hiện có thêm cách khắc phục đề xuất và lý do.

Vì vậy, các kỹ năng trước đây sẽ phát hiện lỗi bảo mật.

Bây giờ, hãy cùng thảo luận về một khía cạnh khác, đó là việc tuân thủ chính sách của ứng dụng.

Ví dụ: giả sử bạn là một nhà phát triển ứng dụng mới muốn ra mắt ứng dụng trên Cửa hàng Play.

Điền vào biểu mẫu an toàn dữ liệu là một bước quan trọng trong quá trình phát hành ứng dụng. Vì vậy, hãy sử dụng mọi công cụ có thể để đảm bảo chúng ta thực hiện đúng trước khi gửi ứng dụng.

Kỹ năng chính sách của Play thực hiện phân tích tĩnh trên toàn bộ mã nguồn của bạn.

Nếu bạn đang phát hành một ứng dụng hiện có trên Cửa hàng Play, thì công cụ này cũng có thể tham chiếu chéo kết quả phân tích mã tĩnh đó với nội dung khai báo trên Cửa hàng Play.

Việc chạy kỹ năng này có thể giúp bạn phát hiện các vấn đề tiềm ẩn về chính sách của Play trước khi gửi ứng dụng, thay vì sau khi gửi, đồng thời giúp đẩy nhanh quy trình gửi ứng dụng.

Quy trình làm việc tương tự như các kỹ năng khác mà chúng ta đã thảo luận: nhập kỹ năng đó rồi hỏi: "Kiểm tra ứng dụng này để đảm bảo tuân thủ chính sách của Google Play trước khi tôi gửi."

Bạn sẽ thấy ảnh chụp màn hình của một báo cáo mẫu ở bên phải và các lệnh Android CLI để cài đặt báo cáo đó ở bên dưới.

android skills list
android skills add play-policy-insights

Như vậy, mọi điều chúng ta đã thảo luận cho đến nay đều diễn ra trước khi bạn phát hành: kiểm tra ý định, kiểm tra quyền, xác thực việc tuân thủ.

Đó là bảo mật trong thời gian xây dựng và điều này rất cần thiết.

Tuy nhiên, có một loại mối đe doạ chỉ tồn tại khi tệp APK của bạn được phát hành ra bên ngoài và chạy trên các thiết bị mà bạn có thể không kiểm soát được.

API Tính toàn vẹn của Play trả lời ba câu hỏi trong thời gian chạy mà mã của bạn không thể tự trả lời: Đây có phải là bản dựng chính hãng, chưa sửa đổi của ứng dụng không?

Ứng dụng này có đang chạy trên một thiết bị Android chính hãng không?

Và đây có phải là tài khoản người dùng Play không?

Vì vậy, bạn có thể dùng Play Integrity API để trả về kết quả về tính toàn vẹn của ứng dụng, tính toàn vẹn của thiết bị và nhiều thông tin khác.

Ngoài việc giúp bạn phát hành ứng dụng an toàn hơn một cách nhanh chóng và dễ dàng, chúng tôi cũng giúp bạn dễ dàng bảo vệ doanh thu và uy tín của ứng dụng.

Vì vậy, hãy bảo vệ doanh nghiệp của bạn khỏi hành vi gian lận và sử dụng sai mục đích.

Trang tổng quan mới Được bảo vệ bằng Play (bạn có thể xem tại đây) giúp bạn theo dõi và định cấu hình các biện pháp bảo vệ tính toàn vẹn, hoạt động phân phối và kiếm tiền ở cùng một nơi.

Chúng tôi cũng đang giảm độ trễ khởi động cho Play Integrity API để bạn có thể sử dụng các quy trình kiểm tra này trong những hành trình của người dùng cần tốc độ nhanh, nhằm chặn các mối đe doạ và thiết bị rủi ro nhanh hơn.

Chúng ta vừa thảo luận về các tính năng và công cụ của Android giúp giữ an toàn cho ứng dụng, nhưng còn người dùng thì sao?

Trước tiên, hãy cùng tìm hiểu về tính năng Bảo vệ OTP qua SMS.

Giả sử bạn muốn triển khai quy trình xác minh người dùng dựa trên SMS cho ứng dụng và gửi mã xác minh.

Quyền truy cập vào SMS cho phép ứng dụng truy cập vào dữ liệu nhắn tin, bao gồm cả dữ liệu nhạy cảm như OTP.

Vì vậy, chúng tôi đã giới thiệu một vài API trong ứng dụng để bạn có thể triển khai, nhờ đó bạn không cần yêu cầu quyền truy cập SMS rộng rãi nhưng vẫn có thể nhận mã OTP qua SMS để xác minh.

SMS Retriever API cho phép ứng dụng của bạn tự động xác minh OTP mà không cần quyền truy cập rộng rãi vào SMS.

Bạn thêm một hàm băm gồm 11 ký tự xác định ứng dụng của bạn vào tin nhắn và hệ thống chỉ gửi cho bạn tin nhắn đó.

Nếu bạn không thể kiểm soát định dạng tin nhắn, hãy sử dụng SMS User Consent API.

Hệ thống sẽ hiển thị một lời nhắc duy nhất, một lần.

Người dùng nhấn vào cho phép hoặc từ chối và nếu họ cho phép, bạn sẽ nhận được một tin nhắn đó.

Vẫn không cần quyền truy cập rộng vào SMS.

Một số ứng dụng có thể chỉ cần thông tin vị trí chính xác một lần để hoàn thành nhiệm vụ.

Quyền một lần hiện tại có mức độ can thiệp cao đối với người dùng, vì vậy, đôi khi nhà phát triển sẽ yêu cầu quyền truy cập thông tin vị trí chính xác rộng hơn.

Vì vậy, Nút vị trí là một công cụ giúp người dùng dễ dàng cấp cho ứng dụng quyền truy cập một lần vào thông tin vị trí chính xác.

Đây là một phần tử trên giao diện người dùng Android mà nhà phát triển ứng dụng có thể tuỳ chỉnh và nhúng.

Chúng tôi đã ra mắt phiên bản đầu tiên của thư viện Jetpack nút vị trí (phiên bản alpha) vào tháng 6.

Tại đây, bạn có thể xem các quyền cần thiết để bật Nút vị trí trong tệp kê khai Android.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

Bạn phải khai báo quyền truy cập vị trí tiêu chuẩn bằng cách thêm cờ quyền onlyForLocationButton, cùng với quyền USE_LOCATION_BUTTON chuyên biệt mà dịch vụ kết xuất từ xa của hệ thống yêu cầu.

Bên phải là mã Jetpack để triển khai.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Bạn có thể thấy ở đây chúng ta đang tạo một Nút vị trí và khởi chạy một lệnh gọi lại.

Lệnh gọi lại này được kích hoạt khi người dùng nhấn vào Nút vị trí để đưa ra quyết định về việc cấp hay từ chối quyền.

Chế độ Bảo vệ nâng cao là một tính năng dành cho những người dùng có nguy cơ gặp rủi ro hoặc những người quan tâm đến vấn đề bảo mật, nhưng bất kỳ ai cũng có thể chọn sử dụng.

Ví dụ: giả sử bạn là một ứng dụng ngân hàng, bạn không bắt buộc phải xác thực đa yếu tố cho mọi giao dịch chuyển khoản vì người dùng thông thường không thích sự phiền hà đó.

Tuy nhiên, khi Chế độ bảo vệ nâng cao đang bật, ứng dụng của bạn sẽ biết người dùng này muốn được bảo vệ ở mức tối đa, vì vậy, bạn có thể tự động yêu cầu xác thực bằng sinh trắc học cho mọi giao dịch chuyển tiền.

Chế độ bảo vệ nâng cao triển khai một nhóm cấu hình được xác định trước để tăng cường khả năng bảo vệ thiết bị.

Sau đây, chúng tôi sẽ hướng dẫn bạn cách tích hợp vào ứng dụng.

Bạn cần yêu cầu cấp quyền, truy vấn Chế độ bảo vệ nâng cao và kiểm tra xem người dùng đã bật Chế độ bảo vệ nâng cao hay chưa bằng cách gọi dịch vụ hệ thống Trình quản lý chế độ bảo vệ nâng cao trên thiết bị.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Sau đó, bạn có thể theo dõi các thay đổi trong thời gian chạy bằng cách đăng ký lệnh gọi lại.

Hôm nay, chúng ta đã tìm hiểu rất nhiều chủ đề.

Sau đây là các đường liên kết nhanh để bạn tìm hiểu thêm về các tính năng này.

Chúng ta sẽ tạm dừng ở đây một chút để bạn có thể ghi lại các URL cần thiết.

Cảm ơn bạn.

Cảm ơn bạn.