Xây dựng hệ thống kiểm thử bảo mật website dựa trên kỹ thuật fuzzing

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
──────── * ────────
ĐỒ ÁN
TỐT NGHIỆP ĐẠI HỌC
NGÀNH CÔNG NGHỆ THÔNG TIN
HỆ THỐNG KIỂM THỬ BẢO MẬT
WEBSITE DỰA TRÊN KỸ THUẬT
FUZZING
Sinh viên thực hiện:
Giáo viên hướng dẫn: TS. Cao Tuấn Dũng
HÀ NỘI 2-2014
LỜI CẢM ƠN
Lời đầu tiên, em xin gửi lời cảm ơn chân thành tới các thầy cô trong trường
Đại học Bách Khoa Hà Nội cùng các thầy cô trong Viện Công nghệ Thông tin và
Truyền thông đã truyền dạy cho em những kiến thức bổ ích trong suốt những năm
qua.
Em xin gửi lời cảm ơn tới thầy giáo, TS Cao Tuấn Dũng - Giảng viên, Trưởng Bộ
môn Công nghệ phần mềm – người đã trực tiếp hướng dẫn và định hướng cho em
thực hiện đề tài của mình.
Em xin chân thành cảm ơn tập thể anh chị em trong công ty BKAV, gia đình thứ hai
của em, đã tạo điều kiện thuận lợi và môi trường bổ ích cho em thực tập để phát huy
đam mê của mình, cũng như đã chia sẻ cho em nhiều kinh nghiệm, kiến thức quý
báu trong quá trình làm việc.
Em cũng xin gửi lời cảm ơn tới tập thể lớp CNTT1-K54, các bạn đã cho em một
môi trường học tập lành mạnh, và những món quà tinh thần vô giá.
Cuối cùng em xin gửi lời cảm ơn chân thành tới gia đình, bạn bè đã quan tâm, động
viên, đóng góp ý kiến và giúp đỡ em trong suốt quá trình học tập, và thực hiện đồ
án tốt nghiệp này.
Hà Nội, tháng 01 năm 2014
Sinh viên thực hiện: 2

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Thông tin về sinh viên:
Họ và tên sinh viên:
Đồ án tốt nghiệp được thực hiện tại: Bộ môn Công Nghệ Phần Mềm, Viện Công Nghệ
Thông Tin và Truyền Thông, Đại học Bách Khoa Hà Nội.
Thời gian làm ĐATN: Từ 9/2013 đến 12/2013
2. Mục đích nội dung của ĐATN:
- Tìm hiểu và phân loại các loại lỗ hổng trên hệ thống các website, cổng thông tin
điện từ, … có thể bị lợi dụng để tấn công hệ thống.
- Tìm hiểu về kỹ thuật fuzzing trong kiểm thử website.
- Tìm hiểu và thu thập các bộ fuzzing data phục vụ cho các.
- Xây dựng hệ thống kiểm thử tự động dựa trên kỹ thuật fuzzing.
3. Các nhiệm vụ cụ thể của ĐATN:
- Định nghĩa các loại tấn công một hệ thống website, cổng thông tin điện từ. Cách
thức phát hiện tự động các loại lỗ hổng của hệ thống.
- Tìm hiểu và thu thập các bộ fuzz phục vụ cho từng loại tấn công cụ thể.
- Thiết kế dữ liệu fuzzing data dựa trên các tri thức thu được từ việc thu thập thông
tin của hệ thống.
- Phân tích thiết kế hệ thống.
- Xây dựng hệ thống kiểm thử tự động.
4. Lời cam đoan của sinh viên:
Tôi cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của TS.
Cao Tuấn Dũng.
Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ
công trình nào khác.
Hà Nội, ngày tháng năm
Tác giả ĐATN
5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo
vệ:
Hà Nội, ngày tháng năm

Giáo viên hướng dẫn
TS. Cao Tuấn Dũng
Sinh viên thực hiện: 3
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP
Nhắc lại về tên đề tài: “Xây dựng hệ thống kiểm thử website dựa trên kỹ thuật
fuzzing”. Xin nói qua về kỹ thuật này: “Fuzzing là một kỹ thuật phát hiện lỗi của
phần mềm bằng cách cung cấp dữ liệu đầu vào cho chương trình (các dữ liệu
không hợp lệ, dữ liệu không mong đợi), sau đó theo dõi và ghi lại các lỗi, các kết
quả trả về của ứng dụng trong quá trình xử lý của chương trình” .
Thành quả nghiên cứu sẽ được hiện thực hóa trong một dịch vụ quét lỗ hổng bảo
mật, tương tác với người dùng qua giao diện website. Hệ thống cung cấp chức năng
phân loại các URL và phân loại bộ fuzz theo các thông tin cung cấp và thu thập
được sẽ làm giảm thời gian và tài nguyên xử lý của hệ thống.
Những mục tiêu cần đặt ra khi xây dựng hệ thống:
 Phát hiện tốt các lỗi SQLi, Blind SQLi, XSS, File Inclusion, Xpath Injection,
các lỗi về việc cấu hình mặc định (bao gồm đường dẫn và tài khoản sử
dụng).
 Xây dựng hệ thống fuzzing riêng cho từng loại lỗ hổng.
 Xây dựng module core của hệ thống quét lỗ hổng dưới dạng một dịch vụ
(SAAS).
 Dễ dàng tích hợp các công cụ, các module phát hiện mới vào hệ thống.
 Xây dựng hệ thống giao tiếp với người sử dụng qua giao diện web.
Sau cùng là kết quả chạy thử nghiệm hệ thống và đánh giá việc phát hiện các lỗ
hổng bảo mật của một số website so với các công cụ khác và định hướng phát triển
trong tương lai cho sản phẩm. Cung cấp được một sản phẩm dịch vụ miễn phí cho
người sử dụng.
Môi trường thực hiện đồ án tốt nghiệp:
 Bộ môn Công nghệ phần mềm, Viện Công nghệ Thông tin và Truyền thông,
