bảo mật web và ứng dụng đề tài bảo mật ứng dụng trên nền tảng android

Trường hợp sửdụng phổ biến nhất là lưu các phần dữ liệu có liên quan vào bộ nhớ đệm.Bằng cách này, khi thiết bị không thể truy cập mạng, người dùng vẫnduyệt qua được nội dung đó dù không

Trang 1

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINHTRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Giảng viên hướng dẫn: Đỗ Hoàng HiểnSinh viên thực hiện:

Lê Minh Tài 18520351Nguyễn Lê Thái Hoàng 18520058Nguyễn Thùy Linh 19520147

Trang 2

1.2 Top 10 OWASP Mobile Risks - Final List 2016 11

1.2.1 M1: Improper Platform Usage (Sử dụng nền tảng không phù hợp) 11

1.2.2 M2: Insecure Data Storage (Lưu trữ dữ liệu không an toàn) 13

1.2.3 M3: Insecure Communication (Giao tiếp không an toàn) 16

1.2.4 M4: Insecure Authentication (Xác thực không an toàn) 20

1.2.5 M5: Insufficient Cryptography (Mật mã không đủ) 25

1.2.6 M6: Insecure Authorization (Ủy quyền không an toàn) 27

1.2.7 M7: Client Code Quality (Chất lượng mã kém) 30

1.2.8 M8: Code Tampering (Giả mạo mã) 33

1.2.9 M9: Reverse Engineering (Kỹ thuật đảo ngược) 36

1.2.10 M10: Extraneous Functionality (Chức năng ngoại lai) 39

Trang 3

Lời mở đầu

Hiện nay, Android và iOS đã và đang là 2 hệ điều hành chiếm thị phầnlớn nhất trên thế giới Android nổi bật với khả năng tùy biến tương thíchcao, dễ sử dụng và cho phép cá nhân hóa một cách dễ dàng Trong khi đó,iOS của Apple chiếm ưu thế về sự ổn định, tính năng bảo mật hiệu quảcùng khả năng cập nhật nhanh Trong đó, Android sẽ dễ bị tấn công hơnvì các lý do như: Android có nhiều người dùng hơn, tin tặc dễ kiếm tiềnhơn; Android cho phép người dùng cài app bên thứ ba vào máy (tuy tínhnăng này không mặc định bật nhưng nhiều người vẫn bật lên để cài cácapp từ kho app bên thứ 3) Do đó vấn đề bảo mật ứng dụng trên nền tảngAndroid là vô cùng cấp thiết Mục tiêu của bài báo cáo này là để giảiquyết vấn đề trên.

1 Lý Thuyết

1.1 Công Nghệ App1.1.1 Android Studio

Android Studio là môi trường phát triển tích hợp (IDE) dành choAndroid Android Studio được xây dựng trên phần mềm IntelliJ IDEAcủa JetBrains và được thiết kế đặc biệt với các công cụ lập trình giúp xâydựng và phát triển các ứng dụng chất lượng cao nhất dành cho nền tảngAndroid của Google.

Các tính năng chính:

1 Trình mô phỏng nhanh và tính năng phong phú

Trang 4

Android Studio hỗ trợ bạn trình mô phỏng Android (Android Emulator)sẽ giúp mô phỏng thiết bị Android trên máy tính của bạn để bạn có thểkiểm tra ứng dụng của mình trên nhiều cấu hình thiết bị Android như điệnthoại thông minh, máy tính bảng, TV Bạn có thể mô phỏng các cuộc gọiđến và tin nhắn văn bản, chỉ định vị trí của thiết bị, mô phỏng chuyểnđộng xoay và các cảm biến phần cứng khác, truy cập Cửa hàng GooglePlay,…

2 Instant Run để đẩy các thay đổi vào ứng dụng đang chạy của bạn màkhông cần xây dựng một APK mới

Tính năng Instant Run giúp lập trình viên cập nhật những thay đổi vàoứng dụng mà bạn đang chạy mà không gây khởi động lại ứng dụng Nhờđó, người dùng không phải tạo một APK nào khác.

3 Tích hợp GitHub để giúp bạn xây dựng các tính năng ứng dụng phổbiến và nhập mã mẫu

Bạn có thể kết nối với GitHub để giúp bạn xây dựng các tính năng ứngdụng phổ biến và nhập mã mẫu GitHub được tích hợp trực tiếp vớiAndroid Studio giúp quản lý dự án trực tiếp với GitHub ngay trênAndroid Studio mà không cần mất thời gian để tải file, giải nén và importtừ bên ngoài về vào trong Android Studio.

4 Hỗ trợ C ++ và NDK

Trong Android Studio, Android NDK là bộ công cụ giúp bạn có thể pháttriển các ứng dụng android sử dụng ngôn ngữ lập trình C, C ++ NDKcung cấp các thư viện giúp bạn quản lý các hoạt động ứng dụng và truycập các thành phần thiết bị vật lý, chẳng hạn như cảm biến và đầu vàocảm ứng.

5 Tích hợp hỗ trợ Google Cloud Platform, dễ dàng tích hợp GoogleCloud và App Engine

