Thời gian tạo đồ thị CPG so với kích thước của mã nguồn

7 Tổng kết

6.2Thời gian tạo đồ thị CPG so với kích thước của mã nguồn

6.2 Vector hóa đồ thị

Bước ánh xạ đồ thị thành các vector đặc trưng bao gồm việc khai thác các mẫu đồ thị phổ biến và lựa chọn mẫu có giá trị để làm đặc trưng. Cả hai thuật toán gSpan và MMRFS đều cần được cung cấp một số tham số do người dùng tự định nghĩa. Chúng tôi thực hiện đánh giá nhiều lần với các bộ giá trị tham số khác nhau (Bảng 6.1) để lựa chọn bộ giá trị cho kết quả phù hợp nhất.

Bảng 6.1: Tập giá trị thử nghiệm cho các tham số tùy chỉnh cho bước Vector hóa đồ thị

Giải thuật Tham số tùy chỉnh Tập giá trị thử nghiệm gSpan với lớp dữ

liệu an toàn max_supportmin_support {0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8}{0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8}

gSpan với lớp dữ

liệu không an toàn max_supportmin_support {0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8}{0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8}

gSpan với lớp dữ

liệu khác max_supportmin_support {0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9}{0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8}

MMRFS δ {5, 10, 15, 20, 25, 30, 35, 40, 45, 50} Kết quả lựa chọn bộ giá trị tùy chỉnh phù hợp được thể hiện như trong Bảng 6.2.

Bảng 6.2: Giá trị được chọn cho các tham số tùy chỉnh cho bước Vector hóa đồ thị

Lỗ hỗng Giải thuật Tham số tùy chỉnh Số lượng mẫu thu được

SQLi

gSpan với lớp dữ

liệu an toàn max_support = 0.4min_support = 0.6 217

gSpan với lớp dữ

liệu không an toàn max_support = 0.3min_support = 0.6 109

gSpan với lớp dữ

liệu khác max_support = 0.1min_support = 0.8 497

MMRFS δ = 10 75

XSS

gSpan với lớp dữ

liệu an toàn max_support = 0.5min_support = 0.6 268

gSpan với lớp dữ

liệu không an toàn max_support = 0.4min_support = 0.7 305

gSpan với lớp dữ

liệu khác max_support = 0.1min_support = 0.8 542

MMRFS δ = 25 70

Kết quả của việc lựa chọn đặc trưng cho thấy ưu điểm rõ rêt, số lượng mẫu cho ra cuối cùng giảm còn khoảng 1/10 so với số lượng ban đầu khai thác được.

6.3 Hiệu suất của các bộ phân loại

Hai bộ phân loại là Decision Tree và Random Forest cũng thông qua quá trình thử nghiệm các tham số để lựa chọn ra bộ giá trị phù hợp cuối cùng. Các tham số tương ứng với mô (adsbygoogle = window.adsbygoogle || []).push({});

Chương 6

hình được cung cấp sẵn trong thư viện scikit-learning và được thể hiện cụ thể trong Bảng 6.3.

Bảng 6.3: Giá trị được chọn cho các tham số tùy chọn của mô hình phân loại

Lỗ hỗng Bộ phân loại Tham số tùy chỉnh

SQLi

Decision Tree max_depth = 30min_samples_leaf = 2 max_features = None Random Forest n_estimators = 300 max_depth = None min_samples_split = 5 min_samples_leaf = 1 max_features = sqrt SVM kernel = rbfC = 10 XSS

Decision Tree max_depth = Nonemin_samples_leaf = 10 max_features = None Random Forest n_estimators = 500 max_depth = None min_samples_leaf = 2 max_features = sqrt SVM kernel = rbf C = 100 6.3.1 Các chỉ số đánh giá

Mục 4.2 đã đề cập tới vấn đề về sự mất cân bằng của tập dữ liệu. Do đó, ta sẽ khảo sát đồng thời nhiều chỉ số để đánh giá hiệu quả của hai bộ phân loại được sử dụng. Bảng 6.4 trình bày chi tiêt kết quả kiểm tra các chỉ số.