Trường Đại học Bách Khoa Hà Nội.
 Công ty Cổ phần An ninh mạng BKAV, HH1 Building , Dương Đình Nghệ,

Cầu Giấy, Hà Nội.
Sinh viên thực hiện: 4
MỤC LỤC
Sinh viên thực hiện: 5
PHẦN I: ĐẶT VẤN ĐỀ
Nội dung chính
 Đặt vấn đề
 Giải pháp đảm bảo an toàn cho hệ thống website
 Nhiệm vụ của đề tài
Sinh viên thực hiện: 6
I. ĐẶT VẤN ĐỀ
Trong thời buổi Internet ngày càng phát triển như hiện nay, việc liên hệ thư từ, trao
đổi thông tin, báo chí cũng phát triển không ngừng. Thay cho các phương thức
hoạt động truyền thống, việc ứng dụng hiệu quả của Internet đến nhiều lĩnh vực
trong đời sống của con người đã cho thấy hiệu quả tối ưu của Internet. Sự thay đổi
này đã lấn sâu vào nhiều lĩnh vực: kinh tế, văn hóa, tôn giáo, chính trị, giải trí
Phần lớn các hoạt động này đều thông qua các website, các website như sợi dây kết
nối giữa cộng đồng mạng với nhau. Sử dụng website mọi người có thể liên hệ, trao
đổi, chia sẽ với nhau một cách nhanh chóng và hiệu quả. Đặc biệt ngày nay, hình
thức thanh toán trực tuyến thông qua website đang ngày càng trở nên phổ biến. Vì
thế, dễ hiểu khi các website đã trở thành mục tiêu tấn công ưa thích của tin tặc.
Tại Việt Nam, đại diện mảng an ninh mạng công ty an ninh mạng Bkav, ông Ngô
Tuấn Anh phát biểu: “Trong năm 2013 đã có gần 5.000 hệ thống website của các cơ
quan doanh nghiệp tại Việt Nam bị tin tặc tấn công. Chủ yếu thông qua các lỗ hổng
về mạng và cấu hình hệ thống. So với năm 2012 (có 2.203 website bị tấn công), con
số này đã tăng lên gấp đôi.” – Nguồn .
Từ thực trạng trên cho thấy, an ninh mạng vẫn chưa thực sự được quan tâm tại các
cơ quan, doanh nghiệp. Cũng theo nhận định của các chuyên gia Công ty ANM
Bkav, hầu hết cơ quan doanh nghiệp của Việt Nam chưa bố trí được nhân sự phụ
trách an ninh mạng hoặc năng lực và nhận thức của đội ngũ này chưa tương xứng

với tình hình thực tế. Đó là những nguyên nhân chính. Chưa có một sản phẩm hay
qui trình tiên tiến nào hỗ trợ cho những người quản trị hệ thống phát hiện và ngăn
chặn sớm những lỗ hổng đang tồn tại trên hệ thống.
II. GIẢI PHÁP ĐẢM BẢO AN TOÀN HỆ THỐNG WEBSITE
Từ tình hình trên ta thấy cần thiết có một giải pháp kiểm thử an toàn bảo mật cho
mỗi hệ thống website trước khi đưa vào sử dụng. Nhằm phát hiện và cảnh báo được
các lỗ hổng trên hệ thống website một cách chính xác. Các lỗ hổng do lỗi của người
lập trình hệ thống: SQL Injection, Code Injection, Cross Site Scripting, URL
Redirect… Các lỗi do việc cấu hình hệ thống không an toàn như để đường dẫn vào
trang quản trị hệ thống là mặc định, tài khoản mặc định…
1. Đánh giá các sản phẩm quét lỗ hổng bảo mật hiện có trên thị trường
Các sản phẩm tương tự được chia làm 2 nhóm chính. Nhóm sản phẩm chạy dưới
dạng Desktop Application như: Acunetix, IBM AppScan, W3af… và nhóm sản
phẩm chạy dưới mô hình SAAS - Software As A Service (webscan.bkav.com,
webscan.com…).
So sánh 2 nhóm sản phẩm
Sinh viên thực hiện: 7
Desktop Application Software As A Service
+ Real time
+ Khó kiểm soát người dùng sử dụng
phẩn mềm, có thể phục vụ cho mục
đích xấu.
+ Tốn kém chi phí cho hoạt động nâng
cấp phần mềm.
+ Thời gian thực hiện tốn rất nhiều tài
nguyên và thời gian.
+ Không Real time
+ Có thể kiểm soát tốt hơn người dùng
hệ thống.
+ Việc nâng cấp trở nên đơn giản hơn.