Google Cloud Platform cho phép bạn xây dựng, thử nghiệm và triển khaicác ứng dụng trên cơ sở hạ tầng đáng tin cậy và có khả năng mở rộng caocủa Google Ngoài ra, bạn có thể tích hợp với Google App Engine, cungcấp một hệ thống gồm ngôn ngữ lập trình (C#, Go, Python, Java, Ruby,PHP, ), hệ cơ sở dữ liệu, các thư viện lập trình, người lập trình sẽ viếtứng dụng và ứng dụng này sẽ chạy trên các máy chủ của Google.

6 Hỗ trợ tích hợp sâu Firebase vào trong các ứng dụng

Firebase là một dịch vụ API dùng để lưu trữ và đồng bộ dữ liệu thời gianthực (Real-time data) Firebase giúp các lập trình viên phát triển các ứngdụng bằng cách đơn giản hóa các thao tác với cơ sở dữ liệu Bạn có thể

Trang 5

khám phá và tích hợp các dịch vụ Firebase trong ứng dụng của mình trựctiếp từ Android Studio trong cửa sổ trợ lý (Assistant).

1.1.2 Kotlin

Kotlin là ngôn ngữ lập trình được phát triển bởi JetBrains Nó xuất hiệnlần đầu năm 2011 khi JetBrains công bố dự án của họ mạng tên "Kotlin".Đây là một ngôn ngữ mã nguồn mở

Về cơ bản, cũng như Java, C hay C++ , Kotlin cũng là "ngôn ngữ lậptrình kiểu tĩnh" Nghĩa là các biến không cần phải định nghĩa trươc khi sửdụng Kiểu tĩnh thực hiện việc kê khai nghiêm ngặt hoặc khởi tạo cácbiến trước khi chúng được sử dụng

Kiểu tĩnh không có nghĩa chúng ta phải khai báo tất cả các biến lúc đầutrước khi sử dụng chúng Các biến có thể được khởi tạo bất cứ nơi nàotrong chương trình và chúng ta có thể sử dụng chúng bất cứ nơi nào khicần Ví dụ:

Ngoài class và method của lập trình hướng đối tượng, Kotlin cũng hỗ trợlập trình thủ tục với việc sử dụng hàm.

Giống như Java, C and C++, điểm mấu chốt của chương trình Kotlin làhàm "main" Nó thông qua một mảng chứa bất kỳ đối số của commandline nào Ví dụ

Trang 6

Phần đuôi file của Java là java, class, jar thì phần đuôi file của Kotlin là.kt và kts.

Ngày 17/5/2017, tại Google I/O keynote, Android team đã thông báoKotlin sẽ trở thành ngôn ngữ chính thức của Android.

Điểm mạnh của Kotlin:

Kotlin biên dịch thành JVM bytecode hoặc JavaScript - Giống như Java,Bytecode cũng là format biên dịch cho Kotlin Bytecode nghĩa là một khiđã biên dịch, các đoạn code sẽ chạy thông qua một máy ảo thay vì một bộxử lý Bằng cách này, code có thể chạy trên bất kỳ nền tảng nào, khi nóđược biên dịch và chạy thông qua máy ảo Khi Kotlin được chuyển đổithành bytecode, nó có thể truyền được qua mạng và thực hiện bởi JVMKotlin có thể sử dụng tất cả các nền tảng và thư viện Java hiện có - Bất kểlà nền tảng cao cấp dựa trên xử lý annotation Điều quan trọng là Kotlindễ dàng tích hợp với Maven, Gradle hay các hệ thống build khác.

Kotlin dễ học và dễ tiếp cận Có thể học dễ dàng bằng những ví dụ thamkhảo đơn giản Cú pháp đơn giản và trực quan Kotlin khá giống Scalanhưng dễ hiểu hơn

Kotlin là mã nguồn mở nên không tốn kém gì để có thể sử dụng

Chuyển đổi tự động Java thành Kotlin - JetBrains tích hợp chức năng mớivào IntelliJ để chuyển đổi Java thành Kotlin và điều này tiết kiệm mộtlượng thời gian rất lớn Nó cũng giúp chúng ta không phải code lại kiểutay to

Trang 7

Null-safety của Kotlin: giúp chúng ta thoát khỏi NullPointerExceptions.Giúp chúng ta tránh những exeption kiểu con trỏ null Trong Kotlin, hệthống sẽ từ chối biên dịch đoạn code đang gán hay trả về giá trị null

Review code không còn là vấn đề - Kotlin tập trung nhiều hơn vào việccú pháp dễ hiểu, dễ đọc để review, chúng có thể hoàn thành bởi nhữngthành viên team chưa quen với ngôn ngữ này.

1.1.3 Room Database (SQLite)

Những ứng dụng xử lý dữ liệu có cấu trúc với lượng không nhỏ có thểđược hưởng nhiều lợi ích khi lưu dữ liệu đó trên máy Trường hợp sửdụng phổ biến nhất là lưu các phần dữ liệu có liên quan vào bộ nhớ đệm.Bằng cách này, khi thiết bị không thể truy cập mạng, người dùng vẫnduyệt qua được nội dung đó dù không có kết nối mạng.

Thư viện lưu trữ Room cung cấp một lớp trừu tượng qua SQLite để manglại khả năng truy cập cơ sở dữ liệu dễ dàng, đồng thời khai thác toàn bộsức mạnh của SQLite Cụ thể, Room đem lại các lợi ích sau:

- Xác minh thời gian biên dịch của truy vấn SQL.

- Chú thích tiện lợi giúp giảm thiểu mã nguyên mẫu lặp lại, dễ mắc lỗi.- Hợp lý hoá đường dẫn di chuyển cơ sở dữ liệu.

Do những điểm cần lưu ý này, bạn nên dùng Room thay vì sử dụng trựctiếp API SQLite.

Lớp cơ sở dữ liệu cung cấp cho ứng dụng của bạn các thực thể của DAOđược liên kết với cơ sở dữ liệu đó Đổi lại, ứng dụng có thể dùng DAO đểtruy xuất dữ liệu từ cơ sở dữ liệu dưới dạng thực thể của đối tượng thựcthể dữ liệu được liên kết Ứng dụng cũng có thể dùng các thực thể dữ liệuđã xác định để cập nhật các hàng trong bảng tương ứng hoặc tạo hàngmới để chèn dữ liệu Hình 1 minh hoạ mối quan hệ giữa nhiều thành phầncủa Room.

Trang 8

Thiết lập

Để dùng Room trong ứng dụng của bạn, hãy thêm các phần phụ thuộc sauvào tệp build.gradle của ứng dụng:

Trang 9

Phương thức triển khai mẫu:

Phần này trình bày phương thức triển khai mẫu cho cơ sở dữ liệu Roomvới một thực thể dữ liệu và một DAO duy nhất.

kapt("androidx.room:room-compiler:$roomVersion") // To use Kotlin Symbolic Processing (KSP)

ksp("androidx.room:room-compiler:$roomVersion")

// optional - Kotlin Extensions and Coroutines support for Room implementation("androidx.room:room-ktx:$roomVersion") // optional - RxJava2 support for Room

implementation("androidx.room:room-rxjava2:$roomVersion") // optional - RxJava3 support for Room

implementation("androidx.room:room-rxjava3:$roomVersion") // optional - Guava support for Room, including Optional and ListenableFuture

implementation("androidx.room:room-guava:$roomVersion") // optional - Test helpers

testImplementation("androidx.room:room-testing:$roomVersion") // optional - Paging 3 Integration

implementation("androidx.room:room-paging:2.5.0-alpha01")}

