Ban đầu, ngƣời dùng truyền vào một câu lệnh truy vấn SQL hoặc truyền vào các tham số để thực hiện câu truy vấn thông qua ứng dụng web sẽ đƣợc thu thập bởi “Thu thập truy vấn”. Các đầu vào này sẽ đƣợc sử dụng trong pha phân tích cú pháp cây truy vấn. Trong pha này, hệ thống sẽ trả ra các câu truy vấn và gửi nó tới một công cụ phân tích cú pháp. Ở đây, công cụ sẽ so sánh cấu trúc của cây phân tích với cấu trúc đƣợc sinh ra theo mô hình. Nếu cấu trúc của câu truy vấn đƣợc so sánh là giống thì truy vấn là hợp lý và đƣợc quyền truy xuất vào CSDL, ngƣợc lại thì sẽ bị từ chối và chặn lại.[6]
Để xác định cú pháp của một ngôn ngữ, ngƣời ta sử dụng văn phạm phi ngữ cảnh CFG (Context Free Grammar) hay còn gọi là văn phạm BNF (Backers Naur Form). Mục đích của phần này là xây dựng một văn phạm G để sản sinh ra câu lệnh truy vấn. Xét câu lệnh truy vấn SELECT SQL đơn giản:
SELECT <select_list> FROM <from_clause> WHERE <where_clause> Trong trƣờng hợp này, Văn phạm G = (∑, ∆, P, S), trong đó:
- ∑: tập hợp các ký hiệu kết thúc (terminal symbols).
∑ = {SELECT, FROM, WHERE, *, OR, AND, NOT, = | < | > | <= | >= | !=} - ∆: tập hợp các ký hiệu không kết thúc (nonterminal symbols).
∆ = {select_statement, select_list, from_clause , where_clause, id_list, id, table_list, boolean_condition, boolean_terminate, boolean_factor, condition, value, comparison_operator, string_literal, number, literal}
- S ∆: là ký hiệu không kết thúc, đƣợc sử dụng làm ký hiệu bắt đầu của văn phạm. S = select_statement
- P: tập hợp các luật sinh, trong đó mỗi luật sinh bao gồm vế trái là một ký hiệu không kết thúc, mũi tên, vế phải là một chuỗi các ký hiệu kết thúc và/hoặc các ký hiệu không kết thúc. Các luật sinh nhƣ sau:
<select_statement> → SELECT <select_list> <from_clause> <where_clause> <select_list> → <id_list> | *
<idn> → <id> | (| <id> |)
<id_list> → <idn> | <idn>, <id_list> <from_clause> → FROM <table_list> <table_list> → <id_list>
<where_clause> → WHERE <boolean_condition>
<boolean_condition> → <boolean_condition> OR <boolean_terminate> | <boolean_terminate>
<boolean_terminate> → <boolean_terminate> AND <boolean_factor> <boolean_factor> → NOT <conditionn> | <conditionn>
<conditionn> → <condition> | (| <condition> | )
<condition> → <value> <comparison_operator> <value> <value> → <idn> | <string_literal> | <numbern> <numbern> → <number> | (| <number> |)
<literaln> → <literal> | (| <literal> |) <string_literal> → „ <literaln> ‟
<comparison_operator> → = | < | > | <= | >= | !=
Với các suy dẫn nhƣ trên, ta có thể biểu diễn dƣới dạng cây phân tích cú pháp truy vấn nhƣ sau:
SELECT <select_list> <from_clause> <where_clause>
<select_list> <from_clause> <where_clause>
* <id_list>
<idn> <id_list><idn>,
<id> (| <id> |) SELECT FROM <table_list> <id_list> WHERE <boolean_condition> <boolean_terminate> <boolean_terminate> <boolean_factor> <boolean_factor> <condition> <condition> <value> <value> <value> <value> <comparison_operator> <comparison_operator> <string_literal> <idn> <numbern> <number> <(|number|)> „<literaln>‟ <literal> <(|literal|)> = | < | > | <= |
>= | != <idn> <string_literal> <numbern>
<number> <(|number|)> „<literaln>‟ <literal> <(|literal|)> <string_literal> <idn> <numbern> <number> <(|number|)> „<literaln>‟ <literal> <(|literal|)> <string_literal> <idn> <numbern> <number> <(|number|)> „<literaln>‟ <literal> <(|literal|)> = | < | > | <= | >= | !=
Hình 2.5: Cây phân tích cú pháp cho câu truy vấn SELECT
Ví dụ: xét câu truy vấn SELECT có cú pháp cụ thể sau
SELECT * FROM usertable WHERE uname = „?‟ AND password = „?‟ Cây phân tích cú pháp của truy vấn trên sẽ nhƣ sau
Hình 2.6 Cây phân tích cú pháp của câu truy vấn SELECT cụ thể
Nếu một dữ liệu truyền vào từ ngƣời dùng là hợp lệ, giả sử nhƣ câu truy vấn sau SELECT * FROM usertable WHERE uname = „eddy‟ AND password = „abc123‟ thì cây phân tích cú pháp của câu truy vấn sẽ là:
Hình 2.7: Cây phân tích cú pháp của truy vấn hợp lệ
Đây là câu truy vấn có cú pháp đƣợc phân tích giống với cú pháp của ngƣời lập trình, nên sẽ đƣợc truy vấn vào CSDL
Ngƣợc lại, xét truy vấn trong đó đầu vào từ ngƣời dùng đƣợc tiêm vào để tấn công vào CSDL nhƣ sau:
SELECT cardnum FROM accounts WHERE uname=‟John‟ AND cardtype=2 OR 1=1 Cây phân tích cú pháp của truy vấn này nhƣ sau:
Hình 2.8: Cây phân tích cú pháp của câu truy vấn không hợp lệ
Cây phân tích cú pháp này không giống với cú pháp mong muốn ban đầu của lập trình viên, nên câu truy vấn này sẽ bị chặn lại và không truy cập đƣợc vào CSDL
2.3.3. Biểu đồ luồng điều khiển
Ý tƣởng của kỹ thuật này là sử dụng biểu đồ luồng điều khiển để sinh ra các ca kiểm thử (test case), các ca kiểm thử này đƣợc sử dụng cho việc phát hiện lỗ hổng bảo mật
Định nghĩa: Đồ thị luồng điều khiển (Control Flow Graph - CFG) là đồ thị có hƣớng, biểu diễn một chƣơng trình, trong đó:
- Đỉnh: biểu diễn một lệnh tuần tự hay một khối lệnh. - Cung: biểu diễn các nhánh rẽ của lệnh điều kiện.
- Một đỉnh vào và một đỉnh ra đƣợc thêm vào để biểu diễn điểm vào và ra của chƣơng trình
Có hai loại câu lệnh cơ bản trong một đơn vị chƣơng trình, đó là: lệnh gán (assignment statement) và lệnh điều kiện (condition statement). Lệnh gán là những lệnh đƣợc biểu diễn bằng ký tự gán “ = ”. Ví dụ nhƣ: x = 2*y, trong đó x, y đều là biến. Lệnh điều kiện là các lệnh có chứa các lệnh điều khiển, nhƣ if(), lặp for(), lặp while(), goto…Trƣờng hợp không có lệnh điều kiện, các lệnh chƣơng trình đƣợc thực hiện theo trình tự mà nó xuất hiện
Lộ trình trong CFG là đƣờng đi xuất phát từ đỉnh vào, đi qua các đỉnh và cung trong đồ thị và kết thúc ở đỉnh ra. Chu trình tạo dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển đƣợc mô tả trong lƣu đồ dƣới đây[8]:
Hình 2.9: Quá trìnhsinh ra dữ liệu kiểm thử trong CFG
Tiêu chuẩn lựa chọn đƣờng đi (Path selection criteria):
- Phủ cấp 0: tất cả các đƣờng đi (bao gồm cả các đƣờng đi đƣợc và không đi đƣợc) đều đƣợc lựa chọn.
- Phủ cấp 1: Lựa chọn các đƣờng đi sao cho tất cả các lệnh đƣợc chạy ít nhất một lần.
- Phủ cấp 2: Lựa chọn các đƣờng đi sao cho mỗi điểm quyết định đều đƣợc thực hiện ít nhất một lần cho trƣờng hợp TRUE lẫn FALSE.
- Phủ cấp 3: Tổng hợp tất cả các khả năng sao cho mỗi điều kiện con (subcondition) của từng điểm quyết định đều đƣợc thực hiện ít nhất một lần cho trƣờng hợp TRUE lẫn FALSE.
Các ký hiệu sử dụng trong biểu đồ luồng điều khiển CFG: . X Điểm xuất phát Khối xử lý Điểm quyết định
Điểm nối Điểm kết thúc
2.3.4. sFuzzing
a) Tổng quan
Để đƣa ra khái niệm về fuzzing là một vấn đề khó, vì không có một nhóm, tổ chức nào hoàn toàn đồng ý về các định nghĩa liên quan tới fuzzing.
Một khái niệm mà có thể nhiều ngƣời biết tới đó là Kiểm thử hộp đen hay kỹ thuật phân tích động : Cung cấp thông tin đầu vào cho phần mềm thông qua nhiều cách giao tiếp khác nhau và không có bất kỳ một sự hiểu biết nào về hoạt động bên trong của hệ thống mà nó kiểm thử. Fuzzing là một kỹ thuật kiểm thử hộp đen, trong đó hệ thống mà nó kiểm thử nhận đƣợc các đầu vào và cấu trúc dữ liệu bất ngờ thông qua giao diện bên ngoài.
Fuzzing thuật toán trong kiểm thử tiêu cực, trái ngƣợc với kiểm tra chức năng, kiểm tra performance của hệ thống. Trong kiểm thử tiêu cực, thay vì gửi các dữ liệu hợp lý đƣợc xử lý trong code. Hệ thống kiểm thử sẽ nhận đƣợc các đầu vào hoặc chuỗi đầu vào không hợp lệ hoặc bán hợp lệ thông qua giao diện tƣơng tác.
Mục đích của fuzzing là tìm kiếm các lỗ hổng liên quan tới bảo mật hoặc bất kỳ lỗ hổng từ chối dịch vụ, suy thoái nghiêm trọng tới dịch vụ và các hành vi không mong muốn khác.
Chƣơng trình hoặc framework tạo ra fuzz test hoặc thực thi các fuzzing testing gọi là fuzzer.
Fuzzing có xu hƣớng tìm lỗi bỏ qua trong quá trình phát triển và thử nghiệm truyền thống, do ngẫu nhiên chọn dữ liệu thử nghiệm, hoặc đầu vào, không thực hiện bất kỳ giả định đối với hoạt động của phần mềm. Fuzzing có một mục tiêu duy nhất là
để sụp đổ hệ thống, để kích thích vô số đầu vào nhằm tìm thấy bất kỳ lỗ hổng nghiêm trọng nào. Một mục tiêu thứ hai của fuzzing đó là: với ngƣời chịu trách nhiệm về bảo mật thì fuzzing còn phân tích các lỗ hổng có thể khai thác[3]
Lỗ hổng có thể đƣợc sinh trong các giai đoạn phát triển phần mềm nhƣ: pha phân tích yêu cầu, thiết kế, triển khai.
Fuzzing đƣợc sử dụng nhƣ một phần trong quá trình phát triển phần mềm. Đây là giải pháp tốt nhất để phát hiện các lỗ hổng “Zero-day”. Các công cụ khác không làm đƣợc điểu này vì chúng dựa trên cơ sở là các lỗ hổng đã có trƣớc đó. Ngoài ra, các công cụ này chỉ kiểm tra và bảo vệ các phần mềm lớn và đƣợc sử dụng rộng rãi. Fuzzer có thể kiểm tra bất kỳ quá trình xử lý nào hoặc các vấn đề tƣơng tự. Fuzzing có thể kiểm tra một quá trình xử lý, dịch vụ, hệ thống, thiết bị hoặc hệ thống mạng, nó không hỗ trợ chính xác một giao diện nào.
c) Phân loại fuzzer
Fuzzer có thể đƣợc phân loại dựa trên 2 tiêu chí khác biệt nhau:
- Vector tiêm(injection) hoặc vector tấn công
- Trƣờng hợp thử nghiệm phức tạp
Fuzzer có thể đƣợc phân loại dựa trên các lĩnh vực ứng dụng mà nó đƣợc sử dụng, cơ bản là dựa theo các vector tấn công mà nó hỗ trợ.
Ví dụ về một vector tấn công hệ thống đa mức[3]
Hình 2.10:Vector tấn công hệ thống đa mức
Fuzzer cũng có thể đƣợc phân loại dựa trên các trƣờng hợp kiểm thử phức tạp. Các trƣờng hợp test sinh ra bởi fuzzing có thể nhắm tới mục tiêu là các lớp khác nhau trong phần mềm sẽ kiểm thử và thử nghiệm các trƣờng hợp thâm nhập khác nhau vào các lớp logic trong [3]
Hình 2.11: Các kiểu bất thƣờng vào mô hình báo cáo lỗi khác nhau
d) Cấu trúc logic của fuzzer
Hình 2.12: Cấu trúc logic của fuzzer
Protocol model: Kích hoạt các chức năng liên quan tới các định dạng dữ liệu và trình
tự message khác nhau
Anomaly library: Tất cả các fuzzer đều chứa một tập các đầu vào để kích hoạt các lỗ
hổng trong phần mềm.
Attack simulation engine: Sử dụng một thƣ viện các tấn công hoặc các vấn đề bất thƣờng. Các vấn đề bất thƣờng đƣợc tập hợp trong một công cụ, hoặc thay đổi ngẫu nhiên để có thể tạo ra các fuzz test trong thực tế
Runtime analysis engine: Giao diện SUT: có rất nhiều kỹ thuật có thể đƣợc sử dụng để
Reporting(báo cáo): Kết quả test sẽ đƣợc đƣa ra theo một định dạng, giúp cho những ngƣời phát triển hoặc một bên thứ ba có thể sử dụng. Một số công cụ khác không có chức năng này, còn fuzzer thì báo cáo rất chi tiết về các lỗ hổng phức tạp
Documentation: Đây là một công cụ nếu không có tài liệu ngƣời dùng thì rất khó sử
dụng. Đặc biệt là trong QA, có thể có nhiều tài liệu hƣớng dẫn sử dụng cho kịch bản test. Tài liệu hƣớng dẫn kịch bản test có thể đƣợc sử dụng khi báo cáo thay vì các tài liệu cố định.[3]
e) Quy trình fuzzing
Một quy trình fuzzing đơn giản bao gồm một chuỗi các message đƣợc gửi tới SUT. Các kết quả thay đổi và message gửi tới có thể đƣợc phân tích, trong một số trƣờng hợp có thể bị bỏ qua. Kết quả trả về điển hình của một kiểm tra fuzz bao gồm các đáp trả sau:
- Valid response(đáp trả hợp lệ).
- Error response(đáp trả lỗi).
- Anomalous response(đáp trả bất thƣờng).
- Crash or other failure (sụp đổ hay lỗi).
Hình2.13: Ví dụ về một kịch bản fuzz và kết quả trả về từ một SUT
Quá trình fuzzing không chỉ là việc gửi và nhận các message. Kiểm thử đầu tiên sẽ đƣợc tạo ra và gửi tới SUT. Giám sát mục tiêu cần đƣợc thực hiện liên tục và tất cả các thất bại đều đƣợc ghi lại để đánh giá trong các lần sau. Một phần quan trọng của quá trình fuzzing là giám sát mã lệnh khi nó xử lý một đầu vào không hợp lệ.[3]
Hình 2.14: Quá trình fuzzing bao gồm các kịch bản fuzz và một hệ thống giám sát 2.4. Công cụ dò quét lỗ hổng trong cổng thông tin điện tử
Một chƣơng trình kiểm thử lỗ hổng website nhất thiết phải có 2 thành phần chính:
- Web Crawler: Module chịu trách nhiệm đi dò quét toàn bộ nội dung website từ đó xây dựng cấu trúc website
- HTTP Fuzz: sinh ra các dữ liệu fuzzing gửi lên server dựa trên cấu trúc website thu đƣợc từ module crawler, sau đó kiểm tra response trả về để đoán nhận có lỗ hổng website hay không[9]
2.4.1. Bkav Web Scan
a) Giới thiệu công cụ
Webscan là một công cụ quét đƣợc cung cấp bởi Bkav, sử dụng công nghệ điện toán đám mây và tiếp cận theo hƣớng Saas. Để thực hiện quét lỗ hổng trên website của mình, ngƣời quản trị website đó chỉ cần truy cập vào địa chỉ Webscan.bkav.com.vn và thực hiện quét. Webscan hỗ trợ quét đồng thời nhiều website một lúc, sau khi quét xong kết quả sẽ đƣợc gửi tới địa chỉ email của ngƣời quét và những chỉ dẫn để khắc phục các lỗ hổng này.
b) Cấu tạo
Theo hƣớng tiếp cận Saas, hệ thống sẽ giao tiếp với ngƣời dùng là các webmaster thông qua một website public ra ngoài. Đây là “phần nổi” của hệ thống. Toàn bộ quá trình dò quét lỗ hổng an ninh website sẽ do một application phía dƣới thực hiện.
Website quản lý các thông tin về ngƣời dùng, chịu trách nhiệm xác thực là webmaster trong quá trình đăng ký.
Sau khi quá trình đăng ký và xác thực hoàn tất, yêu cầu từ ngƣời dùng đƣợc chuyển vào cho trƣơng trình quét lỗ hổng an ninh ở bên dƣới. Chƣơng trình này sẽ thực hiện quá trình quét lỗ hổng an ninh website, chuyển kết quả cho website hiển thị cho ngƣời dùng.
- Vulns Scanner website ( VSW): Website giới thiệu dịch vụ, quản lý thông tin, giao tiếp với ngƣời dùng
- Vulns Scanner Application (VSA): Là chƣơng trình thực hiện quá trình quét các lỗ hổng an ninh của website.[9]
Hai thành phần này giao tiếp với nhau thông qua lời gọi chƣơng trình và cơ sở dữ liệu. c) Kỹ thuật sử dụng
Webscan sử dụng kỹ thuật phân tích động, và tiếp cận dựa trên phỏng đoán để thực hiện dò quét và phát hiện lỗ hổng.
Module Crawler trong VSA
Module Crawler chịu trách nhiệm thu thập các thông tin từ website từ đó dựng lên cấu trúc website thông quá một số thành phần
- Khối downloader: Download truy cập đến website download các web page bắt
đầu từ URL đầu tiên. Các webpage đƣợc khối download đƣa về sẽ đƣợc đƣa đến khối Parse HTML để phân tích. Hiện nay, có một số project mã nguồn mở viết bằng python cho phép parse html nhƣ BeautifulSoup (http://www.crummy.com/software/ BeautifulSoup/) cho kết quả khá tốt. Tuy nhiên vì đƣợc thiết kế cho phép dựng toàn bộ các node cả web pase dƣới dạng cây cho nên thời gian xử lý khá lâu.
- Queue: Chứa các URL phân tích đƣợc.
- Scheduler: Quản lý thời gian tạm dừng giữa các lần request. Sau khoảng thời gian ấy, các url tiếp theo trong Queue đƣợc gửi đến cho khối download.
- Các URL thu thập đƣợc cùng với HTTP response trả về: Đƣợc sử dụng để xây dựng nên cấu trúc của website.
- Mục đích cuối cùng của web crawler là dựng lên đƣợc cấu trúc của website. Cấu trúc này là cơ sở để tiến hành fuzzing tìm các lỗ hổng website. Muốn vậy, ngoài các thông tin về url, danh sách các biến, mỗi nốt trên cây cần lƣu trữ thêm các thông tin nhƣ: Status code, content-length, source html….
- Cuối cùng, kết quả cấu trúc website đƣợc lƣu trữ một cách có thứ bậc trong một