+ Đòi hỏi hạ tầng, về tài nguyên rất lớn.
+ Thời gian phụ thuộc vào tài nguyên
hệ thống Server.
Bảng : So sánh mô hình của các sản phẩm quét lỗ hổng bảo mật website hiện có trên thị trường.
Sau khi so sánh 2 hình thức trên ta thấy để triển khai hệ thống đến số đông người
dùng và tập trung vào đối tượng khách hàng là người không rành về chuyên môn thì
việc triển khai hệ thống dưới mô hình dịch vụ là cần thiết. Tuy nhiên một vấn đề lớn
đặt ra là tài nguyên và thời gian thực hiện quét hệ thống vẫn quá lớn, nếu không có
các bước tối ưu thì hệ thống không thể phục vụ tốt cho số đông người dùng. Khi
nghiên cứu hệ thống của các web scanner ta thấy các sản phẩm hiện tại đều chưa có
quá trình lọc bỏ các URL thừa (không cần thiết khi kiểm tra lỗ hổng), dẫn đến có
quá nhiều các URL được kiểm tra. Và các hệ thống cũng hầu như chưa sử dụng các
tri thức được cung cấp sau quá trình “gathering information” (bao gồm các thông
tin về nền tảng xây dựng hệ thống, ngôn ngữ sử dụng, nền tảng triển khai hệ thống)
nhằm giảm tài nguyên và thời gian quét hệ thống.
2. Đề xuất giải pháp xây dựng Web Fuzzing Scanner
Xây dựng hệ thống Web Fuzzing Scanner theo hướng dịch vụ SAAS, có phần core
fuzzing được tối ưu. Hạn chế được các điểm yếu tồn tại trong các sản phẩm hiện tại
như:
- Sử dụng thêm các tri thức thu được trong quá trình “gathering information”
trong việc thiết kế các dữ liệu fuzz cho hệ thống nhằm giảm các trường hợp
cần kiểm tra.
- Loại bỏ được các URL không cần thiết. Hạn chế tối thiểu các request cần gửi
tới hệ thống.
III. NHIỆM VỤ CỦA ĐỀ TÀI
Xuất phát từ các nhu cầu thực tế kể trên và công việc tại Công ty An ninh mạng
Bkav, tôi chọn đề tài “Xây dựng hệ thống kiểm thử bảo mật website dựa trên kỹ
thuật fuzzing” cho đồ án tốt nghiệp của mình. Đối tượng chính mà hệ thống hướng
đến là các quản trị viên, những người trực tiếp quản lý và theo dõi tình hình hoạt
động các website của mình. Hệ thống sẽ trợ giúp họ phát hiện nhanh các lỗ hổng

đang tồn tại trên hệ thống để có những phương án khắc phục kịp thời.
Sinh viên thực hiện: 8
Đồ án bao gồm các thành phần chính như sau:
• PHẦN I: Đặt vấn đề và định hướng giải pháp.
 Đặt vấn đề
 Giải pháp an toàn cho hệ thống website.
 Nhiệm vụ của đề tài
• PHẦN II: CƠ SỞ LÝ THUYẾT
 Tổng quan về Website
 Tổng quan về lỗ hổng Website
 Các kỹ thuật kiểm thử phần mềm.
 Kỹ thuật Fuzzing.
• PHẦN III: Xây dựng hệ thống
 Các giải pháp xây dựng hệ thống
 Phân tích và thiết kế hệ thống
• PHẦN IV: Đánh giá, định hướng và kế hoạch phát triển cho sản phẩm.
Sinh viên thực hiện: 9
PHẦN II: CƠ SỞ LÝ THUYẾT
Nội dung chính
 Tổng quan về hệ thống website
 Tổng quan về lỗ hổng website
 Các kỹ thuật kiểm thử ứng dụng
 Kỹ thuật Fuzzing
Sinh viên thực hiện: 10
I. TỔNG QUAN VỀ HỆ THỐNG WEBSITE
Với sự phát triển mạnh mẽ của Internet như hiện nay, các ứng dụng web ngày càng
trở nên phổ biến và hiện hữu ở khắp mọi nơi trên thế giới. Ứng dụng web là một hệ
thống hoạt động theo mô hình Client - Server và sử dụng giao thức HTTP (hoặc
HTTPS) để tương tác giữa hai thành phần chủ yếu là trình duyệt - Browser (Client)
và Web Server (Server).

Mô hình hoạt động của một hệ thống web truyền thống
Hình : Mô hình hoạt động của một ứng dụng Web
Trình duyệt web (client) sẽ gửi các HTTP Request tới web server. Web server sẽ
phân tích các yêu cầu và gọi đến các chương trình và trả lại kết quả cho trình duyệt.
Các chương trình có thể được xây dựng trên nhiều ngôn ngữ như PHP, ASP, JSP…
Tùy vào các tác vụ được cài đặt mà nó xử lý, tính toán, tương tác với cơ sở dữ liệu
(CSDL)… Từ đó trả kết quả về trình duyệt gói tin HTTP Response. Trình duyệt sẽ
phân tích gói tin này và hiển thị thông tin cho người dùng.
Nếu một website hoạt động theo mô hình trên sẽ có rất nhiều điểu yếu mà tin tặc có
thể lợi dụng để tấn công.
Sinh viên thực hiện: 11
Hình : Các nguy cơ của một hệ thống website
Tin tặc có thể tấn công vào các thành phần của hệ thống như:
- Tấn công vào người dùng của hệ thống, cướp tài khoản người dùng.
- Tấn công vào quá trình truyền nhận dữ liệu giữa client và server. Tin tặc có
thể nghe lén và lấy thông tin của hệ thống.
- Tấn công vào webserver, các dịch vụ trên web server, chiếm quyền điều
khiển toàn bộ hệ thống.
- Tấn công vào CSDL của hệ thống, thêm sửa xóa CSDL.
II. TỔNG QUAN VỀ LỖ HỔNG HỆ THỐNG WEBSITE
Trong những năm gần đây, website được phát triển với tốc độ rất nhanh tại Việt
Nam nhưng thực tế những quản trị viên vẫn chưa quan tâm đúng mức về vấn đề bảo
mật mà chỉ chú trọng vào hình thức và nội dung của website, do vậy có rất nhiều
trường hợp website bị tấn công hay mất dữ liệu vì những lỗi bảo mật rất phổ biến.
Những lỗi bảo mật này có thể xuất phát từ những sai sót ngay từ trong các khâu
thiết kế, lập trình hoặc triển khai hệ thống website.
Lỗ hổng website là những điểm yếu của hệ thống website mà tin tặc có thể lợi dụng
để khai thác nhằm thu thập thông tin về hệ thống, tấn công lấy cắp thông tin, tấn
công vào người dùng hệ thống hay tấn công chiếm quyền điều khiển hệ thống.
Lỗ hổng website có thể có nhiều nguyên nhân, tuy nhiên chủ yếu là do 3 nguyên