Trang 10

Đối tượng truy cập dữ liệu (DAO)

Mã sau đây xác định một DAO có tên UserDao UserDao cung cấp cácphương thức mà phần còn lại của ứng dụng sẽ dùng để tương tác với dữliệu trong bảng user.

Cơ sở dữ liệu

Mã sau đây xác định một lớp AppDatabase để lưu giữ cơ sở dữ liệu.AppDatabase xác định cấu hình cơ sở dữ liệu và đóng vai trò là điểm truycập chính của ứng dụng vào dữ liệu cố định Lớp cơ sở dữ liệu phải đápứng các điều kiện sau:

Lớp phải được chú thích bằng thẻ chú thích @Database có chứa mảngentities liệt kê mọi thực thể dữ liệu được liên kết với cơ sở dữ liệu.

Lớp này phải là một lớp trừu tượng mở rộng RoomDatabase.

Đối với mỗi lớp DAO được liên kết với cơ sở dữ liệu, lớp cơ sở dữ liệuphải xác định một phương thức trừu tượng không có đối số và trả về mộtthực thể của lớp DAO.

data class User(

@PrimaryKey val uid: Int,

@ColumnInfo(name = "first_name") val firstName: String?, @ColumnInfo(name = "last_name") val lastName: String?)

Trang 11

1.1.4 …

1.2 Top 10 OWASP Mobile Risks - Final List 2016

1.2.1 M1: Improper Platform Usage (Sử dụng nền tảng không phùhợp)

Tác nhân đe dọa

Ứng dụng cụ thể

Danh mục này bao gồm việc sử dụng sai một tính năng của nền tảng hoặckhông sử dụng các biện pháp kiểm soát bảo mật của nền tảng Nó có thểbao gồm Android intents, quyền nền tảng, lạm dụng TouchID, Keychainhoặc một số kiểm soát bảo mật khác là một phần của hệ điều hành diđộng.

Vectơ tấn công

Khả năng khai thác DỄ DÀNG

Các vectơ tấn công tương ứng với các vectơ tấn công giống nhau có sẵntrong Top Ten OWASP truyền thống Bất kỳ lệnh gọi API nào bị lộ đều cóthể đóng vai trò là vectơ tấn công tại đây.

Điểm yếu về bảo mật

Mức độ phổ biến THƯỜNG GẶPKhả năng phát hiện TRUNG BÌNH

Để lỗ hổng này có thể bị khai thác, tổ chức phải hiển thị một dịch vụ webhoặc lệnh gọi API được sử dụng bởi ứng dụng dành cho thiết bị di động.Dịch vụ bị lộ hoặc lệnh gọi API được triển khai bằng cách sử dụng các kỹthuật mã hóa không an toàn tạo ra lỗ hổng OWASP Top Ten trong máychủ Thông qua giao diện di động, kẻ thù có thể cung cấp các đầu vào độchại hoặc chuỗi sự kiện bất ngờ cho điểm cuối dễ bị tấn công Do đó, đốithủ nhận ra lỗ hổng OWASP Top Ten ban đầu trên máy chủ.

