OWASP Mobile Top 10: nó là gì, danh sách lỗ hổng và cách áp dụng

OWASP Mobile Top 10 là gì?

OWASP Mobile Top 10 là danh sách chuẩn hóa các rủi ro bảo mật nghiêm trọng nhất đặc thù cho ứng dụng di động. Khác với OWASP Top 10 chung cho ứng dụng web, phiên bản di động tính đến các đặc thù của nền tảng: lưu trữ cục bộ trên thiết bị, tương tác với cảm biến, chế độ ngoại tuyến và đặc điểm của các cửa hàng ứng dụng. Tài liệu được xuất bản từ năm 2010 và được sửa đổi mỗi 2–4 năm: phiên bản hiện tại cho năm 2024 bao gồm các danh mục như M1 — Improper Credential Usage và M8 — Security Misconfiguration. Dự án được hỗ trợ bởi cộng đồng hơn 500 tình nguyện viên trên toàn thế giới.

Lịch sử và mục đích

Ban đầu, OWASP Top 10 chỉ bao gồm các ứng dụng web, nhưng sự phát triển của ứng dụng di động trong những năm 2010 đòi hỏi một tài liệu riêng. Phiên bản đầu tiên của Mobile Top 10 được phát hành vào năm 2011 và chỉ chứa 7 mục. Đến năm 2024, danh sách đã mở rộng lên 10 danh mục, mỗi danh mục bao gồm nhiều kịch bản tấn công cụ thể. Mục đích chính của tài liệu là cung cấp cho các nhà phát triển và nhóm bảo mật một ngôn ngữ chung để thảo luận về rủi ro và ưu tiên sửa chữa. Các bản cập nhật thường xuyên của danh sách phản ánh những thay đổi trong bối cảnh mối đe dọa: sự xuất hiện của các API mới, sự tiến hóa của hệ điều hành (Android, iOS) và các kỹ thuật tấn công mới được mô tả trong báo cáo của Positive Technologies và các trung tâm nghiên cứu khác.

Danh sách OWASP Mobile Top 10 được hình thành như thế nào

Phương pháp biên soạn Mobile Top 10 dựa trên dữ liệu từ các dự án thực tế: kết quả kiểm tra thâm nhập ứng dụng di động, báo cáo sự cố và nghiên cứu lỗ hổng được phân tích. Mỗi danh mục được đánh giá theo hai tham số: Tỷ lệ xuất hiện (Incidence Rate) và Tác động kỹ thuật (Technical Impact). Sự kết hợp của các chỉ số này tạo thành bảng xếp hạng cuối cùng. Không giống như các danh sách chủ quan, OWASP sử dụng dữ liệu mở: bất kỳ thành viên cộng đồng nào cũng có thể gửi yêu cầu đưa vào danh mục mới thông qua kho lưu trữ GitHub của dự án. Cho phiên bản hiện tại 2024, hơn 300.000 bài kiểm tra bảo mật từ 25 quốc gia đã được xử lý, làm cho số liệu thống kê mang tính đại diện cho hệ sinh thái phát triển di động toàn cầu. Ngoài ra, OWASP công bố MASVS (Mobile Application Security Verification Standard) — một bộ yêu cầu bảo mật chi tiết bao gồm hơn 80 kiểm tra cụ thể được phân bổ vào 8 danh mục. MASVS được sử dụng làm cơ sở để chứng nhận ứng dụng và làm danh sách kiểm tra cho kiểm tra thâm nhập: mỗi yêu cầu có một tham chiếu đến danh mục Mobile Top 10, đảm bảo khả năng truy xuất giữa tiêu chuẩn và danh sách rủi ro.

Tổng quan về các lỗ hổng chính trong top 10

Hãy xem xét ba danh mục nghiêm trọng nhất từ OWASP Mobile Top 10 2024, bao phủ hơn 70% tất cả các sự cố bảo mật trong các dự án di động. Mỗi danh mục bao gồm các kịch bản khai thác cụ thể và khuyến nghị bảo vệ.

Sử dụng nền tảng không đúng

Danh mục này (M1) bao gồm các tình huống mà nhà phát triển sử dụng API và cơ chế nền tảng không đúng cách. Ví dụ điển hình: Intent Injection trên Android, trình xử lý Deep Link mở trên iOS, xử lý sai Keychain và SharedPreferences. Kẻ tấn công có thể gửi một Intent được tạo đặc biệt và truy cập dữ liệu của ứng dụng hoặc thành phần khác. Theo báo cáo của NowSecure (2023), 22% ứng dụng Android được kiểm tra có chứa lỗ hổng loại Intent Redirection. Bảo vệ bao gồm: xác thực đầu vào nghiêm ngặt, kiểm tra nguồn Intent và sử dụng quyền cho các thành phần được xuất.

Lưu trữ dữ liệu không an toàn