nhân sau:
- Lỗi do sự yếu kém và chưa có khái niệm về lập trình an toàn của người lập
trình, phát triển ứng dụng. Không kiểm soát chặt chẽ các đầu vào từ người
Sinh viên thực hiện: 12
dùng, tin tặc có thể lợi dụng để khai thác và tấn công hệ thống, người dùng
hệ thống.
- Lỗi do việc cấu hình hệ thống yếu, cấu hình hệ thống mặc định, tài khoản hệ
thống mặc định, do sử dụng các dịch vụ, nền tảng mà không cập nhật phiển
bản mới, bản vá…
- Lỗi nằm trong các giao thức, các nền tảng hay chuẩn xây dựng hệ thống đã
được công khai.
Lỗ hổng website có thể phân thành một số loại chính như:
 Injection: Các lỗ hổng cho phép tin tặc chèn những script để thực thi như
SQL Injection, XPath Injection, System Command Injection, LDAP
Injection
 Client Side: Các lỗ hổng tấn công vào client. Ví dụ như Cross Site Scripting
(XSS), Cross-site Request Forgery (CSRF)
 Parameter Manipulation: Các lỗ hổng như Cookie Manipulation, HTTP
Form Field Manipulation…
 Misconfiguration: Các lỗ hổng thuộc về cấu hình hệ thống chưa an toàn.
 Information Disclosure: Các lỗ hổng cung cấp các thông tin của hệ thống,
tin tặc có thể lợi dụng cho những cuộc tấn công tiếp theo. Ví dụ như: Path
Traversal, Predict Resource Location, Directory Listing
Top 10 lỗ hổng OWASP - 2013 OWASP TOP 10 – 2013
A1 – Injection
A2 – Broken Authentication and
Session Management
A3 – Cross Site Scripting (XSS)
A4 – Insecure Direct Object
References

A5 – Security Misconfiguration
A6 – Sensitive Data Exposure
A7 – Missing Funtion Level
Access Control
A8 – Cross Site Request Forgery
A9 – Using Known Vulnerable
Components
A10 – Unvalidated Redirects and
Forwards
Sinh viên thực hiện: 13
Bảng : Top 10 lỗ hổng phổ biến nhất năm 2013 (Nguồn OSWAP)
Mỗi lỗ hổng bảo mật sẽ có cách khai thác và phát hiện khác nhau. Chúng ta sẽ cùng
đi vào một số lỗ hổng chính để thấy và hiểu rõ hơn về từng lỗ hổng và đưa ra những
biện pháp để phát hiện, khắc phục và phòng tránh các lỗ hổng đang tồn tại trên hệ
thống.
1. Lỗ hổng Injection (SQL Injection, Xpath injection… )
1.1. Khái quát
Lỗ hổng injection là loại lỗ hổng liên quan tới việc thao tác với CSDL, bao gồm các
hệ quản trị CSDL quan hệ (Mysql, MSSQL, Oracle…), các dữ liệu XML… Nguyên
nhân chủ yếu là do người lập trình không kiểm duyệt hoặc có kiểm duyệt chưa tốt
dữ liệu nhập vào, tin tặc dễ dàng có thể vượt qua để chèn các câu lệnh truy vấn như
SQL, XQuery…, khi chèn thành công tin tặc có thể đọc, thêm sửa, xóa thông tin
trong CSDL của hệ thống.
Về mặt lý thuyết, lỗ hổng injection tưởng chừng rất đơn giản nhưng đây là một
trong những loại tấn công phổ biến và nguy hiểm nhất hiện nay. Dựa vào các lỗi
Injection, tin tặc có thể thao tác trực tiếp CSDL của hệ thống, đọc tệp tin, ghi tệp tin
nhằm tạo backdoor và chiếm quyền điều khiển hệ thống.
1.2. Minh họa
Nếu lập trình viên không kiểm soát tốt các giá trị biến nhập vào từ người dùng. Tin
tặc có thể lợi dụng để chèn các đoạn mã độc nhằm thay đổi cấu trúc câu truy vấn và

lộ các thông tin về hệ thống. Chẳng hạn, một kịch bản quen thuộc để lấy thông tin
của hệ thống như sau:
URL

Với một giá trị ID chính xác được nhập vào là 1 hệ thống sẽ trả về người dùng có
ID bằng 1.
Quá trình xử lý của hệ thống
PHP Code
$id = $_REQUEST[“id”];
$query = “SELECT * FROM users where userID=”.$id;
Hệ thống không có quá trình kiểm duyệt dữ liệu ID từ người dùng.
Trong trường hợp này ta thấy, nếu người dùng gửi đường dẫn có giá trị id = x thì
kết quả trả về của hệ thống sẽ hoàn toàn bình thường.
Nhìn kỹ đoạn mã PHP xử lý ta thấy biến $id được đưa ngay vào câu truy vấn mà
không được kiểm duyệt trước, tin tặc hoàn toàn có thể chèn một số mã độc để lấy
Sinh viên thực hiện: 14
thông tin về hệ thống. Chẳng hạn, thay vì gửi giá trị id = 1 tin tặc sẽ gửi giá trị id =
-1 or 1=1.
URL
-1 or 1=1 -
Khi đó câu truy vấn của chúng ta sẽ trở thành
SQL Query
SELECT * FROM users WHERE userID=-1 or 1=1 -
Rõ ràng với điều kiện WHERE userID = -1 thì CSDL sẽ không trả về bản ghi nào
trả về. Tuy nhiên, do đoạn mã or 1=1 - đã được tin tặc chèn vào. Nên điều kiện
sau WHERE sẽ trở nên luôn đúng và kết quả là CSDL sẽ trả về tất cả các bản ghi có
trong bảng users.
Bằng những cách thức nâng cao khác, tin tặc hoàn toàn có thể chèn các đoạn mã
nguy hiểm hơn để lấy toàn bộ thông tin về hệ thống, đọc ghi tệp tin bằng các hàm
trong CSDL như: outfile, load_file (MySQL), execute (MSSQL) lên hệ thống từ đó