Ở hầu hết các chỉ số, mô hình Random Forest và SVM đạt được kết quả cao hơn so với mô hình Decision Tree. Điều này có thể được lí giải nhờ sức mạnh của thuật toán học tổng hợp từ nhiều cây quyết định con trong mô hình Random Forest, dẫn đến khả năng dự đoán của mô hình cũng chính xác hơn. Bản thân SVM cũng là mô hình có đặc điểm phù hợp và có khả năng cho kết quả tốt đối với các bài toán dạng phân loại nhị phân. Một điểm nữa cần lưu ý khi quan sát các chỉ số là cả ba mô hình đều phân loại tốt đối với các file an toàn, không chứa lỗ hổng. Tuy nhiên, đối với các file có lỗ hổng, chỉ số precision chỉ đạt mức khá (0.6 - 0.7). Điều này có nghĩa một số lượng tương đối các file an toàn nằm trong tập hợp các file được phân loại là có chứa lỗ hổng bảo mật. Chỉ số recall ở tất cả các hàng đều duy trì trong khoảng 0.79 - 0.87. Con số này cho thấy phần lớn các file được phân loại theo đúng nhãn của nó. Tuy nhiên, đối với một công cụ phân loại lỗ hổng bảo mật, người sử dụng sẽ không mong muốn bị bỏ sót lỗ hổng bảo mật nào trong mã nguồn. Vậy nên hiệu quả phân loại của công cụ chỉ đang ở mức tạm chấp nhận

Bảng 6.4: Các chỉ số đánh giá độ hiệu quả của mô hình phân loại

Bộ phân loại Lỗ hổng Lớp Precision Recall F1-score Accuracy Decision

Tree

SQLi Không an toànAn toàn 0.930.68 0.810.87 0.860.77 0.83

XSS Không an toànAn toàn 0.790.73 0.800.81 0.800.77 0.78

Random Forest

SQLi Không an toànAn toàn 0.920.71 0.830.85 0.870.77 0.84

XSS Không an toànAn toàn 0.800.74 0.820.81 0.810.78 0.79

SVM SQLi

An toàn 0.90 0.84 0.87 0.84

Không an toàn 0.72 0.82 0.77

XSS Không an toànAn toàn 0.800.74 0.790.82 0.790.78 0.78

Chương 6

6.4 Kiểm thử giao diện hệ thống

Trong phần này, chúng tôi trình bày một số testcase thực hiện kiểm thử cho các chức năng trên giao diện được hiện thực. Các testcase được trình bày cụ thể ở trong Bảng 6.5.

Bảng 6.5: Các chỉ số đánh giá độ hiệu quả của mô hình phân loại

STT Nội dung Kết quả Ghi

chú Chức năng dự đoán lỗ hổng

1 Truy cập vào trang điều

khiển của công cụ Giao diện hiển thị bảng điều khiểnvà vùng hiển thị kết quả trống Pass 2 Chọn file mã nguồn cần

kiểm tra Hiển thị tên file được chọn trong ôchứa tên file Pass 3 Chọn loại lỗ hổng bảo mật (adsbygoogle = window.adsbygoogle || []).push({});

cần kiểm tra:XSS,SQLi, cả

hai (Both)

Tên của loại lỗ hổng được chọn được thay đổi từ màu trắng thành màu xanh

Pass

4 Chọn bộ phân loại để dự đoán: Decision Tree, Ran- dom Forest, SVM

Tên của loại bộ phân loại được chọn được thay đổi từ màu trắng thành màu xanh

Pass

5 Nhấn nút Scan để gửi yêu

cầu kiểm tra tới hệ thống Hệ thống kiểm tra và thực hiện dựđoán sự tồn tại của lỗ hổng trong file mã nguồn được tải lên với các lựa chọn được người dùng thiết lập. Kết quả được trả về và hiển thị trên màn hình

Pass

Chức năng hiển thị thông tin mã nguồn

1 Chọn chế độ hiển thị là Ed-

itor Nội dung mã nguồn được kiểm trahiển thị trên màn hình giao diện Pass 2 Chọn chế độ hiển thị là

CPG Đồ thị CPG của mã nguồn đượchiển thị với khả năng thu giảm, mở rộng các nút và liên kết

Pass

Chức năng tạo báo cáo

1 Nhấn nút Generate Report

để tạo báo cáo về kết quả kiểm tra mã nguồn

File báo cáo được tạo và tự động

7

Tổng kết

Chương này sẽ trình bày các kết quả đạt được từ quá trình làm luận văn. Đồng thời phân tích những hạn chế còn tồn tại và chỉ ra các hướng mở rộng phát triển cho các nghiên cứu trong cùng lĩnh vực trong tương lai.

7.1 Kết quả đạt được

Qua quá trình thực hiện đề tài “Xây dựng công cụ sử dụng học máy tìm kiếm lỗ hổng bảo mật trong ứng dụng web”, chúng tôi kiểm chứng khả năng áp dụng các kỹ thuật học máy và khai phá dữ liệu để phát hiện mã nguồn dễ bị tấn công trong một ngôn ngữ lập trình động, cụ thể là PHP. Kết quả chính của luận văn này là công cụ có thể nhận diện lỗ hổng bảo mật trong mã nguồn PHP bằng cách sử dụng một bộ phân loại học máy và các đặc trưng được trích xuất thông qua khai thác mẫu đồ thị. Từ đó khẳng định tiềm năng của hướng nghiên cứu áp dụng học máy vào quy trình kiểm tra mã nguồn. Bên cạnh đó, chúng tôi còn đề xuất một phương pháp để ánh xạ thông tin từ biểu diễn dạng cấu trúc của mã nguồn là đồ thị CPG thành các đặc trưng có giá trị phân loại cao cho quá trình xây dựng mô hình học máy. Điều này cung cấp thêm một hướng giải quyết khác cho vấn đề về vector hóa mã nguồn khi xây dựng công cụ kiểm tra kết hợp với các kỹ thuật định hướng dữ liệu.