Tác động kỹ thuật

Tác động DỮ DỘI

Tác động kỹ thuật của lỗ hổng này tương ứng với tác động kỹ thuật của lỗhổng liên quan (được định nghĩa trong Top Ten của OWASP) mà đối thủđang khai thác thông qua thiết bị di động.

Ví dụ: kẻ thù có thể khai thác lỗ hổng Cross-Site Scripting (XSS) thôngqua thiết bị di động Điều này tương ứng với Danh mục OWASP Top TenA3 - XSS với tác động kỹ thuật ở mức trung bình.

@Database(entities = [User::class], version = 1)abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao

}

Trang 12

Tác động kinh doanh

Ứng dụng / Doanh nghiệp cụ thể

Tác động kinh doanh của lỗ hổng này tương ứng với tác động kinh doanhcủa lỗ hổng liên quan (được định nghĩa trong Top Ten OWASP) mà đốithủ đang khai thác thông qua thiết bị di động.

Ví dụ: kẻ thù có thể khai thác lỗ hổng Cross-Site Scripting (XSS) thôngqua thiết bị di động Điều này tương ứng với các tác động kinh doanh củaOWASP Top Ten A3 - XSS Category.

Tôi có dễ bị ‘sử dụng nền tảng không đúng cách’không?

Đặc điểm xác định của rủi ro trong danh mục này là nền tảng (iOS,Android, Windows Phone, v.v.) cung cấp một tính năng hoặc một khảnăng được ghi nhận và hiểu rõ Ứng dụng không sử dụng được khả năngđó hoặc sử dụng không đúng cách Điều này khác với mười rủi ro hàngđầu trên thiết bị di động khác vì thiết kế và triển khai không hoàn toàn làvấn đề của nhà phát triển ứng dụng.

Có một số cách mà các ứng dụng dành cho thiết bị di động có thể gặpphải rủi ro này.

- Vi phạm các hướng dẫn đã xuất bản Tất cả các nền tảng đều có

hướng dẫn phát triển về bảo mật (c.f., ((Android)), ((iOS)), ((WindowsPhone))) Nếu một ứng dụng trái với các phương pháp hay nhất do nhàsản xuất khuyến nghị, thì ứng dụng đó sẽ phải chịu rủi ro này Ví dụ: cócác hướng dẫn về cách sử dụng Chuỗi khóa iOS hoặc cách bảo mật cácdịch vụ đã xuất trên Android Các ứng dụng không tuân theo các nguyêntắc này sẽ gặp rủi ro này.

- Vi phạm quy ước hoặc thông lệ Không phải tất cả các phương pháp

hay nhất đều được hệ thống hóa trong hướng dẫn của nhà sản xuất Trongmột số trường hợp, có những phương pháp hay nhất trên thực tế phổ biếntrong các ứng dụng dành cho thiết bị di động.

- Sử dụng sai mục đích Một số ứng dụng có ý định thực hiện đúng,

nhưng thực tế lại thực hiện sai một số phần Đây có thể là một lỗi đơngiản, chẳng hạn như đặt cờ sai trên lệnh gọi API hoặc có thể là sự hiểunhầm về cách hoạt động của các biện pháp bảo vệ.

Trang 13

Các lỗi trong mô hình quyền của nền tảng thuộc loại này Ví dụ: nếu ứngdụng yêu cầu quá nhiều quyền hoặc sai quyền, thì tốt nhất nên phân loại ởđây.

Làm cách nào để ngăn chặn 'Sử dụng nền tảng khôngphù hợp'?

Các phương pháp cấu hình và mã hóa an toàn phải được sử dụng ở phíamáy chủ của ứng dụng di động Để biết thông tin về lỗ hổng cụ thể, hãytham khảo các dự án OWASP Web Top Ten hoặc Cloud Top Ten.

Các tình huống tấn công ví dụ

Bởi vì có một số nền tảng, mỗi nền tảng có hàng trăm hoặc hàng nghìnAPI, các ví dụ trong phần này chỉ làm nổi bật những gì có thể.

Bộ nhớ cục bộ ứng dụng thay vì Keychain iOS Keychain là một

phương tiện lưu trữ an toàn cho cả dữ liệu ứng dụng và hệ thống TrêniOS, các ứng dụng nên sử dụng nó để lưu trữ bất kỳ dữ liệu nhỏ nào có ýnghĩa bảo mật (khóa phiên, mật khẩu, dữ liệu đăng ký thiết bị, v.v.) Mộtsai lầm phổ biến là lưu trữ các mục như vậy trong bộ nhớ cục bộ của ứngdụng Dữ liệu được lưu trữ trong bộ nhớ cục bộ của ứng dụng có sẵntrong các bản sao lưu iTunes không được mã hóa (ví dụ: trên máy tínhcủa người dùng) Đối với một số ứng dụng, mức độ hiển thị đó là khôngphù hợp.

1.2.2 M2: Insecure Data Storage (Lưu trữ dữ liệu không an toàn)

Các tác nhân đe dọa bao gồm những điều sau đây: kẻ thù đã lấy đượcthiết bị di động bị mất / bị đánh cắp; phần mềm độc hại hoặc một ứngdụng đóng gói lại khác thay mặt đối thủ thực thi trên thiết bị di động.