hình thành những backdoor và sau cùng là chiếm quyền điều khiển toàn bộ hệ
thống.
Với kiểu tấn công Xpath Injection ta cũng có thể khai thác hoàn toàn tương tự.
Mức độ nguy hiểm của SQL/Xpath Injection là rất cao bởi vì nó tác động trực tiếp
đến CSDL: ăn cắp thông tin người dùng, thay đổi làm sai lệch các thông tin quan
trọng, thêm sửa xóa CSDL… Rõ ràng, với một hệ thống website đặc biệt là các hệ
thống có liên quan đến tài chính như ngân hàng, thì việc thông tin bị đánh cắp hay
thay đổi sẽ gây những thiệt hại vô cùng lớn.
1.3. Cơ chế phát hiện
Tương tự như quá trình khai thác một lỗi SQL chúng ta cũng có thể phát hiện tự
động các hệ thống có ẩn chứa những mối nguy hiểm như vậy. Có thể phát hiện các
lỗi SQL/Xpath Injection bằng 4 phương pháp chính:
- Dựa trên các thông báo lỗi từ hệ thống, từ CSDL của hệ thống.
- Dựa trên kỹ thuật boolean based (kiểm tra kết quả khác nhau của các câu
truy vấn khác nhau, ví dụ như khi chèn or 1=1 và or 1=2).
- Dựa trên kỹ thuật nối câu truy vấn (UNION query).
- Dựa trên kỹ thuật timebased: sử dụng các hàm thao tác với thời gian trong hệ
quản trị CSDL và kiểm tra timeout của kết quả trả về.
Ta cần thiết kế bộ dữ liệu fuzzing dựa trên các kỹ thuật phát hiện này. Ví dụ một bộ
dữ liệu fuzz cho lỗi SQL Injection dựa trên các thông báo lỗi của hệ thống:
Bộ dữ liệu fuzz khi phát hiện dựa trên các thông báo lỗi từ hệ thống
Sinh viên thực hiện: 15
Đầu vào
Các thông báo lỗi từ hệ thống
(Regular Expression)
‘
“
\xBF'\"("
mysql_fetch_array|mysql_num_rows|mysql_fetch_array|Error at line
near|You have an error in your SQL syntax|mySQL error with query|

on MySQL result index|mysql_query|supplied argument is not a
valid MySQL result resource in
SQL command not properly ended|SQLException|Supplied
argument is not a valid PostgreSQL result|Syntax error in query
expression|The error occurred in|Unterminated string constant|
invalid query|is not allowed to access
\[Microsoft\]\[ODBC Microsoft Access Driver\]
ASP\.NET is configured to show verbose error messages|Microsoft
OLE DB Provider for ODBC Drivers[\S\s]*error
java\.sql\.SQLException\: Syntax error or access violation
XPathException
Dynamic SQL Error
DB2 SQL error\:
Bảng : Cơ chế phát hiện lỗi SQL Injection
1.4. Các thức phòng tránh
Lỗ hổng SQL Injection/Xpath Injection xảy ra do các biến được nhập vào từ người
dùng không được kiểm soát chặt chẽ trước khi xây dựng câu truy vấn tới CSDL. Đó
chính là nguyên nhân chung nhất của các lỗ hổng dạng Injection.
Lỗ hổng SQL Injection/Xpath Injection xảy ra khi có kết hợp cả 2 điều kiện:
- Có sự truy vấn tới CSDL
- Câu truy vấn chưa được kiểm soát sự an toàn
Có thể khẳng định chắc chắn rằng, một biến được nhập vào từ người dùng, qua
nhiều bước xử lý trung gian xây dựng câu truy vấn tới CSDL mà không có bất cứ
bước kiểm tra sự an toàn nào thì chắc chắn sẽ mắc các lỗ hổng Injection. Đây cũng
chính là điểm mấu chốt để nhận diện và phòng chống các lỗ hổng Injection. Phương
pháp hữu hiệu nhất để chống tấn công SQL/Xpath Injection là kiểm soát thật chặt
chẽ các giá trị nhập được nhập vào từ người dùng.
2. Lỗ hổng Cross Site Scripting
2.1. Khái quát
Cross-site Scripting (XSS) là lỗ hổng cho phép tin tặc có thể chèn những đoạn mã

client-script (thường là Javascript, JScript, DHTML và cũng có thể là cả các thẻ
HTML) vào trang web, khi người dùng vào những trên web này, mã độc sẽ được
thực thi trên máy của người dùng và thực hiện các mục đích mà kẻ tin tặc mong
muốn.
Khác với SQL Injection tấn công vào CSDL của website, XSS tấn công trực tiếp
vào người dùng. Lợi dụng lỗi XSS này, tin tặc có thể:
Sinh viên thực hiện: 16
- Lừa đảo người quản trị của website, lấy cắp cookie, chiếm session… từ đó
có thể đăng nhập chiếm quyền điều khiển website.
- Thực thi các mã độc javascript tùy ý nhằm tấn công vào người dùng.
- Phát tán các thông tin xấu lên hệ thống.
Hiện nay, kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗ hổng
phổ biến nhất của các ứng dụng web. Mối đe doạ của chúng đối với người sử dụng
ngày càng lớn.
2.2. Minh họa
Ta sẽ minh họa lỗi XSS bằng một ví dụ đơn giản
URL
:8001/Vulns/XSS/example.php?msg=I’am%20chientq
Hệ thống thực hiệc việc in ra giá trị của biến GET msg. Đoạn mã PHP:
<?php
if (isset( $_GET['msg'] ) ){
echo '<h1>'.$_GET['msg'].'</h1>';
}
?>
Tuy nhiên một tin tặc thay vì việc nhập vào dữ liệu hợp lệ có thể nhập vào những
thẻ HTML và mã Javascript ví dụ như:
:8001/Vulns/XSS/example.php?
msg=<script>alert(document.cookie)</scsript>
Khi đó đó hay vì hiện dữ liệu như bình thường hệ thống xuất hiện một popup hiển
thị cookie của người dùng:

Hình : Minh họa lỗi Cross Site Scsripting.
Nếu như thay vì chỉ hiển thị cookie của hệ thống, tin tặc có thể sử dụng một hàm
gửi mail hay một hàm trong javascript để gửi thông tin về cookie của người dùng về
cho tin tặc thì tin tặc hoàn toàn có thể đăng nhập vào tài khoản của người dùng bằng
cách set giá trị cookie nhận được vào trình duyệt của tin tặc. Tin tặc sẽ có đủ các
Sinh viên thực hiện: 17
quyền như người dùng khi đăng nhập vào hệ thống. Cũng với lỗi này tin tặc cũng có
thể chèn các đoạn virus javascript, cài đặt add-on, download mã độc, … vào trình
duyệt và máy của của người dùng.
2.3. Cơ chế phát hiện
Một biến có lỗ hổng XSS nếu như giá trị của biến đó được hiện ra trình duyệt hoặc
trong mã nguồn html mà không có bước xử lý thích hợp nào trước đó.
Đế phát hiện lỗi này chúng ta sẽ thực hiện gửi một chữ ký kèm những đoạn mã đặc
biệt tới hệ thống như:
<scipt>alert(1223)</script>
“><scipt>alert(1223)</script>
“ onmouseover=alert(123445) foo=”
….
Thực hiện việc phân tích mã html, nếu tìm thấy sự xuất hiện của các đoạn mã đó
trong mã html thì chứng tỏ hệ thống đã mắc lỗi XSS.
2.4. Các thức phòng tránh
XSS là một lỗ hổng rất phổ biến và rất nguy hiểm đối với người dùng hệ thống. Tuy
nhiên việc phòng tránh lỗi XSS lại hết sức đơn giản. Đối với các dữ liệu được nhận
từ người dùng, khi thực hiện việc hiển thị ta cần encode tất cả các giá trị được in ra.
Khi đó các đoạn mã độc sẽ không thể thực thi được. Trong các ngôn ngữ lập trình
đều có các hàm hỗ trợ việc mã hóa dữ liệu này. Ví dụ như:
- Hàm htmlentities() – trong ngôn ngữ PHP
- Hàm htmlEncode() – trong ngôn ngữ C#
- Trong jsp cung cấp cú pháp: ${specialCharString} để thực hiện encode html
tag.

3. Lỗ hổng Directory Listing
3.1. Khái quát
Trong các webserver, khi chúng ta thực hiện truy cập vào một thư mục web, nếu tồn
tại các tệp tin mặc định của hệ thống thì hệ thống sẽ gọi đến ngay các tệp tin mặc
định như: index.html, index.jsp, index.php, default.asp… Tuy nhiên nếu trong thư
mục không tồn tại các tệp tin mặc định hoặc cơ chế cấu hình riêng của website thì
khi truy cập tới các thư mục web này hệ thống sẽ hiển thị danh sách tất cả các tệp
tin và thư mục con hiện có trong thư mục. Với lỗ hổng này, tin tặc có thể biết được
các danh sách các tệp tin có trên hệ thống và thực hiện việc đọc, truy cập trái phép
vào các tệp tin trong hệ thống.
3.2. Minh họa
Dưới đây là một ví dụ về lỗi Directory Listing.
Sinh viên thực hiện: 18
Hình : Minh họa lỗi Directory Listing
3.3. Phát hiện
Để phát hiện lỗi trên hệ thống ta thực hiện việc truy cập vào các thư mục của hệ
thống, cụ thể truy cập vào các URL kết thúc bằng dấu “/”. Và kiểm tra sự xuất hiện
của một số lỗi trả về từ hệ thống. Trong mã html trả có chứa từ “index of” hoặc
“parent directory”… thì đồng nghĩa với việc hệ thống tồn tại lỗi Directory Listing.
3.4. Phòng chống
Để phòng chống lỗi Directory Listing cũng hết sức đơn giản, chúng ta có thể thực
hiện bằng một trong các phương pháp sau
- Thêm tệp tin mặc định vào các thư mục (index, default…)
- Thêm một số tệp tin cấu hình như .htaccess trong Apache để hạn chế.
- Cấu hình từ các WebServer (IIS, Apache…)
- Cấu hình phân quyền cấp người dùng khi truy cập vào các thư mục đó
4. Lỗ hổng File Inclusion
4.1. Khái quát
Lỗ hổng File Inclusion là loại lỗ hổng xảy ra khi hệ thống thực hiện việc thao tác
với tệp tin. Khi hệ thống không có quá trình kiểm duyệt đoạn mã chèn vào chặt chẽ,