7.2 Hạn chế7.2.1 Tập dữ liệu 7.2.1 Tập dữ liệu

Đối với đề tài này, tập dữ liệu có ảnh hưởng to lớn đến hai giai đoạn chính của quá trình nhận diện lỗ hổng, bao gồm bước khai thác mẫu đặc trưng và xây dựng mô hình phân loại. Mục 4.2 của luận văn đã trình bày thông tin về tập dữ liệu SARD được sử dụng. Tuy cung cấp một số lượng lớn các file được phân loại rõ ràng và có thông tin chi tiết kèm theo về lỗ hổng, tập dữ liệu này vẫn còn nhiều khuyết điểm khiến khiến nó không tương thích hoàn toàn với mục đích sử dụng trong luận văn.

Thứ nhất, mã nguồn có chứa lỗ hổng trong tập dữ liệu này được tạo ra bởi công cụ do nhóm tác giả của nghiên cứu [27] hiện thực. Điều này đồng nghĩa với việc các mã

Chương 7

nguồn này không thực sự phản ánh sự tồn tại của lỗ hổng bảo mật trong các chương trình thực tế. Mỗi mẫu dữ liệu chỉ gói gọn trong một file nên không bao quát sự được đa dạng và phức tạp của một ứng dụng web thực sự.

Thứ hai, tập dữ liệu được phân thành các tập con theo loại lỗ hổng bảo mật bao quát nhất. Thực tế, mỗi một loại lỗ hổng bảo mật có thể được phân tích thành nhiều loại chi tiết hơn, ví dụ lỗ hổng SQLi có thể chia thành các loại chính là In-band SQLi (Classic), Inferential SQLi (Blind) và Out-of-band SQLi. Nếu có thể phân loại dữ liệu thành các lớp cụ thể như trên và cho công cụ học các đặc trưng để dự đoán, tính ứng dụng và hiệu quả sẽ được cải thiện đáng kể, thậm chí cho phép công cụ gợi ý được chính xác vị trí của lỗ hổng trong mã nguồn. (adsbygoogle = window.adsbygoogle || []).push({});

Đối với vấn đề về tập dữ liệu, nhiều tác giả [34, 18] lựa chọn xây dựng một bộ dữ liệu riêng cho nghiên cứu của mình. Công việc này đòi hỏi thu thập mã nguồn từ các ứng dụng thực tế, thực hiện rà soát lỗ hổng và gán nhãn cho mã nguồn một cách thủ công. Tuy nhiên, trong phạm vi năng lực và thời gian của đề tài, chúng tôi không thể thực hiện theo phương pháp này.

7.2.2 Phương pháp thực hiện

Phương pháp tiếp cận và hiện thực được chúng tôi sử dụng trong luận văn này còn tồn tại một số hạn chế, đặt ra các bài toán mở rộng cho việc cải thiện trong tương lai.

Thứ nhất, thiết kế hiện tại của công cụ được xác định để dữ đoán lỗ hổng bảo mật với điều kiện mã nguồn của chương trình cần xem xét đã có sẵn. Việc phát hiện các lỗ hổng của ứng dụng web mà không có mã nguồn là một bài toán riêng khác và có độ phức tạp cao hơn.

Thứ hai,công cụ hiện tại sử dụng PHPJoern cho bước tạo đồ thị CPG nên bản thân công cụ mặc định chỉ hoạt động với mã nguồn PHP. Tuy nhiên, có thể điều chỉnh module tạo đồ thị CPG để nó hoạt động với nhiều ngôn ngữ khác nhau bằng cách thay thế công cụ PHPJoern bằng công cụ Joern và thực hiện một số thay đổi cần thiết để tương thích với công cụ mới này.

Thứ ba, công cụ hiện tại chỉ có khả năng dự đoán trong file mã nguồn có hay không có tồn tại lỗ hổng bảo mật nào đó. Việc dự đoán và xác định vị trí của lỗ hổng trong mã nguồn đòi hỏi phân tích đồ thị dựa trên một mức độ chi tiết (granularity) phù hợp hơn mức file.

Thứ tư, thực tế tập dữ liệu của chúng tôi có rất nhiều mã nguồn gần giống nhau, và có khả năng chứa các mẫu trùng lặp. Do các đặc trưng phục vụ cho quá trình học máy được khai thác trực tiếp từ tập dữ liệu, khả năng các đặc trưng này bị “thiên vị” (bias) do sự trùng lặp của các mẫu dữ liệu là rất lớn.