Trong trường hợp đối thủ có được thiết bị di động một cách vật lý, đối thủsẽ kết nối thiết bị di động với một máy tính có phần mềm miễn phí.Những công cụ này cho phép đối thủ xem tất cả các thư mục ứng dụngcủa bên thứ ba thường chứa thông tin nhận dạng cá nhân được lưu trữ(PII) hoặc các tài sản thông tin nhạy cảm khác Kẻ thù có thể tạo ra phầnmềm độc hại hoặc sửa đổi một ứng dụng hợp pháp để lấy cắp các tài sảnthông tin đó.

Mức độ phổ biến THƯỜNG GẶP

Trang 14

Khả năng phát hiện TRUNG BÌNH

Lỗ hổng lưu trữ dữ liệu không an toàn xảy ra khi các nhóm phát triển chorằng người dùng hoặc phần mềm độc hại sẽ không có quyền truy cập vàohệ thống tệp của thiết bị di động và thông tin nhạy cảm sau đó trong khodữ liệu trên thiết bị Hệ thống tập tin có thể dễ dàng truy cập Các tổ chứcnên mong đợi một người dùng độc hại hoặc phần mềm độc hại kiểm tracác cửa hàng dữ liệu nhạy cảm Cần tránh sử dụng các thư viện mã hóakém Việc root hoặc bẻ khóa thiết bị di động sẽ tránh được bất kỳ biệnpháp bảo vệ mã hóa nào Khi dữ liệu không được bảo vệ đúng cách, cáccông cụ chuyên dụng là tất cả những gì cần thiết để xem dữ liệu ứngdụng.

Điều này có thể dẫn đến mất dữ liệu, trong trường hợp tốt nhất là cho mộtngười dùng và trong trường hợp xấu nhất cho nhiều người dùng Nó cũngcó thể dẫn đến các tác động kỹ thuật sau: trích xuất thông tin nhạy cảmcủa ứng dụng qua phần mềm độc hại trên thiết bị di động, ứng dụng đãsửa đổi hoặc công cụ pháp y Bản chất của tác động kinh doanh phụ thuộcnhiều vào bản chất của thông tin bị đánh cắp Dữ liệu không an toàn cóthể dẫn đến các tác động kinh doanh sau:

- Hành vi trộm cắp danh tính;- Vi phạm quyền riêng tư;- Gian lận;

- Thiệt hại về danh tiếng;

- Vi phạm chính sách đối ngoại (PCI); hoặc- Hao hụt vật chất.

- Thiệt hại về danh tiếng

- Vi phạm Chính sách Đối ngoại (PCI); hoặc- Tổn thất vật chất.

Tôi có dễ bị ‘lưu trữ dữ liệu không an toàn’ không?

Trang 15

Danh mục này lưu trữ dữ liệu không an toàn và rò rỉ dữ liệu ngoài ýmuốn Dữ liệu được lưu trữ không an toàn bao gồm, nhưng không giớihạn, những điều sau:

- Cơ sở dữ liệu SQL;- Các tệp nhật ký;

- Dữ liệu XML lưu trữ các tệp kê khai của ou;- Kho lưu trữ dữ liệu nhị phân;

- Cửa hàng bánh quy;- Thẻ SD;

- Đã đồng bộ hóa đám mây.

Rò rỉ dữ liệu ngoài ý muốn bao gồm nhưng không giới hạn ở các lỗ hổngbảo mật từ:

- Hệ điều hành;- Các khuôn khổ;

- Môi trường biên dịch;- Phần cứng mới.

- Thiết bị đã root hoặc Jailbreak

Điều này rõ ràng là nhà phát triển không hề hay biết Đặc biệt trong pháttriển thiết bị di động, điều này được nhìn thấy nhiều nhất trong các quytrình nội bộ không có tài liệu hoặc tài liệu dưới dạng như:

- Cách hệ điều hành lưu trữ dữ liệu, hình ảnh, các lần nhấn phím, ghi nhậtký và bộ đệm;

- Cách khung phát triển lưu trữ dữ liệu, hình ảnh, các lần nhấn phím, ghinhật ký và bộ đệm;

- Cách thức hoặc số lượng dữ liệu làm khung quảng cáo, phân tích, xã hộihoặc hỗ trợ dữ liệu bộ nhớ cache, hình ảnh, các lần nhấn phím, ghi nhậtký và bộ đệm.

Làm cách nào để ngăn chặn 'Lưu trữ dữ liệu khôngan toàn'?

Điều quan trọng là phải lập mô hình ứng dụng di động, hệ điều hành, nềntảng và khuôn khổ của mối đe dọa để hiểu nội dung thông tin mà ứngdụng xử lý và cách API xử lý các nội dung đó Điều quan trọng là phảixem cách chúng xử lý các loại tính năng sau:

- Bộ nhớ đệm URL (cả yêu cầu và phản hồi);- Bàn phím bấm bộ nhớ đệm;

Trang 16

- Sao chép / Dán bộ nhớ đệm bộ đệm;- Nền tảng ứng dụng;

- Dữ liệu trung gian- Ghi nhật ký;

- Lưu trữ dữ liệu HTML5;

- Đối tượng cookie của trình duyệt;