tin tặc có thể lấy các giá trị của các biến Post, Get, Headers từ người dùng gửi lên
để thao tác với CSDL. Bằng việc khai thác lỗ hổng này tin tặc có thể thực hiện việc
tải các backdoor lên hệ thống và đọc các tệp tin của hệ thống…
File Inclusion được chia làm 2 loại chính là:
- Local File Inclusion: Thực hiện khi các tệp tin mà hệ thống thao tác là các
tệp tin của local và không cho phép việc chèn vào hệ thống các đoạn mã
Sinh viên thực hiện: 19
- Remote File Inclusion: Cho phép việc chèn các đoạn mã từ một hệ thống từ
xa và thực hiện trên web server.
4.2. Minh hoạ
Với một chương trình có dạng:
URL :8001/vulns/LFI/?color=blue.php
Code xử lý
<?php
$color = 'green.php';
if (isset( $_GET['color'] ) ){
$color = $_GET['color'];
}
include( $color );
?>
Mô tả Đường dẫn này sẽ lấy giá trị của biến color trong GET link để thực
hiện việc hàm include file đó vào ứng dụng. Trong trường hợp này
là blue.php, red.php và green.php để hiển thị các dòng chữ có màu
lam, đỏ và màu lục tương ứng.
Tuy nhiên thay vì để mặc định các giá trị là “green.php”, “red.php” hay “blue.php”
tin tặc hoàn toàn có thể nhập vào giá trị bất thường nhằm đọc các thông tin từ hệ
thống. Ví dụ việc đọc tệp tin cấu hình của apache server
:8001/vulns/LFI/?color= / / /apache/conf/httpd.conf khi đó hệ
thống sẽ đọc tệp tin httpd.conf của hệ thống. Do cấu trúc “ /” trong các hệ điều
hành là để quay lại thư mục cha của ứng dụng, kẻ tấn công có thể lái việc đọc vào

các tệp tin tương ứng.
Hình : Minh họa lỗi Local File Inclusion
Khi khai thác lỗi này thành công, tin tặc có thể thực hiện đọc các tệp tin cấu hình hệ
thống, hoặc có thể đọc các tệp tin quan trọng khác như: /etc/passwd, /etc/shadow…
Tuy nhiên tin tặc cũng có thể chèn vào một đường dẫn đến những đoạn mã nguy
hiểm khác và thực hiện include vào hệ thống (nếu như hệ thống cho phép việc
include remote file). Như vậy tin tặc không chỉ là đọc nữa mà hoàn toàn có thể thực
Sinh viên thực hiện: 20
thi các đoạn mã đó trên hệ thống và tạo ra các backdoor hay tải các webshell lên
server và chiếm quyền điều khiển hoàn toàn web server.
Hình : Minh họa lỗi Remote File Inclusion (Tin tặc có thể tải giao diện của google vào hệ thống)
4.3. Phát hiện
Để phát hiện lỗi này chúng ta sẽ thực hiện đưa vào những giá trị của các tệp tin có
thể và kiểm tra kết quả trả về để đánh giá việc tồn tại của lỗ hổng. Ví dụ:
- / / /etc/passwd
- / / /etc/shadow
- / /apache/logs/access.log
Việc chèn số các “ /” là do chương trình phát hiện sẽ tự động thêm vào.
4.4. Phòng tránh
File Inclusion là một lỗi cực kỳ nghiêm trọng. Để phòng tránh cho chương trình gặp
phải các lỗi như vậy. Người lập trình cần quản lý, kiểm duyệt chặt chẽ các giá trị
của các biến mà người dùng nhập vào hệ thống trước khi thực hiện việc đưa các
biến đó vào xử lý. Đặc biệt là khi thao tác với các tệp tin của hệ thống. Khi thực
hiện việc include file, không nên sử dụng các dữ liệu được cung cấp từ người dùng,
các giá trị này cần được đặt tĩnh trong code của chương trình.
5. Các lỗ hổng do cấu hình mặc định
5.1. Khái quát
Là những lỗi về cấu hình đường dẫn mặc định của hệ thống, không cấu hình hạn
chế truy nhập, hay những đường dẫn mà để mật khẩu truy cập là mặc định. Như
đường dẫn đến trang quản trị, đường dẫn đến tệp tin cấu hình hệ thống…

5.2. Minh họa
Ví dụ đường dẫn đến website: đây là trang quản trị của
hệ thống các dự án đã triển khai trên hệ thống.
Sinh viên thực hiện: 21
Khi ta truy nhập vào đường dẫn, hệ thống đã có bước yêu cầu xác thực tài khoản và
mật khẩu. Tuy nhiên “username/password” lại được đặt mặc định là: admin/admin.
Hình : Minh họa cho lỗi để cấu hình mặc định
Với lỗi hổng trên ta có thể thực hiện việc đưa backdoor lên hệ thống, undeploy hoặc
loại bỏ các ứng dụng đang thực hiện trên hệ thống.
5.3. Phát hiện
Để phát hiện các lỗi cấu hình chúng ta cần thực hiện truy cập đến các trang cấu hình
mặc định và kiểm tra mã trạng thái trả về cùng với việc kiểm tra mã HTML của hệ
thống.
5.4. Khắc phục
Để khắc phục lỗ hổng này rất đơn giản chúng ta cần thực hiện các bước sau:
Sinh viên thực hiện: 22
- Đặt ẩn hoặc cấu hình cấm truy cập tới các đường dẫn cấu hình không cần
thiết.
- Đặt tài khoản và mật khẩu mạnh, không để tin tặc có thể đoán hoặc tấn công
vét cạn (brute force) mật khẩu dễ dàng.
- Hạn chế truy cập dựa trên địa chỉ và các thông tin của người sử dụng.
III. CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
Hình : Các kỹ thuật kiểm thử
1. Kiểm thử hộp đen
Hình : Kỹ thuật kiểm thử hộp đen.
Kiểm thử hộp đen coi phần mềm như là một "hộp đen", kiểm thử chức năng mà
không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm. Người kiểm
tra chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế
nào. Các test case (trường hợp kiểm tra) được tạo bằng việc sử dụng các mô tả bên
ngoài của phần mềm, bao gồm: các đặc tả, các chức năng, các yêu cầu và thiết kế