Thứ năm, khả năng dự đoán lỗ hổng của công cụ còn giới hạn do tập dữ liệu sử dụng chỉ bao gồm hai loại lỗ hổng bảo mật là SQLi và XSS.

7.3 Phương hướng phát triển

Để công cụ có thể được hoàn thiện hơn và khắc phục được các hạn chế đã nêu ở trên, chúng tôi đề xuất một số hướng phát triển có thể được thực hiện như sau.

• Xét về vấn đề với sự thiếu hụt dữ liệu cần thiết, chúng tôi nhận thấy bộ dữ liệu được thu thập từ các kho lưu trữ mã nguồn mở là một nguồn dữ liệu có tiềm năng khai thác lớn. Việc xác định sự tồn tại lỗ hổng bảo mật có thể được xác định nhờ kiểm tra lịch sử các commit của những chương trình này và đối chiếu với danh sách các CVE. Tuy vậy, vẫn còn một trở ngại lớn đó là yêu cầu về nhân lực và thời gian để thực hiện rà soát và gán nhãn các mã nguồn. Vấn đề này có thể được xem xét như một bài gom cụm các mã nguồn có đặc điểm giống nhau thành một lớp để thực hiện gán nhãn tự động.

• Xét về tính ứng dụng của công cụ, có hai khía cạnh cần được phát triển thêm: số lượng lỗ hổng bảo mật được nhận diện và khả năng xác định vị trí lỗ hổng. Đối với việc tăng số lượng lỗ hổng bảo mật, vấn đề quan trọng nhất cần giải quyết là cung cấp dữ liệu với đa dạng các loại lỗ hỗng, nghĩa là ta phải giải quyết bài toán về tập dữ liệu đã nêu trước đó. Đối với khả năng xác định vị trí lỗ hổng, chúng tôi cho rằng các mức độ chi tiết để xem xét mã nguồn cơ bản như cấp chương trình, cấp file, cấp hàm, cấp câu lệnh, . . . chưa thực sự phù hợp. Nghiên cứu mở rộng có thể đề xuất một phương pháp chia mã nguồn thành các đơn vị cơ bản khác, phù hợp hơn cho quá trình xem xét và định vị lỗ hổng bảo mật.

• Một hướng phát triển mở rộng hơn nữa là tích hợp thêm cho công cụ khả năng tự động sửa lỗi sau khi đã xác định được lỗ hổng. Ý tưởng này xuất phát từ việc chúng tôi quan sát được nhóm dữ liệu “an toàn” cho một loại lỗ hổng bảo mật thường bao gồm các đoạn mã chứa chức năng có lỗ hổng bảo mật nhưng có sự can thiệp của các hàm sàn lọc dữ liệu trên dòng dữ liệu hoặc có sự thay đổi trong luồng thực thi so với đoạn mã nguy hiểm để tạo nên tính an toàn của nó.

Tóm lại, đề tài của chúng tôi được hoàn thành với việc hiện thực thành công một công cụ ứng dụng kĩ thuật học máy để nhận diện lỗ hổng bảo mật. Tuy nhiên, ý nghĩa của đề tài không chỉ dừng lại ở đây mà còn mở ra nhiều phương hướng phát triển mới, có tiềm năng đưa công cụ của chúng tôi nói riêng và các nghiên cứu liên quan nói chung hoàn thiện hơn, đến gần hơn với mục tiêu tự động hóa quá trình kiểm tra lỗ hổng bảo mật và hỗ trợ một cách linh hoạt và hiêu quả cho người sử dụng.

Tài liệu tham khảo

[1] Hisham Alasmary et al. “Analyzing and Detecting Emerging Internet of Things Mal- ware: A Graph-Based Approach”. In: IEEE Internet of Things Journal 6.5 (2019), pp. 8977–8988.

[2] M. Backes et al. “Efficient and Flexible Discovery of PHP Application Vulnera- bilities”. In: 2017 IEEE European Symposium on Security and Privacy (EuroS P).

2017, pp. 334–349.

[3] Michael Backes et al. “Efficient and Flexible Discovery of PHP Application Vulner- abilities”. In: 2017 IEEE European Symposium on Security and Privacy (EuroS P).

2017, pp. 334–349.

[4] D. Balzarotti et al. “Saner: Composing Static and Dynamic Analysis to Validate Sanitization in Web Applications”. In: 2008 IEEE Symposium on Security and Pri- vacy (sp 2008). 2008, pp. 387–401.

[5] Z. Bilgin et al. “Vulnerability Prediction From Source Code Using Machine Learn- ing”. In: IEEE Access 8 (2020), pp. 150672–150684.