- Dữ liệu phân tích được gửi cho bên thứ ba.

Một ví dụ trực quan

iGoat là một ứng dụng di động có mục đích dễ bị tấn công dành cho cộngđồng bảo mật để khám phá các loại lỗ hổng bảo mật này trước tiên Trongbài tập dưới đây, chúng tôi nhập thông tin đăng nhập của mình và đăngnhập vào ứng dụng ngân hàng giả mạo Sau đó, chúng tôi điều hướng đếnhệ thống tệp Trong thư mục ứng dụng, chúng ta có thể thấy một cơ sở dữliệu được gọi là “credentials.sqlite” Khám phá cơ sở dữ liệu này cho thấyrằng ứng dụng đang lưu trữ tên người dùng và thông tin đăng nhập củachúng tôi

1.2.3 M3: Insecure Communication (Giao tiếp không an toàn)Tác nhân đe dọa

Khi thiết kế một ứng dụng di động, dữ liệu thường được trao đổi theokiểu máy khách-máy chủ Khi giải pháp truyền dữ liệu của nó, nó phảitruyền qua mạng của nhà cung cấp thiết bị di động và internet Các tácnhân đe dọa có thể khai thác các lỗ hổng để chặn dữ liệu nhạy cảm khi dữliệu đó đang di chuyển qua đường dây Các tác nhân đe dọa sau tồn tại:- Đối thủ chia sẻ mạng cục bộ của bạn (Wi-Fi bị xâm phạm hoặc bị giámsát);

- Nhà cung cấp dịch vụ hoặc thiết bị mạng (bộ định tuyến, tháp di động,proxy, v.v.); hoặc

- Phần mềm độc hại trên thiết bị di động của bạn.

Yếu tố khai thác của việc giám sát mạng đối với các phạm vi truyềnthông không an toàn Theo dõi lưu lượng truy cập qua mạng của một nhàcung cấp dịch vụ khó hơn so với giám sát lưu lượng truy cập của mộtquán cà phê địa phương Nói chung, các cuộc tấn công có chủ đích dễthực hiện hơn.

Trang 17

Các ứng dụng di động thường không bảo vệ lưu lượng mạng Họ có thểsử dụng SSL / TLS trong quá trình xác thực nhưng không sử dụng ở nơikhác Sự không nhất quán này dẫn đến nguy cơ lộ dữ liệu và ID phiên đểđánh chặn Việc sử dụng bảo mật giao thông không có nghĩa là ứng dụngđã triển khai nó một cách chính xác Để phát hiện các lỗi cơ bản, hãyquan sát lưu lượng mạng của điện thoại Các sai sót tinh vi hơn đòi hỏiphải kiểm tra thiết kế của ứng dụng và cấu hình ứng dụng.

Lỗ hổng này làm lộ dữ liệu của một người dùng cá nhân và có thể dẫnđến việc đánh cắp tài khoản Nếu đối thủ chặn tài khoản quản trị, toàn bộtrang web có thể bị lộ Thiết lập SSL kém cũng có thể tạo điều kiện chocác cuộc tấn công lừa đảo và MITM.

- Thiệt hại danh tiếng.

Tôi có dễ bị ‘giao tiếp không an toàn’ không?

Rủi ro này bao gồm tất cả các khía cạnh của việc lấy dữ liệu từ điểm Ađến điểm B, nhưng thực hiện nó không an toàn Nó bao gồm thông tinliên lạc giữa thiết bị di động với thiết bị di động, giao tiếp từ ứng dụngđến máy chủ hoặc liên lạc từ thiết bị di động sang thứ khác Rủi ro nàybao gồm tất cả các công nghệ truyền thông mà thiết bị di động có thể sửdụng: TCP / IP, WiFi, Bluetooth / Bluetooth-LE, NFC, âm thanh, hồngngoại, GSM, 3G, SMS, v.v.

Tất cả các vấn đề liên lạc TLS ở đây Tất cả các vấn đề về NFC,Bluetooth và WiFi đều có ở đây.

Các đặc điểm nổi bật bao gồm đóng gói một số loại dữ liệu nhạy cảm vàtruyền dữ liệu đó vào hoặc ra thiết bị Một số ví dụ về dữ liệu nhạy cảmbao gồm khóa mã hóa, mật khẩu, thông tin người dùng riêng tư, chi tiết

Trang 18

tài khoản, mã thông báo phiên, tài liệu, siêu dữ liệu và mã nhị phân Dữliệu nhạy cảm có thể đến thiết bị từ máy chủ, có thể đến từ ứng dụng đếnmáy chủ hoặc có thể đi giữa thiết bị và một thứ khác cục bộ (ví dụ: thiếtbị đầu cuối NFC hoặc thẻ NFC) Đặc điểm xác định của rủi ro này là sựtồn tại của hai thiết bị và một số dữ liệu truyền giữa chúng.

Nếu dữ liệu đang được lưu trữ cục bộ trong chính thiết bị, đó là # Dữ liệuan toàn Nếu thông tin chi tiết về phiên được giao tiếp một cách an toàn(ví dụ: qua kết nối TLS mạnh) nhưng bản thân bộ nhận dạng phiên khôngtốt (có lẽ nó có thể dự đoán được, entropy thấp, v.v.) thì đó là sự cố#Insecure Authentication, không phải sự cố giao tiếp.