của phần mềm.
Người thiết kế test case chọn các giá trị đầu vào và kiểm tra dữ liệu đầu ra có hợp lệ
hay không. Phương pháp kiểm thử hộp đen bao gồm: phân vùng tương đương, phân
tích các giá trị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử
bảng quyết định, kiểm thử chéo, kiểm thử dựa trên mô hình, sử dụng test case, thăm
Sinh viên thực hiện: 23
dò kiểm thử và kiểm thử dựa trên đặc điểm kỹ thuật. Kiểm thử hộp đen có thể kiểm
tra được cả những thành phần chưa được thực thi trong đặc tả, nhưng không chắc
chắn rằng mọi trường hợp đã được kiểm tra hoàn toàn.
2. Kiểm thử hộp trắng
Hình : Kỹ thuật kiểm thử hộp trắng
Người kiểm thử hộp trắng biết được tất cả các cấu trúc dữ liệu bên trong chương
trình, các thuật toán và cả mã lệnh cài đặt. Người thiết kế các test case sẽ đưa ra các
trường hợp kiểm thử sao cho tất cả mã lệnh được thực hiện ít nhất một lần.
Cùng với kiểm thử hộp đen, kiểm thử hộp trắng cho phép nhóm phát triển kiểm tra
những phần của hệ thống ít khi thực hiện, đảm bảo những hàm quan trọng được
thực thi ít nhất một lần. Kiểm thử hộp trắng cũng thống kê những hàm nào được
thực hiện, bao nhiêu dòng lệnh được thực hiện chính xác, từ đó cho biết mức độ bao
trùm của việc kiểm tra. Tuy nhiên, có một trở ngại đối với hình thức kiểm tra này là
đòi hỏi phải có mã nguồn của chương trình, điều này không phải lúc nào cũng có
thể sẵn sàng.
3. Kiểm thử hộp xám
Hình : Kỹ thuật kiểm thử hộp xám
Trong những năm gần đây một phương pháp hay được sử dụng là kiểm thử hộp
xám. Đó là sự kết hợp của kiểm thử hộp đen và hộp trắng. Thông tin có được là cấu
trúc dữ liệu nội bộ, giải thuật của chương trình, nhưng công đoạn thực hiệ kiểm thử
Sinh viên thực hiện: 24
ở mức người dùng. Mục đích của kiểm thử hộp xám là phát hiện lỗi thiết kế và cài
đặt. Kiểm thử hộp xám đặc biệt quan trọng khi ghép nối các module của các lập
trình viên khác nhau lại. Ngoài ra còn có một vài loại kiểm thử đặc biệt khác như

kiểm thử hiệu năng, kiểm thử tính dễ sử dụng với người dùng, kiểm tra tính an toàn
dữ liệu và ngăn cản tin tặc tấn công.
IV. KỸ THUẬT FUZZING
1. Khái niệm
Trong lĩnh vực an ninh ứng dụng, Fuzzing là một kỹ thuật phát hiện lỗi của phần
mềm bằng cách cung cấp dữ liệu đầu vào cho chương trình (các dữ liệu không hợp
lệ, dữ liệu không mong đợi), sau đó theo dõi và ghi lại các lỗi, các kết quả trả về
của ứng dụng trong quá trình xử lý của chương trình. Dữ liệu không mong đợi
thường là các giá trị vượt quá biên, các giá trị đặc biệt có ảnh hưởng tới phần xử lý,
hiển thị của chương trình.
Fuzzing là quá trình tự động hoặc bán tự động và lặp lại thao tác sinh dữ liệu sau đó
chuyển cho hệ thống xử lý. Kỹ thuật Fuzzing thường được sử dụng nhiều trong việc
kiểm thử cho các vấn đề về an ninh trong các phần mềm, hệ thống máy tính và các
ứng dụng dịch vụ. Khái niệm Fuzzing thiên về lý thuyết hơn là giải pháp cụ thể cho
từng vấn đề. Các chương trình ứng dụng Fuzzing gọi là Fuzzer. Tùy theo môi
trường và ứng dụng cần kiểm tra mà người ta có các phương án khác nhau để xây
dựng Fuzzer.
2. Lịch sử của Fuzzing
Thuật ngữ “fuzz” được giá sư Barton Millter đưa ra trong bài tập cho sinh viên tại
trường Winconsin Madison vào năm 1988. Bài tập được đặt tên là “Operating
System Utility Program Reliability - The Fuzz Generator” để kiểm tra mức độ chịu
đựng của các ứng dụng Unix, độ tin cậy của mã nguồn. Hiện nay, các kết quả
nghiên cứu của nhóm vẫn được cập nhật tại địa chỉ:
/>Năm 1999, trường đại học Oulu bắt đầu xây dựng các bộ kiểm thử PROTOS. Các
bộ kiểm thử được xây dựng qua việc nghiên cứu và đặc tả giao thức sau đó tạo ra
các gói tin “dị dạng” để kiểm tra xem ứng dụng cài đặt có xử lý đúng đắn nó không.
Việc sinh ra những bộ kiểm thử như vậy khá tốn nhiều công sức, nhưng một khi
hoàn tất sẽ có thể áp dụng cho nhiều ứng dụng khác nhau của nhiều hãng phát triển
khác nhau. Một số lượng lớn lỗi đã được phát hiện trong quá trình fuzzing sau đó.
Năm 2002, Microsoft đã quyết định đầu tư cho nhóm sáng lập PROTOS. Năm

2003, các thành viên của nhóm đã thành lập Codenomicon, một công ty chuyên
thiết kế và phát triển các sản phẩm fuzzing thương mại.
Sinh viên thực hiện: 25