Lưu trữ dữ liệu không an toàn (M2) là vấn đề phổ biến nhất trong các ứng dụng di động. Nó xảy ra khi dữ liệu nhạy cảm (token truy cập, mật khẩu, dữ liệu cá nhân) được lưu trữ dưới dạng văn bản thuần túy hoặc với bảo vệ không đầy đủ. Các nguồn lỗ hổng điển hình: cơ sở dữ liệu SQLite không mã hóa, SharedPreferences không có EncryptedSharedPreferences, ghi log dữ liệu ở chế độ gỡ lỗi. Theo OWASP Foundation (2024), hơn 60% ứng dụng miễn phí trên Google Play lưu trữ ít nhất một loại dữ liệu nhạy cảm ở dạng không được mã hóa. Giải pháp là sử dụng Android EncryptedSharedPreferences, iOS Keychain và mã hóa dữ liệu trước khi ghi vào bộ nhớ cục bộ.

Giao tiếp không an toàn

Danh mục M3 — Giao tiếp không an toàn — bao gồm các lỗ hổng trong kênh truyền dữ liệu giữa ứng dụng và máy chủ. Thiếu HTTPS, xác thực chứng chỉ SSL không đúng, sử dụng giao thức TLS 1.0/1.1 lỗi thời — tất cả những vấn đề này cho phép kẻ tấn công chặn lưu lượng thông qua các cuộc tấn công Man-in-the-Middle. Tình huống đặc biệt nguy hiểm khi ứng dụng xử lý dữ liệu nhạy cảm (giao dịch ngân hàng, thông tin y tế) qua kênh không được bảo vệ. Năm 2023, các nhà nghiên cứu từ NCC Group phát hiện ra rằng 12% ứng dụng tài chính phổ biến sử dụng cấu hình TLS không chính xác. Khuyến nghị: bắt buộc sử dụng HTTPS với Certificate Pinning và từ chối HTTP trong các bản dựng sản xuất.

Cách kiểm tra ứng dụng theo OWASP Mobile Top 10

Kiểm tra bảo mật của ứng dụng di động theo phương pháp OWASP bao gồm nhiều giai đoạn: phân tích mã tĩnh (SAST), phân tích động (DAST) và kiểm tra thủ công (kiểm tra thâm nhập). Mỗi giai đoạn nhằm xác định các danh mục lỗ hổng cụ thể từ Mobile Top 10.

Công cụ kiểm tra

Để phân tích tự động, OWASP khuyến nghị sử dụng MobSF (Mobile Security Framework) — một công cụ mã nguồn mở. MobSF thực hiện phân tích tĩnh mã nguồn và tệp nhị phân, kiểm tra cấu hình tệp kê khai, phân tích quyền và xác định các lỗ hổng từ Mobile Top 10. Để phân tích động, Burp Suite (proxy chặn lưu lượng) và Frida (công cụ phân tích thời gian chạy) được sử dụng. Sự kết hợp của các công cụ này bao phủ hơn 80% danh mục trong danh sách. Kiểm tra thường xuyên trong đường ống CI/CD với MobSF cho phép xác định lỗ hổng ở giai đoạn phát triển sớm và giảm chi phí sửa chữa xuống 60–70%. Việc tích hợp các công cụ SAST và DAST vào đường ống nên được tự động hóa thông qua plugin Gradle/Maven hoặc các bước Fastlane trong bản dựng iOS.

Giải thích báo cáo MobSF

Sau khi chạy MobSF, nhà phát triển nhận được báo cáo với các chỉ thị màu sắc: đỏ — lỗ hổng nghiêm trọng, cam — rủi ro trung bình, vàng — rủi ro thấp. Mỗi cảnh báo chứa tham chiếu đến danh mục OWASP Mobile Top 10 tương ứng, mô tả vấn đề và khuyến nghị sửa chữa. Điều quan trọng không chỉ là loại bỏ các cảnh báo đỏ mà còn phân tích các cảnh báo cam: nhiều trong số chúng (ví dụ: Activity được xuất mà không có bảo vệ) có thể kết hợp để tạo cho kẻ tấn công một vectơ tấn công. Khuyến nghị đạt được không có cảnh báo đỏ và không quá 2–3 cảnh báo cam trước mỗi lần phát hành. Báo cáo MobSF cũng bao gồm phân tích quyền ứng dụng: bất kỳ quyền quá mức nào (ví dụ: truy cập camera trong máy tính) đều được gắn cờ là vi phạm nguyên tắc đặc quyền tối thiểu và phải được xóa khỏi tệp kê khai. Đối với ứng dụng iOS, MobSF thực hiện phân tích tương tự các tệp .ipa, bao gồm kiểm tra Info.plist về các ngoại lệ ATS và phân tích tệp nhị phân Mach-O cho các API không an toàn như NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}