Các rủi ro thông thường của giao tiếp không an toàn là xung quanh tínhtoàn vẹn của dữ liệu, tính bảo mật của dữ liệu và tính toàn vẹn của nguồngốc Nếu dữ liệu có thể bị thay đổi khi đang truyền mà không thể pháthiện được thay đổi (ví dụ: thông qua một cuộc tấn công trung gian) thì đólà một ví dụ điển hình về rủi ro này Nếu dữ liệu bí mật có thể bị lộ, họcđược hoặc thu được bằng cách quan sát quá trình liên lạc khi nó xảy ra(tức là nghe trộm) hoặc bằng cách ghi lại cuộc trò chuyện khi nó xảy ravà tấn công nó sau đó (tấn công ngoại tuyến), đó cũng là một vấn đề liênlạc không an toàn Không thể thiết lập và xác thực đúng cách kết nối TLS(ví dụ: kiểm tra chứng chỉ, mật mã yếu, các sự cố cấu hình TLS khác) đềunằm ở đây trong giao tiếp không an toàn.

Làm cách nào để ngăn chặn 'giao tiếp không antoàn'?

Các phương pháp hay nhất chung

- Giả sử rằng lớp mạng không an toàn và dễ bị nghe trộm.

- Áp dụng SSL / TLS để vận chuyển các kênh mà ứng dụng dành chothiết bị di động sẽ sử dụng để truyền thông tin nhạy cảm, mã thông báophiên hoặc dữ liệu nhạy cảm khác tới API phụ trợ hoặc dịch vụ web.- Tài khoản cho các thực thể bên ngoài như công ty phân tích bên thứ ba,mạng xã hội, v.v bằng cách sử dụng phiên bản SSL của họ khi một ứngdụng chạy quy trình thông qua trình duyệt / webkit Tránh các phiên SSLhỗn hợp vì chúng có thể làm lộ ID phiên của người dùng.

- Sử dụng các bộ mật mã tiêu chuẩn công nghiệp, mạnh mẽ với độ dàikhóa thích hợp.

- Sử dụng chứng chỉ được ký bởi nhà cung cấp CA đáng tin cậy.

- Không bao giờ cho phép chứng chỉ tự ký và xem xét ghim chứng chỉcho các ứng dụng có ý thức bảo mật.

- Luôn yêu cầu xác minh chuỗi SSL.

Trang 19

- Chỉ thiết lập kết nối an toàn sau khi xác minh danh tính của máy chủđiểm cuối bằng cách sử dụng các chứng chỉ đáng tin cậy trong chuỗikhóa.

- Cảnh báo người dùng thông qua giao diện người dùng nếu ứng dụngdành cho thiết bị di động phát hiện chứng chỉ không hợp lệ.

- Không gửi dữ liệu nhạy cảm qua các kênh thay thế (ví dụ: SMS, MMShoặc thông báo).

- Nếu có thể, hãy áp dụng một lớp mã hóa riêng biệt cho bất kỳ dữ liệunhạy cảm nào trước khi nó được cấp cho kênh SSL Trong trường hợp cáclỗ hổng trong tương lai được phát hiện trong quá trình triển khai SSL, dữliệu được mã hóa sẽ cung cấp một biện pháp bảo vệ thứ cấp chống lại viphạm bảo mật.

Các mối đe dọa mới hơn cho phép kẻ thù nghe trộm lưu lượng truy cậpnhạy cảm bằng cách chặn lưu lượng truy cập trong thiết bị di động ngaytrước khi thư viện SSL của thiết bị di động mã hóa và truyền lưu lượngmạng đến máy chủ đích Xem M10 để biết thêm thông tin về bản chất củarủi ro này.

Các phương pháp hay nhất cụ thể cho iOS

Các lớp mặc định trong phiên bản iOS mới nhất xử lý rất tốt việc thươnglượng độ mạnh của mật mã SSL Rắc rối xảy ra khi các nhà phát triển tạmthời thêm mã để bỏ qua các mặc định này để giải quyết các trở ngại pháttriển Ngoài các thông lệ chung trên:

Đảm bảo rằng chứng chỉ hợp lệ và không bị đóng.

Khi sử dụng CFNetwork, hãy cân nhắc sử dụng API truyền tải an toàn đểchỉ định chứng chỉ ứng dụng khách đáng tin cậy Trong hầu hết các tìnhhuống, NSStreamSocketSecurityLevelTLSv1 nên được sử dụng để có độbền mật mã tiêu chuẩn cao hơn.

Sau khi phát triển, đảm bảo tất cả các lệnh gọi NSURL (hoặc trình baobọc của NSURL) không cho phép các chứng chỉ tự ký hoặc không hợp lệ,

Cân nhắc sử dụng tính năng ghim chứng chỉ bằng cách thực hiện như sau:xuất chứng chỉ của bạn, đưa chứng chỉ đó vào gói ứng dụng và cố định nóvào đối tượng tin cậy của bạn Sử dụng kết nối phương thức NSURL:willSendRequestForAuthenticationChallenge: bây giờ sẽ chấp nhậnchứng chỉ của bạn.

Các phương pháp hay nhất dành riêng cho Android

