CHƯƠNG 3: ĐỀ XUẤT CỦA CHÚNG TÔI
3.4. Đánh giá hoạt động giải thuật đề xuất
Chi phí hoạt động của giải thuật đề xuất được đánh giá dựa trên đánh giá về chi phí triển khai, cài đặt và hiệu năng của hệ thống.
Giải thuật đề xuất được xây dựng dựa trên SDriver nên cũng có một số đặc điểm tương tự. Giải thuật đề xuất chỉ cần thực hiện thêm một đoạn code để chuyển kết nối ứng dụng đi qua bộ lọc trung gian. Ngoài ra, mã nguồn ứng dụng không cần thay đổi gì thêm. Giải thuật đề xuất cũng là mã nguồn mở giống như SDriver. Vì vậy mà không có phát sinh chi phí cài đặt. Về chi phí triển khai, phần mất nhiều thời gian nhất và cũng quan trọng nhất là phần huấn luyện. Tập dữ liệu các khuôn mẫu hợp lệ cần được huấn luyện với số lượng càng lớn càng tốt. Vì vậy mà cũng dẫn đến việc tiêu tốn chi phí huấn luyện như là chi phí mua, sử dụng các phần mềm hỗ trợ huấn luyện, chi phí nhân công.
Về hiệu năng, hiệu năng của giải thuật đề xuất và SDRiver cải tiến sẽ cùng được lần lượt kiểm thử trên cùng một hệ thống và sau đó sẽ được so sánh với nhau.
Cấu hình máy tính được sử dụng để thử nghiệm là:
Cấu hình máy tính: Bộ vi xử lý Intel® Core i5-7200U 2.50 – 2.70 Ghz, Ram 4GB, SSD Kingston 240 GB
Môi trường: Java SE Develop Kit 8, Windows 10 Pro 64bit.
CSDL: MySQL version 5.7.
Kết quả thu được thể hiện trên bảng 3.1.
Chế độ SDriver cải tiến (ms) Giải thuật đề xuất (ms) Tỷ lệ (%)
Huấn luyện 4/3 4/3 100%
Thực thi 3 3 100%
Bảng 3-1 Thời gian thực thi truy vấn
Bảng 3.1 trên thể hiện thời gian thực thi câu truy vấn, đơn vị mili giây (ms), Tỷ lệ được tính bằng % thời gian sử dụng của hai giải pháp.
Về cơ bản, giải thuật đề xuất tiến hành thêm một bước loại bỏ những chuỗi chú thích không cần thiết nên thời gian tạo khuôn mẫu không thay đổi nhiều. Tiếp theo là dữ liệu trong bảng signatures và bảng anomaly cho đến khi đánh giá không lớn nên thời gian tìm kiếm trong CSDL ssql cũng không đáng kể. Vì vậy, thời gian thực thi của cả hai bên là tương đương.
3.4.2. Đánh giá về độ chính xác
Đánh giá độ chính xác của giải thuật đề xuất và SDriver cải tiến thực hiện thông qua việc sử dụng công cụ Burp Suite Pro V 2.1.04.
Hình 3.15 Giao diện Burp Suite
Muốn thực hiện kiểm tra tấn công tiêm nhiễm SQL trên với Burp Suite, trước hết cần phải thực hiện cấu hình để Burp Suite có thể bắt được thông tin GET và POST của web. Trên công cụ, cấu hình proxy 127.0.0.1 port 6666 tương tự cấu hình trên trình duyệt. Sau đó thực hiện đăng nhập trên web, công cụ sẽ bắt được thông tin sử dụng cho tấn công tiêm nhiễm SQL.
Hình 3.16 Ví dụ lấy thông tin POST
Burp Suite Pro có tập hợp các payload, các mẫu dùng cho tấn công tiêm nhiễm SQL. Dựa trên thông tin POST thu được, nó sẽ thực hiện lần lượt tấn công tiêm nhiễm vào trường userName và trường password với 268 trường hợp khác nhau. Kết quả giải thuật đề xuất và SDriver cải tiến đều phát hiện đúng 268 trường hợp tấn công. Tỷ lệ phát hiện tấn công tiêm nhiễm SQL 100% với hai phương pháp. Chi tiết như bảng 3.2.
Với kiểm thử phát hiện nhầm truy vấn hợp lệ thành tấn công, tập hợp mẫu khách quan chưa được xây dựng nên chỉ thực hiện với những trường hợp tương tự tại phần 3.1. Giải thuật đề xuất đã khắc phục được lỗi phát hiện nhầm của SDriver cải tiến.
Bảng 3-2 Kết quả ngăn chặn tấn công tiêm nhiễm SQL
Tấn công SDriver cải tiến Giải thuật đề xuất Ứng dụng web tiêm nhiễm Ngăn chặn Tỷ lệ Ngăn chặn Tỷ lệ
SQL (%) (%)
SimpleWebApp 268 268 100% 268 100%
3.4.3. Một số hạn chế
Giải thuật đề xuất thực hiện lọc bỏ chuỗi ký tự độc hại trong câu truy vấn SQL. Như kết quả mô phỏng, hệ thống đã lấy được chính xác chuỗi ký tự độc hại. Tuy nhiên, việc xử lý, giới hạn hay lọc bỏ chuỗi nhập của người dùng thường được thực hiện ở mức ứng dụng web level và mang lại hiệu quả nhiều hơn ở mức này. Vì vậy mà cơ chế tìm, lọc chuỗi ký tự độc hại của giải thuật đề xuất cũng có những hạn chế.
Trước hết ,câu truy vấn có thể thực hiện áp dụng cơ chế lọc ở đây phải có dạng sau:
“… WHERE USER_NAME = AND PASSWORD =”
Với những truy vấn nếu có nhiều hơn hai phần nhập dữ liệu người dùng vào sẽ xảy ra lỗi. Ngoài ra, phương thức lấy chuỗi đang sử dụng dấu “=” và chữ
“AND” làm cố định. Nếu trường hợp kẻ tấn công thêm “‘AND” vào trường USER_NAME sẽ khiến cho chương trình chạy không đúng.
3.5. Kết chương
Nội dung chương 3 đã làm rõ SDriver cải tiến có khả năng phát hiện nhầm các câu truy vấn hợp lệ thành tấn công do trong quá trình rút gọn, các thành phần chú thích không được xử lý. Chuỗi rút gọn thu được chưa đạt được độ tổng quát nhất định.
Giải thuật đề xuất thay đổi cơ chế rút gọn nhằm tiến hành loại bỏ thành phần chú thích. Ngoài ra, giải thuật tiến hành lọc chuỗi ký tự độc hại trong chuỗi ký tự người dùng nhập vào. Một bảng gọi là anomaly chứa các chuỗi ký tự này được thêm vào CSDL ssql. Dữ liệu trong anomaly được sử dụng để phát hiện, ngăn chặn tấn công tiêm nhiễm SQL bên cạnh khớp mẫu hợp lệ.
Mô phỏng giải thuật đề xuất và đánh giá kết quả. Giải thuật đề xuất được đánh giá qua so sánh với SDriver cải tiến.
Về hiệu năng, thời gian huấn luyện với mỗi truy vấn hợp lệ, thời gian phát hiện truy vấn tấn công của hai phương pháp là tương đương nhau. Chi phí triển khai không nhiều do dùng mã nguồn mở. Mã nguồn ứng dụng không cần thay đổi nhiều.
Về độ chính xác, hai phương pháp đều phát hiện được chính xác các truy vấn tấn công. Giải thuật đề xuất đã khắc phục được lỗi phát hiện nhầm truy vấn hợp lệ thành truy vấn tấn công của SDriver cải tiến.
KẾT LUẬN
Sau thời gian tìm hiểu và thực hiện đề tài: “Chống tấn công SQL injection sử dụng các khuôn mẫu tổng quát”, luận văn đã trình bày hai phương pháp phát hiện, ngăn chặn tấn công tiêm nhiễm SQL là SDriver và SDriver cải tiến. Trong đó, luận văn đã chỉ ra được các trường hợp nhận nhầm dữ liệu hợp lệ thành dữ liệu tấn công, phương thức lấy chuỗi để hỗ trợ của SDriver cải tiến không mang nhiều ý nghĩa. Luận văn đã đưa ra một giải thuật mới, khắc phục được lỗi phát hiện nhầm truy vấn hợp lệ thành tấn công mà không làm giảm tỷ lệ phát hiện chính xác tấn công tiêm nhiễm cũng như hiệu năng chương trình. Ngoài ra, giải thuật đề xuất đã lọc được những chuỗi tấn công độc hại trong dữ liệu người dùng nhập vào và thêm vào tập dữ liệu mẫu độc hại.
Nhìn chung, luận văn đã đưa ra được những khuyến nghị để tăng khả năng chính xác của việc phát hiện, ngăn chặn tấn công tiêm nhiễm SQL của bộ lọc SDriver. Tuy nhiên luận văn vẫn còn những hạn chế đã nêu ở phần 3.4.3 chưa đưa ra được những đánh giá có tính thuyết phục hơn, như mở rộng ứng dụng web thực tế, mở rộng số lượng câu truy vấn, áp dụng với những truy vấn có độ phức tạp cao
Hướng phát triển tiếp theo: Nội dung luận văn có thể phát triển theo các hướng sau:
Tiếp tục nghiên cứu khắc phục những điểm hạn chế.
Nghiên cứu để cải thiện tính chính xác của hệ thống