Trang 20

- Xóa tất cả mã sau chu kỳ phát triển có thể cho phép ứng dụng chấp nhận tấtcả các chứng chỉ như org.apache.http.conn.ssl.AllowAllHostnameVerifier hoặcSSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER.

- Nếu sử dụng một lớp mở rộng SSLSocketFactory, hãy đảm bảo rằngphương thức checkServerTrusted được triển khai đúng cách để chứng chỉmáy chủ được kiểm tra chính xác.

Có một số tình huống phổ biến mà người kiểm tra khả năng thâm nhậpthường phát hiện khi kiểm tra bảo mật giao tiếp của ứng dụng dành chothiết bị di động:

Thiếu kiểm tra chứng chỉ

Ứng dụng dành cho thiết bị di động và một điểm cuối kết nối thành côngvà thực hiện bắt tay TLS để thiết lập một kênh an toàn Tuy nhiên, ứngdụng dành cho thiết bị di động không thể kiểm tra chứng chỉ do máy chủcung cấp và ứng dụng dành cho thiết bị di động chấp nhận vô điều kiệnbất kỳ chứng chỉ nào do máy chủ cung cấp Điều này phá hủy mọi khảnăng xác thực lẫn nhau giữa ứng dụng dành cho thiết bị di động và điểmcuối Ứng dụng dành cho thiết bị di động dễ bị tấn công trung gian thôngqua proxy TLS.

Đàm phán bắt tay yếu

Ứng dụng dành cho thiết bị di động và một điểm cuối kết nối và thươnglượng thành công một bộ mật mã như một phần của quá trình bắt tay kếtnối Máy khách thương lượng thành công với máy chủ để sử dụng bộ mậtmã yếu dẫn đến mã hóa yếu mà đối thủ có thể dễ dàng giải mã Điều nàygây nguy hiểm cho tính bảo mật của kênh giữa ứng dụng dành cho thiếtbị di động và điểm cuối.

Rò rỉ thông tin quyền riêng tư

Ứng dụng dành cho thiết bị di động truyền thông tin nhận dạng cá nhântới một điểm cuối qua các kênh không an toàn thay vì qua SSL Điều nàygây nguy hiểm cho tính bảo mật của bất kỳ dữ liệu nào liên quan đếnquyền riêng tư giữa ứng dụng dành cho thiết bị di động và điểm cuối.

1.2.4 M4: Insecure Authentication (Xác thực không an toàn)

Trang 21

Các tác nhân đe dọa khai thác lỗ hổng xác thực thường làm như vậythông qua các cuộc tấn công tự động sử dụng các công cụ có sẵn hoặcđược xây dựng tùy chỉnh.

Sau khi đối thủ hiểu sơ đồ xác thực dễ bị tấn công như thế nào, chúng sẽgiả mạo hoặc bỏ qua xác thực bằng cách gửi yêu cầu dịch vụ tới máy chủphụ trợ của ứng dụng dành cho thiết bị di động và bỏ qua bất kỳ tươngtác trực tiếp nào với ứng dụng dành cho thiết bị di động Quá trình gửinày thường được thực hiện thông qua phần mềm độc hại di động trongthiết bị hoặc các mạng botnet do kẻ tấn công sở hữu.

Các kế hoạch xác thực kém hoặc bị thiếu cho phép kẻ thù thực thi chứcnăng ẩn danh trong ứng dụng dành cho thiết bị di động hoặc máy chủ phụtrợ được ứng dụng di động sử dụng Xác thực yếu hơn cho các ứng dụngdành cho thiết bị di động khá phổ biến do yếu tố hình thức đầu vào củathiết bị di động Yếu tố hình thức rất khuyến khích các mật khẩu ngắnthường hoàn toàn dựa trên mã PIN 4 chữ số Yêu cầu xác thực đối vớiứng dụng dành cho thiết bị di động có thể khá khác so với các lược đồxác thực web truyền thống do các yêu cầu về tính khả dụng.

Trong các ứng dụng web truyền thống, người dùng phải trực tuyến và xácthực trong thời gian thực với một máy chủ phụ trợ Trong suốt phiên làmviệc của họ, có một kỳ vọng hợp lý rằng họ sẽ có quyền truy cập liên tụcvào Internet.

Trong các ứng dụng dành cho thiết bị di động, người dùng không phải lúcnào cũng trực tuyến trong phiên của họ Kết nối internet di động kém tincậy hoặc có thể dự đoán được so với kết nối web truyền thống Do đó,các ứng dụng dành cho thiết bị di động có thể có các yêu cầu về thời gianhoạt động yêu cầu xác thực ngoại tuyến Yêu cầu ngoại tuyến này có thểphân chia sâu sắc về những điều mà các nhà phát triển phải xem xét khitriển khai xác thực di động.

Để phát hiện các lược đồ xác thực kém, người kiểm tra có thể thực hiệncác cuộc tấn công nhị phân chống lại ứng dụng dành cho thiết bị di độngkhi ứng dụng đang ở chế độ "ngoại tuyến" Thông qua cuộc tấn công,người kiểm tra sẽ buộc ứng dụng bỏ qua xác thực ngoại tuyến và sau đóthực thi chức năng cần xác thực ngoại tuyến (để biết thêm thông tin về