123doc Do An Ung Dung Fuzzing Trong Kiem Thu Khai Thac Lo Hong Bao Mat Website Co Code 1

MỤC LỤC
MỤC LỤC...........................................................................................................
DANH MỤC HÌNH.............................................................................................
DANH MỤC BẢNG...........................................................................................
DANH MỤC TỪ VIẾT TẮT............................................................................vii
MỞ ĐẦU...............................................................................................................
Chương 1. TỔNG QUAN VỀ KIỂM THỬ WEBSITE....................................
1.1. Các khái niệm cơ bản...................................................................................
1.1.1. Website..................................................................................................
1.1.2. Lỗ hổng bảo mật..................................................................................
1.1.3. Lỗ hổng website...................................................................................
1.1.4. Kiểm thử phần mềm.............................................................................
1.1.5. Kiểm thử website.................................................................................
1.1.6. Fuzzing................................................................................................
1.2. Các loại lỗ hổng bảo mật web....................................................................
1.2.1. Phân loại các lỗ hổng bảo mật web....................................................
1.2.2. Một số lỗ hổng bảo mật ứng dụng web chính.....................................
1.3. Kỹ thuật Fuzzing........................................................................................
1.3.1. Lịch sử.................................................................................................
1.3.2. Phân loại Fuzzing................................................................................
1.3.3. Ưu nhược điểm của Fuzzing................................................................
1.4. Lựa chọn Fuzzing cho kiểm tra lỗ hổng website........................................
1.5. Kết luận chương 1......................................................................................
Chương 2. KỸ THUẬT FUZZING TRONG KIỂM TRA LỖ HỔNG
BẢO MẬT WEBSITE.......................................................................................
2.1. Mô hình Fuzzing cho ứng dụng website....................................................
2.1.1. Mô hình Fuzzing..................................................................................
2.1.2. Quy trình Fuzzing trong kiểm thử bảo mật website............................
2.2. Thu thập các điểm đầu vào.........................................................................
2.2.1. Cơ chế trích xuất URL từ mã HTML...................................................
1
2.2.2. Phương pháp thu thập.........................................................................
2.3. Nguyên lý chèn dữ liệu fuzz.......................................................................
2.3.1. Chèn dữ liệu vào phương thức GET....................................................
2.3.2. Chèn dữ liệu vào phương thức POST..................................................
2.4. Phương pháp phát hiện lỗ hổng bảo mật....................................................
2.4.1. Phát hiện lỗ hổng dựa trên đặc trưng.................................................
2.4.2. Phát hiện lỗ hổng dựa trên cấu hình...................................................
2.5. Kết luận chương 2......................................................................................
Chương 3. XÂY DỰNG ỨNG DỤNG KIỂM TRA LỖ HỔNG BẢO MẬT
WEBSITE...........................................................................................................
3.1. Đặc tả chương trình....................................................................................
3.1.1. Mô tả....................................................................................................
3.1.2. Yêu cầu................................................................................................
3.2. Thiết kế hệ thống........................................................................................
3.2.1. Kiến trúc chương trình........................................................................
3.2.2. Thiết kế chức năng hệ thống................................................................
3.3. Xây dựng chương trình...............................................................................
3.3.1. Phương thức xử lý...............................................................................
3.3.2. Xây dựng các thành phần chính..........................................................
3.4. Triển khai, thử nghiệm...............................................................................
3.4.1. Cài đặt ứng dụng.................................................................................
3.4.2. Thử nghiệm, đánh giá..........................................................................
3.5. Kết luận chương 3......................................................................................
KẾT LUẬN........................................................................................................
TÀI LIỆU THAM KHẢO.................................................................................
2
DANH MỤC HÌNH
1.1 Kiến trúc một ứng dụng web...................................................................6
1.2 Mô hình hoạt động của một ứng dụng web.............................................7
1.3 Kiểm thử hộp đen..................................................................................19
1.4 Kiểm thử hộp trắng...............................................................................20
1.5 Kiểm thử hộp xám.................................................................................20
1.6 Hộp thoại lỗ hổng XSS chứa cookie.....................................................28
1.7 Website bị lỗi Directory Listing............................................................29
1.8 Kết quả sau tấn công lỗ hổng LFI.........................................................31
1.9 Minh họa lỗ hổng cấu hình mặc định....................................................33
2.1 Mô hình Fuzzing cho ứng dụng web.....................................................40
2.2 Quy trình Fuzzing.................................................................................41
2.3 Sơ đồ của một crawler...........................................................................47
2.4 Mô hình thu thập URL theo mã HTML................................................49
2.5 Các đường dẫn từ tệp tin robots.txt.......................................................51
2.6 Mô hình phân tích phát hiện lỗ hổng....................................................56
3.1 Kiến trúc phân tầng của ứng dụng........................................................65
3.2 Luồng xử lý chức năng thu thập URL...................................................66
3.3 Luồng xử lý chức năng quét lỗ hổng website.......................................67
3.4 Luồng xử lý chức năng đưa ra lời khuyên............................................68
3.5 Giao tiếp giữa Fuzzer và Server............................................................69
3.6 Xử lý đồng bộ và bất đồng bộ...............................................................71
3.7 Thành phần thu thập điểm đầu vào.......................................................74
3.8 Thành phần tấn công.............................................................................74
3.9 Thành phần phân tích............................................................................75
3.10 Danh sách các thông số tùy chọn..........................................................76
3.11 Giao diện Fuzzing thủ công..................................................................76
3.12 Giao diện Crawler URL........................................................................77
3.13 Giao diện Auto Fuzzing & Scan Vulnerability.....................................78
3.14 Website thử nghiệm..............................................................................79
3.15 Danh sách các lỗ hổng website thử nghiệm..........................................80
3.16 Lỗ hổng XSS được phát hiện................................................................80
3
DANH MỤC BẢNG
1.1 Các trường tham số trong HTTP Request [13].....................................10
1.2 Bảng mã trạng thái HTTP [18]..............................................................12
1.3 Một số trường tham số trong HTTP Response.....................................12
1.4 Các thành phần của một Cookie............................................................15
1.5 Top 10 lỗ hổng website phổ biến nhất năm 2013 (OWASP) [11]........22
2.1 Các thuộc tính và các thẻ đi kèm có chứa các URL của hệ thống........45
2.2 Ví dụ trong fuzzing đường dẫn tương đương........................................53
2.3 Chèn dữ liệu fuzzing vào URL.............................................................54
2.4 Chèn dữ liệu fuzzing vào phương thức POST......................................54
2.5 Cơ chế phát hiện các lỗ hổng hệ thống.................................................58
2.6 Các mẫu thông báo lỗi từ SQL..............................................................59
2.7 Phát hiện các lỗi do cấu hình.................................................................61
3.1 Kết quả quá trình thu thập.....................................................................79
3.2 Danh sách các lỗ hổng phát hiện...........................................................80
4
DANH MỤC TỪ VIẾT TẮT
Từ viết tắt Nghĩa Tiếng Anh Nghĩa Tiếng Việt
HTTP Hypertext Transfer Protocol Giao thức truyền siêu văn bản
TCP Transmission Control Protocol Giao thức truyền TCP
HTML Hypertext Markup Language Ngôn ngữ đánh dấu siêu văn
bản
XML Extensible Markup Language Ngôn ngữ đánh dấu mở rộng
SSL Secure Sockets Layer Lớp bảo mật socket
XSS Cross Script Site Lỗ hổng XSS
CSRF Cross - Site Request Forgery Lỗ hổng CSRF
URL Uniform Resource Locator Địa chỉ tài nguyên
RFI Remote File Inclusion Lỗ hổng RFI
LFI Local File Inclusion Lỗ hổng LFI
OWASP The Open Web Application Dự án nghiên cứu bảo mật ứng
Security Project dụng web
GUI Graphical User Interface Giao diện đồ họa người dùng
CSDL Database Cơ sở dữ liệu
5
MỞ ĐẦU
Tên đồ án: “Nghiên cứu kỹ thuật Fuzzing áp dụng trong kiểm tra lỗ
hổng bảo mật website”.
1. Lý do chọn đề tài
Hiện nay, vấn đề bảo mật và an toàn thông tin đang ngày càng được
chính phủ, các cơ quan, doanh nghiệp chú trọng đầu tư. Tuy nhiên, không
phải tất cả các tổ chức, doanh nghiệp đều có thể trang bị đầy đủ cũng như có
thể đảm bảo an toàn, bảo mật thông tin một cách toàn diện. Theo khảo sát,
khoảng 75% các cuộc tấn công mạng được thực hiện thông qua ứng dụng web
hoặc thông qua website. Website không được kiểm tra kỹ lưỡng và đảm bảo
an toàn, do đó dễ dàng làm mồi cho những kẻ tấn công.
Theo thống kê của Bkav, tại Việt Nam, trung bình mỗi tháng lại có hơn
300 website của các doanh nghiệp, tổ chức trong nước bị tấn công. Kết quả
nghiên cứu của Bkav cũng cho thấy, tại Việt Nam có tới 40% website tồn tại
lỗ hổng. Còn theo báo cáo toàn cầu từ Kaspersky Lab, Việt Nam đứng thứ ba
trên thế giới về sự nguy hiểm tiềm ẩn khi lướt web với 35% số người dùng đã
bị tấn công. VNCERT cũng ghi nhận hơn 30.000 sự cố an ninh tại Việt Nam
trong năm 2015.
Cũng theo nhận định của các chuyên gia, 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 và cũng chưa có một sản phẩm hay quy trình chuẩ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.
Từ tình hình trên ta thấy cần thiết có một giải pháp, kỹ thuật xây dựng
hệ thống kiểm thử bảo mật cho mỗi hệ thống website, nhằm phát hiện và cảnh
báo 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ư phân quyền tài nguyên trên máy chủ không nghiêm ngặt, đặt tài khoản
mặc định,…
Trong phương pháp kiểm thử hộp đen, Fuzzing là một kỹ thuật phát
hiện lỗ hổng phần mềm, được thực hiện bằng cách cung cấp tự động hoặc bán
tự động bộ dữ liệu đầu vào bất thường, không hợp lệ hay ngẫu nhiên vào
6
chương trình nhằm theo dõi và xác định các trường hợp, hành vi bất thường
trong quá trình xử lý và trong kết quả trả về để phát hiện lỗ hổng bảo mật tiềm
ẩn.
Kỹ thuật fuzzing mang lại hiệu quả rất lớn cho việc kiểm thử cho các
vấn đề về an ninh trong các phần mềm, hệ thống máy tính và các ứng dụng
dịch vụ. Hiện tại, fuzzing là một kỹ thuật không thể tách rời của cộng đồng
kiểm thử với rất nhiều các mã nguồn mở, công cụ thương mại và những công
trình nghiên cứu liên quan.
Xuất phát từ thực tế trên, em đã lựa chọn đề tài “Nghiên cứu kỹ thuật
Fuzzing áp dụng trong kiểm tra lỗ hổng bảo mật website” thuộc phạm vi
các vấn đề đã nêu để làm đồ án tốt nghiệp nhằm góp phần đáp ứng yêu cầu
nghiên cứu lý luận, phục vụ công tác đảm bảo an toàn, bảo mật website.
2. Các công trình nghiên cứu có liên quan
Hiện nay, tại Việt Nam có rất ít các nghiên cứu về vấn đề này, một số
công trình nghiên cứu áp dụng kỹ thuật Fuzzing trong kiểm thử phần mềm
nhưng chưa đi sâu nghiên cứu kỹ thuật này trong bảo mật web, hay chỉ áp
dụng kỹ thuật Fuzzing cho quá trình người dùng tự kiểm thử thủ công mà
chưa có tự động hóa. Ví dụ:
- Đề tài “Xây dựng công cụ đánh giá an toàn website” của tác giả Lê
Ngọc Thức, nghiên cứu các lỗ hổng website và xây dựng ứng dụng nhưng
chưa đi sâu nghiên cứu các kỹ thuật kiểm thử.
- Đề tài “Nghiên cứu và ứng dụng công cụ kiểm thử tự động trong kiểm
thử phần mềm” của tác giả Mai Thị Nhi mới chỉ đưa ra nghiên cứu về kỹ
thuật Fuzzing trong phần mềm mà chưa có cho website.
- Đề tài “Nghiên cứu kiểm thử bảo mật website” của tác giả Đinh Thị
Thiên Anh, chưa đi sâu nghiên cứu về các phương pháp kiểm thử tự động bảo
mật website.
3. Mục đích nghiên cứu
- Thống kê và phân loại các lỗ hổng trên hệ thống website, cổng thông
tin điện tử,... Từ đó, đưa ra các biện pháp phòng ngừa cho từng loại lỗ hổng.
- Phân tích kỹ thuật fuzzing trong kiểm thử website, làm nền tảng cho
xây dựng ứng dụng.
7
- Xây dựng hệ thống kiểm thử bảo mật tự động cho website dựa trên kỹ
thuật fuzzing.
4. Nhiệm vụ nghiên cứu
Nhiệm vụ nghiên cứu của đồ án gồm các nội dung sau:
Nhiệm vụ 1: Tìm hiểu tổng quan về website, phương thức và mô hình
hoạt động của website.
Nhiệm vụ 2: Nghiên cứu các lỗ hổng bảo mật website, cách thức tấn
công và biện pháp phòng chống.
Nhiệm vụ 3: Tìm hiểu tổng quan về các phương pháp kiểm thử phần
mềm nói chung và kỹ thuật Fuzzing trong kiểm thử lỗ hổng bảo mật website
nói riêng.
Nhiệm vụ 4: Nghiên cứu kỹ thuật lập trình bất đồng bộ trên ngôn ngữ
C# nhằm tăng tốc độ truy vấn lấy toàn bộ nội dung website, đồng thời trích
xuất liên kết và xây dựng lại cấu trúc một website.
Nhiệm vụ 5: Xây dựng ứng dụng kiểm tra lỗ hổng bảo mật website dựa
trên cơ sở các nội dung nghiên cứu trước nhằm phát hiện lỗ hổng tồn tại
website, đồng thời đưa ra các khuyến nghị và cách thức khắc phục cho từng
loại lỗ hổng.
5. Đối tượng nghiên cứu
- Kiến trúc và phương thức hoạt động của website.
- Các loại lỗ hổng bảo mật website và những biện pháp phòng chống,
khắc phục tương ứng.
- Các phương pháp kiểm thử phần mềm, ứng dụng web.
- Giải pháp kiểm tra và phát hiện lỗ hổng bảo mật website bằng kỹ
thuật Fuzzing.
- Phần mềm kiểm tra lỗ hổng bảo mật website.
6. Phương pháp nghiên cứu
- Phương pháp nghiên cứu lý thuyết:
+ Tham khảo các chương trình, giáo trình đào tạo.
+ Thu thập và phân tích các tài liệu, thông tin liên quan đến các kỹ
thuật Fuzzing trong bảo mật website.
8
+ Tìm hiểu các kết quả nghiên cứu về các lỗ hổng bảo mật đã được
công bố hiện nay.
+ Sử dụng kết quả nghiên cứu từ dự án mở về bảo mật ứng dụng web
của OWASP.
- Phương pháp nghiên cứu thực nghiệm:
+ Tìm hiểu phần mềm kiểm thử bảo mật website hiện có tại Việt Nam
cũng như trên thế giới.
+ Tiến hành cài đặt và đánh giá thử nghiệm chương trình demo qua
từng giai đoạn.
7. Phạm vi nghiên cứu
- Không gian, thời gian: Trong phạm vi đồ án
- Kiến thức: Tổng quan bảo mật website và nghiên cứu kỹ thuật
Fuzzing để xây dựng phần mềm kiểm thử web với phạm vi nằm trong 10 lỗ
hổng nghiêm trọng nhất được OWASP công bố năm 2013.
8. Các đóng góp của đồ án
Các đóng góp của đồ án về mặt kiến thức và thực tiễn sau khi hoàn
thành như sau:
- Về mặt kiến thức: Đồ án trình bày đầy đủ các vấn đề chung về lỗ
hổng bảo mật website cũng như những nghiên cứu về quy trình Fuzzing trong
kiểm tra lỗ hổng bảo mật website, cung cấp cho người đọc một bộ tài liệu
phản ánh nhiều mặt kiến thức trong lĩnh vực kiểm thử bảo mật web.
- Về mặt thực tiễn: Sản phẩm của đồ án là một ứng dụng kiểm tra và
phát hiện lỗ hổng bảo mật website, góp phần giúp những người phát triển ứng
dụng web có thể kiểm tra website có tồn tại lỗ hổng bảo mật hay không. Từ
đó, đưa ra các biện pháp cụ thể để khắc phục chúng.
9. Bố cục của đồ án
Với giới hạn những vấn đề nghiên cứu trên, đồ án này được xây dựng
với cấu trúc phân thành 3 chương:
Chương 1: Tổng quan về kiểm thử website.
Chương 2: Kỹ thuật Fuzzing trong kiểm tra lỗ hổng bảo mật website.
Chương 3: Xây dựng ứng dụng kiểm tra lỗ hổng bảo mật website.
9
Chương 1
TỔNG QUAN VỀ KIỂM THỬ WEBSITE
Chương này sẽ trình bày tổng quan, mang tính lý thuyết về các vấn đề
có liên quan đến kiểm thử website. Trong đó, chú trọng đưa ra các khái niệm
cơ bản có liên quan đến đề tài như khái niệm về website, lỗ hổng bảo mật,
kiểm thử, kỹ thuật Fuzzing, tạo cơ sở lý thuyết cho việc đi sâu nghiên cứu các
vấn đề của đồ án.
Ngoài ra, chương này cũng trình bày chi tiết về các loại lỗ hổng bảo
mật web, đưa ra nguyên nhân, cơ chế phát hiện và cách phòng chống cho
từng loại. Nó là cơ sở tạo ra những đặc trưng cho quá trình phân tích phát
hiện lỗ hổng của Fuzzing trong chương 2.
Tại đây cũng trình bày tổng quan về kỹ thuật Fuzzing bao gồm phân
loại kỹ thuật, các ưu, nhược điểm của nó, từ đó đưa ra các lý do lựa chọn
Fuzzing là kỹ thuật được sử dụng cho kiểm thử bảo mật website.
1.1. Các khái niệm cơ bản
1.1.1. Website
Website là một tập hợp các trang web, thường chỉ nằm trong một tên
miền hoặc tên miền phụ trên World Wide Web của Internet. Một trang web là
tập tin HTML hoặc XHTML có thể truy nhập dùng giao thức HTTP. Website
có thể được xây dựng từ các tệp tin HTML (website tĩnh) hoặc vận hành bằng
các CMS chạy trên máy chủ (website động). Website có thể được xây dựng
bằng nhiều ngôn ngữ lập trình khác nhau (PHP, .NET, Java, Ruby on Rails…)
[17].
Một Website thường được bao gồm bởi 04 phần chính:
- Source code: Mã nguồn website, chứa tệp lệnh trích xuất HTML.
- Hosting: Bộ nhớ lưu trữ website.
- Database: Dữ liệu nội dung website.
- Domain: Tên miền của website, thực chất một website không cần đến
tên miền nó vẫn có thể hoạt động bình thường vì nó có địa chỉ IP. Bản chất
của tên miền là nó được ánh xạ sang địa chỉ IP thông qua máy chủ DNS, tạo
ra sự đơn giản cho người dùng dễ dàng truy cập vào web thông qua tên miền,
thay vì phải nhớ địa chỉ IP của website.
10
Ban đầu, các website chỉ bao gồm các nội dung văn bản, hình ảnh và
video, chúng được liên kết với nhau thông qua các link. Tác dụng của website
đơn giản chỉ là lưu trữ và hiển thị thông tin. Người dùng chỉ có thể đọc, xem,
di chuyển đến các được dẫn giữa các page. Với công nghệ hiện nay, website
không chỉ đơn giản là một trang tin cung cấp các thông tin. Trước sự ra đời
của các ngôn ngữ server như: CGI, ASP, PHP,… các website đã trở nên linh
hoạt, có thể tương tác với người dùng. Từ đây, người dùng có thể dùng web
để thực hiện một công việc nào đó bằng máy tính, do đó ứng dụng web được
ra đời.
Ứng dụng web là một ứng dụng chủ/khách sử dụng giao thức HTTP để
tương tác với người dùng hay hệ thống khác [5].
Trình khách là một trình duyệt web như: Internet Explorer, Chrome,
FireFox hay có thể là một chương trình có chức năng như một trình duyệt
web. Người dùng có thể gửi, nhận các dữ liệu từ máy chủ thông qua việc trao
đổi luồng thông tin với web server và hiển thị nội dung trang web nhận được
trên trình duyệt. Các ứng dụng web này có thể là các trang cổng thông tin
điện tử, trao đổi thông tin, mua bán, các diễn đàn, các trang gửi nhận thư,...
Tốc độ phát triển các kỹ thuật xây dựng ứng dụng web cũng phát triển
rất nhanh. Trước đây những ứng dụng web thường được xây dựng bằng CGI
(Common Getaway Interface) được chạy trên các máy chủ web và kết nối với
với các cơ sở dữ liệu đơn giản trên cùng một máy chủ. Ngày nay, ứng dụng
web thường được viết bằng PHP, ASP.Net, JSP (hay các ngôn ngữ tương tự)
và chạy trên máy chủ phân tán, kết nối đến nhiều nguồn dữ liệu.
Một ứng dụng web thường có kiến trúc gồm:
11
Hình 1.1. Kiến trúc một ứng dụng web
Trên hình 1.1 mô tả kiến trúc thông thường của một ứng dụng web bao
gồm các lớp:
- Lớp trình diễn: Lớp này có chức năng hiển thị dữ liệu mà nó nhận
được từ web server cho người dùng, ngoài ra còn có thể có chức năng tạo bố
cục và giao diện cho trang web.
- Lớp ứng dụng: Đây là nơi xử lý của ứng dụng web. Nó sẽ xử lý thông
tin yêu cầu từ người dùng, đưa ra quyết định, gửi kết quả đến lớp trình diễn.
Lớp này thường được cài đặt bằng các kỹ thuật lập trình dựa trên các ngôn
ngữ như CGI, Java, .NET, PHP,... và được triển khai trên host hoặc trên các
dịch vụ của máy chủ như Apache của Linux, IIS của Windows Server,…
- Lớp dữ liệu: Lớp này là các hệ quản trị dữ liệu SQL như MySQL,
SQL Server, Oracle,... chịu tránh nhiệm quản lý các file dữ liệu và quyền sử
dụng dữ liệu của toàn bộ website. Thường được triển khai trực tiếp trên cùng
hoặc tách biệt riêng với web server.
Việc phân lớp trong kiến trúc web tạo ra các hoạt động đơn giản nhưng
có liên kết chặt chẽ giữa các lớp. Nó giúp cho người quản trị dễ dàng triển
khai, vận hành và chủ động trong phòng, chống các cuộc tấn công. Ví dụ như
lớp ứng dụng có lỗi nhưng hệ thống, cơ sở dữ liệu được cấu hình đảm bảo thì
hacker khó có thể khai thác và làm ảnh hưởng tới hệ thống.
Hoạt động của một ứng dụng web là sự tương tác giữa trình khách với
web server. Dưới đây là mô hình hoạt động của một ứng dụng web:
12
Hình 1.2. Mô hình hoạt động của một ứng dụng web
Tương ứng các lớp của một ứng dụng web, hoạt động của một website
cũng có 3 phần:
- Trình khách (trình duyệt người dùng): Chrome, FireFox,…
- Trình chủ: Apache, IIS,…
- Hệ quản trị CSDL: Oracle, SQL Server, MySQL,…
Bên cạnh đó, một giải pháp dùng để bảo vệ hệ thống mạng thường
được sử dụng là bức tường lửa (firewall), nó có vai trò như lớp rào chắn bên
ngoài một hệ thống mạng, vì chức năng chính của firewall là kiểm soát luồng
thông tin giữa các máy tính. Có thể xem firewall như một bộ lọc thông tin, nó
xác định và cho phép một máy tính này có được truy xuất đến một máy tính
khác hay không, hay một mạng này có được truy xuất đến mạng kia hay
không [5].
Người ta thường dùng firewall vào mục đích:
- Cho phép hoặc cấm các dịch vụ truy xuất ra ngoài.
- Cho phép quy định cấm các hay cho phép dịch vụ từ bên ngoài truy
xuất vào trong.
- Kiểm soát địa chỉ truy nhập, cấm địa chỉ truy nhập.
Firewall hoạt động dựa trên góp IP do đó kiểm soát được việc truy cập
máy tính của người sử dụng.
1.1.1.1. Mô tả hoạt động của website
Trình duyệt tạo một HTTP Request gửi máy chủ web thông qua các
phương thức GET, POST,… của giao thức HTTP, yêu cầu cung cấp hoặc xử
lý tài nguyên thông tin. Địa chỉ của tài nguyên yêu cầu được xác định trong
định dạng URL.
Sau khi nhận được truy vấn từ trình khách, máy chủ web xác định sự
tồn tại của tài nguyên được yêu cầu. Nếu yêu cầu can thiếp các quyền truy cập
của tài nguyên thì máy chủ web từ chối truy vấn và trả về cảnh báo thích hợp.
Nếu yêu cầu là hợp lệ, lúc này máy chủ có thể cho thực thi một chương trình
được xây dựng từ ngôn ngữ như Perl, C/C++,… hoặc máy chủ yêu cầu bộ
biên dịch thực thi các trang PHP, ASP, JSP,… theo yêu cầu của máy khách.
13
Tùy theo các tác vụ của chương trình được cài đặt mà nó xử lý, tính toán, kết
nối đến cơ sở dữ liệu, lưu các thông tin do máy khách gửi đến.
Khi máy chủ web định danh được tài nguyên, nó thực hiện hành động
chỉ ra trong request method và tạo ra response trả về cho máy khách 1 luồng
dữ liệu có định dạng theo giao thức HTTP, nó gồm 2 phần:
- Header mô tả các thông tin về gói dữ liệu và các thuộc tính, trạng thái
trao đổi giữa trình duyệt và WebServer.
- Body là phần nội dung dữ liệu mà Server gửi về Client, nó có thể là
một file HTML, một hình ảnh, một đoạn phim hay một văn bản bất kì.
Khi giao dịch hoàn tất, máy chủ web thực hiện ghi vào tệp tin nhật ký
mô tả giao dịch vừa thực hiện.
Với firewall, luồng thông tin giữa máy chủ và máy khách là luồng
thông tin hợp lệ. Vì thế, nếu hacker tìm thấy vài lỗ hổng trong ứng dụng Web
thì firewall không còn hữu dụng trong việc ngăn chặn hacker này. Do đó, các
kỹ thuật tấn công vào một hệ thống mạng ngày nay đang dần tập trung vào
những sơ suất (hay lỗ hổng) trong quá trình tạo ứng dụng của những nhà phát
triển Web hơn là tấn công trực tiếp vào hệ thống mạng, hệ điều hành. Tuy
nhiên, hacker cũng có thể lợi dụng các lỗ hổng Web để mở rộng sự tấn công
của mình vào các hệ thống không liên quan khác [5].
1.1.1.2. Các thuật ngữ liên quan
a. Http header
HTTP header là phần đầu của gói tin giao thức HTTP, thông tin mà
máy khách và máy chủ gửi cho nhau. Những thông tin máy khách gửi cho
máy chủ được gọi là HTTP requests (yêu cầu) còn máy chủ gửi cho máy
khách là HTTP responses (trả lời). Thông thường, một HTTP header gồm
nhiều dòng, mỗi dòng chứa tên tham số và giá trị. Một số tham số có thể được
dùng trong cả header yêu cầu và header trả lời, còn số khác thì chỉ đuợc dùng
riêng trong từng loại [3].
Ví dụ: Một header yêu cầu được thực hiện gửi tới đường dẫn:
http://localhost:8080/Apple/index.php
GET /Apple/index.php HTTP/1.1

Host: localhost:8080
14
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/53
(KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/
*;q=0.8
Referer: http://localhost:8080/Apple/index.php
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: vi
Cookie:
__utma=111872281.900455997.1485134486.1485134486.1485134486.1;
__utmz=111872281.1485134486.1.1.utmcsr=(direct)|utmccn=(direct)|
utmcmd=(none)
- Dòng đầu là dòng yêu cầu cho biết phương thức yêu cầu (GET hoặc
POST), địa chỉ yêu cầu (/Apple/index.php?ac=ipad) và phiên bản HTTP
(HTTP/1.1).
- Tiếp theo là các trường tham số mô tả cho các thông tin trong header.
Một số các trường cơ bản được mô tả như trong bảng 1.1 dưới đây:
Bảng 1.1. Các trường tham số trong HTTP Request [13]
STT Trường Mô tả
1 Host Tên miền của máy chủ và số cổng TCP trên máy
chủ đang nghe. Số cổng có thể bị bỏ qua nếu là
cổng tiêu chuẩn cho dịch vụ được yêu cầu (80).
2 Connection Các tùy chọn cho kiểu kết nối ngắt hay kết nối
liên tục sau khi hoàn thành một giao dịch.
3 Accept Các loại nội dung có thể chấp nhận.
4 Accept- Cho biết loại ngôn ngữ đang được dùng trên
Language website này.
5 Accept-Encoding Danh sách các loại mã hóa được chấp nhận.
15
6 Authorization Chứng thực cho xác thực HTTP.
7 User-Agent Trường User-Agent chứa các thông tin về tác

nhân tạo yêu cầu.
8 Referer Cho biết địa chỉ của trang web tham chiếu tới.
9 Cookie Trường này chứa một cặp tên/giá trị của thông tin
để giữ lại cho URL.
10 Range Xác định phần nội dung được yêu cầu.
Header của HTTP request sẽ kết thúc bằng một dòng trống, nhằm tạo
khoảng cách giữa phần tiêu đề và phần thân mang các dữ liệu truy vấn được
sử dụng trong phương thức khác như POST.
Header trả lời từ server:
HTTP/1.1 200 OK
Date: Sun, 02 Apr 2017 09:18:42 GMT
Server: Apache/2.2.8 (Win32) PHP/5.2.6
X-Powered-By: PHP/5.2.6
Content-Length: 6427
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
Set-Cookie:
ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBMFLJ;
path=/
Cache-control: private
<HTML>
<BODY>
...
16
- Dòng đầu là dòng trạng thái, để cho biết phiên bản HTTP được dùng
(HTTP/1.1), (200) và trạng thái (OK). Nó được phân loại thành 5 loại mã
chính và được mô tả trong bảng 1.2:
Bảng 1.2. Bảng mã trạng thái HTTP [18]
STT Mã Mô tả
1 1xx Information (Thông tin): Khi nhận được những mã như vậy
tức là request đã được server tiếp nhận và quá trình xử lý
request đang được tiếp tục.
2 2xx Success (Thành công): Khi nhận được những mã như vậy
tức là request đã được server tiếp nhận, hiểu và xử lý thành
công
3 3xx Redirection (Chuyển hướng): Mã trạng thái này cho biết

client cần có thêm action để hoàn thành request
4 4xx Client Error (Lỗi Client): Nó nghĩa là request chứa cú pháp

không chính xác hoặc không được thực hiện.
5 5xx Server Error (Lỗi Server): Nó nghĩa là Server thất bại với
việc thực hiện một request nhìn như có vẻ khả thi.
- Tiếp theo là các trường tham số, mỗi trường mang những đặc trưng
cho một thông tin về gói tin HTTP response trả về. Một số trường được mô tả
như bảng 1.3 dưới đây:
Bảng 1.3. Một số trường tham số trong HTTP Response
STT Trường Mô tả
1 Date Thời điểm phản hồi từ phía Server.
2 Server Các thông tin về Server, thông tin về phần mềm
được sử dụng bởi Server để kiểm soát yêu cầu.
3 Content-Length Độ dài của gói tin HTTP Response.
4 Content-Type Loại nội dung gói tin gửi về.
17
5 Set-Cookie Trường này chứa một cặp tên/giá trị của thông tin
để giữ lại cho URL.
6 Cache-control Để xác định các tham số cho bộ nhớ đệm hoặc yêu
cầu các loại cụ thể về bộ nhớ đệm.
7 Location Thông tin về đường dẫn sẽ được chuyển hướng tới,
thường đi cùng mã trạng thái 302.
8 Age Lượng thời gian từ khi phản hồi được tạo ra tại
Server ban đầu của người gửi
9 Pragma Các chỉ dẫn cụ thể để thực hiện.
- Khoảng cách một dòng trống để báo hiệu kết thúc header để nối tiếp
phần thân của HTTP response.
b. Session
HTTP là giao thức hướng đối tượng tổng quát, phi trạng thái, nghĩa là
HTTP không lưu trữ trạng thái làm việc giữa trình duyệt với máy chủ. Sự
thiếu sót này gây khó khăn cho một số ứng dụng Web, bởi vì máy chủ không
biết được trước đó trình duyệt đã có những trạng thái nào. Vì thế, để giải
quyết vấn đề này, ứng dụng Web đưa ra một khái niệm phiên làm việc
(Session). Còn SessionID là một chuỗi để chứng thực phiên làm việc. Một số
máy chủ sẽ cung cấp một sessionID cho người dùng khi họ xem trang web
trên máy chủ [5].
Session là khoảng thời gian người sử dụng giao tiếp với 1 ứng dụng.
Session bắt đầu khi người sử dụng truy cập vào ứng dụng lần đầu tiên, và kết
thúc khi người sử dụng thoát khỏi ứng dụng. Mỗi session sẽ có một định danh
(ID). Trong ngữ cảnh ứng dụng web, website sẽ quyết định khi nào session
bắt đầu và kết thúc. Trong 1 session, website có thể lưu trữ một số thông tin
như đánh dấu bạn đã login hay chưa, những bài viết nào bạn đã đọc qua,…
[19]
Để duy trì phiên làm việc thì sessionID thường được lưu vào:
- Biến trên URL
- Biến ẩn form
18
- Cookie
Phiên làm việc chỉ tồn tại trong một khoảng thời gian cho phép, thời
gian này được cấu hình quy định tại máy chủ hoặc bởi ứng dụng thực thi.
Máy chủ sẽ tự động giải phóng phiên làm việc để khôi phục lại tài nguyên
trao đổi của hệ thống.
c. Cookie
Cookie là những phần dữ liệu nhỏ có cấu trúc được chia sẻ giữa máy
chủ và trình duyệt của người dùng [1].
Cookie mang một số đặc điểm chính như sau:
- Cookie được lưu trữ tại brower dưới những file dữ liệu nhỏ dạng text
(trong memory hoặc trên đĩa) và sẽ gửi ngược lên lại server mỗi khi browser
tải 1 trang web từ server.
- Được ứng dụng tạo ra để lưu trữ, truy tìm, nhận biết các thông tin về
người dùng đã ghé thăm trang web và những vùng mà họ đi qua trong trang.
Những thông tin này có thể bao gồm tên/định danh người dùng, mật khẩu, sở
thích, thói quen…
- Cookie được trình duyệt của người dùng mặc định chấp nhận lưu trên
ổ cứng của máy tính, tuy nhiên người dùng có thể thiết lập không chấp nhận
lưu trữ cookies.
- Cookie được tạo ra bởi website và gởi tới browser, do vậy 2 website
khác nhau (cho dù cùng host trên 1 server) sẽ có 2 cookie khác nhau gởi tới
browser. Ngoài ra, mỗi browser quản lý và lưu trữ cookie theo cách riêng của
mình, cho nên 2 browser cùng truy cập vào 1 website sẽ nhận được 2 cookie
khác nhau.
Ở những lần truy cập sau đến trang Web đó, ứng dụng có thể dùng lại
những thông tin trong cookie mà người dùng không phải làm lại thao tác đăng
nhập hay phải cung cấp lại các thông tin khác [1].
Cookie được phân làm 2 loại secure/non-secure và persistent/non-
persistent do đó ta sẽ có 4 kiểu cookie là:
- Persistent và Secure
- Persistent và Non-Secure
- Non-Persistent và Secure
19
- Non-Persistent và Non-Secure
Persistent cookies được lưu trữ dưới dạng tập tin .txt (ví dụ như trình
duyệt Internet Explorer lưu cookie thành nhiều tập tin *.txt trong đó mỗi tập
tin là một cookie) được lưu trữ trên ổ cứng của máy tính và không bị xóa khi
trình duyệt đóng lại. Những cookie này có thể thiết lập những sở thích của
bạn đối với mỗi trang web cụ thể khi bạn quay lại, cho phép những ưu đãi sẽ
được sử dụng trong những lần trình duyệt tiếp theo.
Non-persistent cookie là loại cookie tạm thời, nó được lưu trữ trên bộ
nhớ RAM của máy khách và sẽ bị hủy khi đóng trang web hay nhận được
lệnh hủy từ trang web. Bằng việc xóa cookie của bạn theo định kỳ sẽ làm
giảm nguy cơ của việc lạm dụng thông tin vô tình hay cố ý lưu trữ trong
cookie.
Secure cookies chỉ có thể được gửi thông qua giao thức HTTPS (SSL),
nhằm tránh cho các nguy cơ bị giả mạo cookie.
Non-Secure cookie có thể được gửi bằng cả hai giao thức HTTPS hay
HTTP. Thực chất là đối với secure cookie thì máy chủ sẽ cung cấp chế độ
truyền bảo mật.
Bảng 1.4. Các thành phần của một Cookie
Domain Flag Path Secure Expiration Name Value
www.redhat.co FALSE / FALSE 1154029490 Apache 64.3.40.151.16

m 018996349247
480
- Domain: Tên miền của trang web đã tạo cookie cung cấp cho người
dùng (www.redhat.com)
- Flag: Mang giá trị True/False - xác định các máy khác với cùng tên
miền có được truy xuất đến cookie hay không.
- Path: Phạm vi các địa chỉ có thể truy xuất cookie. Ví dụ: Nếu path là
“/home” thì các địa chỉ trong thư mục /home cũng như tất cả các thư mục con
của nó như /home/path1 có thể truy xuất đến cookie này. Còn nếu giá tri là “/”
thì cookie sẽ được truy xuất bởi tất cả địa chỉ thuộc miền trang web tạo ra
cookie.
20
- Sercure: mang giá trị True/False - Xác định quá trình truyền cookie là
kết nối có sử dụng mã hóa SSL hay không.
- Expiration: thời gian hết hạn của cookie, được tính bằng giây kể từ
0:00:00 giờ GMT ngày 01/01/1970. Nếu giá trị này không được thiết lập thì
trình duyệt sẽ hiểu đây là non-persistent cookie và chỉ lưu trong bộ nhớ RAM
và sẽ xoá nó khi trình duyệt bị đóng.
- Name: Tên biến (Apache)
- Value: Với cookie được tạo ở trên thì giá trị của Apache là
64.3.40.151.16018996349247480 và ngày hết hạn là 27/07/2006, của tên
miền http://www.redhat.com
Ví dụ chuỗi lệnh trong HTTP header dưới đây sẽ tạo một cookie:
Set-Cookie: Apache="64.3.40.151.16018996349247480"; path="/";

domain="www.redhat.com"; path_spec; expires="2006-07-27 19:39:15Z";
version=0
- Các cookie của Internet Explorer được đặt trong một tập tin
Cookies.txt, với đường dẫn là: C:\Program Files\Netscape\Users\UserName\
Cookies.txt
- Các cookies của IE được lưu thành nhiều tập tin, mỗi tập tin là một
cookie và thường được đặt tại C:\Documents and Setting\ [username]\
Cookies.
Kích thước tối đa của một cookie là 4kb. Số cookie tối đa cho một tên
miền là 20 cookie. Cookie bị hủy ngay khi đóng trình duyệt gọi là “session
cookie”.
Sử dụng Session hay Cookie:
- Trong một số trường hợp Cookie không sử dụng được. Có thể
browser đã được thiết lập để không chấp nhận cookie, lúc đó session vẫn sử
dụng được bằng cách truyền session ID giữa các trang web qua URL, ví dụ:
script.php?session=abc123 [19].
- Lượng dữ liệu truyền tải giữa browser và server: chỉ mỗi session ID
được truyền giữa browser và server, data thực sự được website lưu trữ trên
server.
21
- Bảo mật: thông tin được truyền tải qua lại giữa server, client và thông
tin được lưu trữ tại client càng ít càng tốt.
d. Proxy
Proxy là một máy chủ internet hay một phần mềm làm nhiệm vụ
chuyển tiếp thông tin và kiểm soát tạo sự an toàn cho việc truy cập internet
của các máy khách [17].
Proxy cung cấp cho người dùng truy xuất internet những nghi thức đặc
biệt hoặc tập những nghi thức thực thi trên dual_homed host hoặc basion host.
Những chương trình client của người sử dụng sẽ phải đi qua trung gian proxy
server thay thế cho server thật sự mà người sử dụng cần giao tiếp.
Proxy server xác định những yêu cầu từ client và quyết định đáp ứng
hay không đáp ứng, nếu yêu cầu được đáp ứng, proxy server sẽ kết nối với
server thật thay cho client và tiếp tục chuyển tiếp những yêu cầu từ client đến
server, cũng như trả lời của server đến client. Vì vậy proxy server giống cầu
nối trung gian giữa server và client [5].
1.1.2. Lỗ hổng bảo mật
Lỗ hổng bảo mật trên một hệ thống là các điểm yếu có thể tạo ra sự
ngưng trệ của dịch vụ, thêm quyền đối với người sử dụng hoặc cho phép các
truy nhập không hợp pháp vào hệ thống. Các lỗ hổng cũng có thể nằm ngay
các dịch vụ cung cấp như sendmail, web, ftp … Ngoài ra các lỗ hổng còn tồn
tại ngay chính tại hệ điều hành như trong Windows XP, Windows NT, UNIX;
hoặc trong các ứng dụng mà người sử dụng thường xuyên sử dụng như Word
processing, Các hệ databases… [3]
Có thể nói lỗ hổng bảo mật là những điểm yếu trên hệ thống hoặc ẩn
chứa trong một dịch vụ mà dựa vào đó kẻ tấn công có thể xâm nhập trái phép
để thực hiện các hành động phá hoại hay chiếm đoạt các tài nguyên hợp pháp.
Nguyên nhân gây ra lỗ hổng bảo mật là khác nhau:
- Do lỗi của bản thân hệ thống
- Do phần mềm cung cấp hoặc do người lập trình
- Do người quản trị yếu kém không hiểu sâu sắc các dịch vụ cung cấp.
1.1.3. Lỗ hổng website
22
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 website [20].
Lỗ hổng website có thể xuất phát từ nhiều nguyên nhân, tuy nhiên chủ
yếu là do 3 nguyên nhân sau:
- Lỗi do người lập trình, phát triển ứng dụng tập trung vào chức năng
và tốc độ mà không quan tâm đến an toàn. Ứng dụng không có thành phần
kiểm tra hay kiểm tra yếu các dữ liệu đầu vào từ người dùng, từ đó, kẻ tấn
công có thể lợi dụng lỗ hổng từ mã nguồn để khai thác và tấn công hệ thống.
- Lỗi do người quản trị cấu hình hệ thống yếu, cấu hình hệ thống mặc
định, tài khoản mặc định, không thường xuyên cập nhật phiên bản mới cho
các dịch vụ triển khai trên hệ thống.
- 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. Ví dụ như giao thức HTTP hoạt động theo chuẩn
mô hình client/server đơn giản và khi xây dựng giao thức này người ta chưa
quan tâm đến vấn đề bảo mật.
1.1.4. Kiểm thử phần mềm
Kiểm thử phần mềm được định nghĩa theo nhiều cách khác nhau, dưới
đây là một số định nghĩa:
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần
dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá
một khía cạnh nào đó của hệ thống hay thành phần đó [9].
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục
đích tìm lỗi [8].
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch
vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm
cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản
phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra
các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu
của phần mềm trong nhiều ngành khác nhau [17].
Có thể định nghĩa một cách dễ hiểu như sau:
23
Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình
được thiết kế và thực hiện nhằm đảm bảo cho hệ thống thực hiện theo đúng
những yêu cầu mà chúng đã được thiết kế và không thực hiện những điều
không mong muốn. Kiểm thử phần mềm là một pha quan trọng trong quá
trình xây dựng và phát triển hệ thống, chúng giúp cho người phát triển hệ
thống và các khách hàng thấy được hệ thống mới đã đáp ứng các yêu cầu đặt
ra.
Các phương pháp kiểm thử phần mềm có thể chia làm 3 loại:
- Kiểm thử hộp đen (Black box testing)
- Kiểm thử hộp trắng (White box testing)
- Kiểm thử hộp xám (Gray box testing)
1.1.4.1. Kiểm thử hộp đen
Là phương pháp kiểm thử được thực hiện mà không biết được cấu trúc
và hành vi bên trong của phần mềm, là cách kiểm thử mà hệ thống được xem
như một chiếc hộp đen, không cách nào nhìn thấy phía bên trong cái hộp [14].
Một số phương pháp kiểm thử hộp đen:
- Kiểm thử fuzzing (Fuzz testing)
- Phân lớp tương đương (Equivalence partitioning)
- Phân tích giá trị biên (Boundary value analysis)
- Kiểm thử mọi cặp (All-pairs testing)
- Ma trận dấu vết (Traceability matrix)
- Kiểm thử thăm dò (Exploratory testing)
Hình 1.3. Kiểm thử hộp đen

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, những kiểm
thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng,
mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối
24
mà không có đèn”, bởi vì kiểm thử viên không biết các phần mềm được kiểm
tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp
mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ
gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất [6] .
Do vậy, kiểm thử hộp đen có ưu điểm của một sự đánh giá khách quan,
mặt khác nó lại có nhược điểm của một thăm dò mù.
1.1.4.2. Kiểm thử hộp trắng
Là phương pháp kiểm thử trái ngược hoàn toàn với kiểm thử hộp đen,
nó cho phép kiểm tra cấu trúc bên trong của một phần mềm với mục đích đảm
bảo rằng tất cả các mã lệnh, thuật toán và điều kiện sẽ được thực hiện ít nhất 1
lần.
Một số phương pháp kiểm thử hộp trắng:
- Kiểm thử giao diện lập trình ứng dụng (API testing)
- Bao phủ mã lệnh (Code coverage)
- Các phương pháp gán lỗi (Fault injection)
- Các phương pháp kiểm thử hoán chuyển (Mutation testing methods)
- Kiểm thử tĩnh (Static testing)
Hình 1.4. Kiểm thử hộp trắng

Kiểm thử hộp trắng có thể áp dụng tại cấp đơn vị, tích hợp hệ thống và
các cấp độ của quá trình kiểm thử phần mềm. Mặc dù phương pháp này thiết
kế kiểm thử có thể phát hiện ra nhiều lỗi hoặc các vấn đề, nhưng nó có thể
không phát hiện các phần chưa thực hiện của các đặc điểm kỹ thuật hoặc yêu
cầu thiếu sót [17].
1.1.4.3. Kiểm thử hộp xám
Là sự kết hợp của kiểm thử hộp đen và hộp trắng. Trong kiểm thử hộp
xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, người kiểm thử có
25
thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với
mục đích là để thiết kế đầu vào, nhưng khi kiểm tra thì như ở mức hộp đen.
Hình 1.5. Kiểm thử hộp xám

Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không
rõ ràng, giống như một chiếc hộp xám, bởi vì đầu vào và đầu ra rõ ràng là ở
bên ngoài hộp đen mà chúng ta vẫn gọi về hệ thống được kiểm tra [6].
1.1.5. Kiểm thử website
Kiểm thử website là một thành phần trong kiểm thử phần mềm nhưng
tập trung vào các ứng dụng web, nhằm đảm bảo các ứng dụng web hoạt động
một cách hiệu quả, chính xác và đáp ứng được nhu cầu của khách hàng. Hiện
nay, nó đang là một trong những thành phần đang phát triển nhanh nhất của
kiểm thử phần mềm.
Hoàn thành quá trình kiểm thử của một hệ thống web trước khi đi vào
hoạt động là bước đầu để có được sự đảm bảo về khả năng các ứng dụng được
xây dựng trên trang web đang hoạt động đúng. Nó giúp giải quyết các vấn đề
như tính sẵn sàng, toàn vẹn, bảo mật của hệ thống web, đáp ứng cho số lượng
ngày càng tăng cao người sử dụng và khả năng sống sót trong lưu lượng truy
cập của người dùng. Việc bỏ qua các vấn đề trong kiểm thử trước khi đi vào
hoạt động có thể ảnh hưởng đến khả năng hoạt động của chính website đó.
Sau khi thực hiện kiểm thử web, kiểm thử viên có thể tìm thấy các sự
cố trong hệ thống trước khi chúng xảy ra trong môi trường người dùng.
1.1.6. Fuzzing
Trong lĩnh vực an ninh ứng dụng, Fuzzing hay kiểm thử mờ (fuzz
testing) là một kỹ thuật thuộc kiểm thử hộp đen (black box), phát hiện lỗi của
phần mềm bằng cách tự động hoặc bán tự động cung cấp dữ liệu đầu vào
không hợp lệ, không mong đợi hay ngẫu nhiên vào phần mềm. Phần mềm sẽ
được giám sát và ghi lại các trường hợp ngoại lệ như lỗi mã không được thực
thi, tài nguyên thất thoát,... nhằm xác định các hành vi bất thường, phát hiện
26
các lỗ hổng bảo mật tiềm ẩn của phần mềm. 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 [16].
Các chương trình và framework được dùng để tạo ra kỹ thuật fuzzing
hoặc thực hiện fuzzing được 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.
Fuzzing là một trong những kỹ thuật của kiểm thử hộp đen, không đòi
hỏi quyền truy cập vào mã nguồn. Do đó, nó có khả năng tìm thấy lỗi một
cách nhanh chóng và tránh được việc phải xem mã nguồn.
Fuzzing cũng giống như các kỹ thuật kiểm thử phần mềm, nhưng nó
được sử dụng để phát hiện ra một loạt các vấn đề của web như: Cross Site
Scripting, tràn bộ đệm, chèn câu truy vấn (SQL Injection),... [16]
1.2. Các loại lỗ hổng bảo mật web
1.2.1. Phân loại các lỗ hổng bảo mật web
Bảng 1.5. Top 10 lỗ hổng website phổ biến nhất năm 2013 (OWASP) [11]
Top 10 OWASP 2013
STT Lỗ hổng Mô tả
1 Injection Sai sót trong nhập liệu. Điều này xảy ra khi các
thông tin sai lệch được đưa vào cùng với các biến
dữ liệu đầu vào như 1 phần của lệnh hay câu truy
vấn.
2 Broken Xác thực hay quản lý phiên thiếu chính xác. Sơ hở

Authentication này cho phép kẻ tấn công có thể lợi dụng để đạt
and Session được mật khẩu, khóa hay phiên làm việc, từ đó mạo
Management danh phiên làm việc người dùng.
3 Cross-Site Sai sót trong kiểm duyệt nội dung đầu vào cũng dẫn
Scripting đến rủi ro này. Các dữ liệu bất hợp lệ được gửi đến
(XSS) trình duyệt mà không cần sự xác nhận thông
thường.
4 Insecure Direct Điều này xảy ra thì nhà phát triển cho thấy có các
27
Object tham chiếu trực tiếp đến một đối tượng nội bộ hay
References của người dùng khác. Điều này cho phép kẻ tấn
công có thể truy cập các tài liệu một cách trái phép.
5 Security Một hệ thống bảo mật tốt là hệ thống triển khai cho
Misconfigurati khung ứng dụng, máy chủ ứng dụng, máy chủ cơ sở
on dữ liệu, nền tảng… các phương pháp bảo mật cần
thiết, thống nhất và liên kết với nhau.
6 Sensitive Data Các dữ liệu nhạy cảm không được lưu trữ và bảo vệ
Exposure cẩn thận, dẫn đến khi bị kẻ tấn công khai thác.
7 Missing Thiếu các điều khoản trong việc phân quyền quản
Function Level trị các mức, dẫn đến việc kẻ tấn công có thể lợi
Access Control dụng và truy ra các điểm yếu trên hệ thống, hay lợi
dụng leo thang đặc quyền.
8 Cross-Site Lợi dụng sơ hở của nạn nhân, kẻ tấn công có thể lừa
Request nạn nhân thực hiện các hành động nguy hiểm mà
Forgery nạn nhân không hề hay biết, ví dụ như chuyển tiền
(CSRF) từ tài khoản nạn nhân sáng tài khoản kẻ tấn công,
thông qua các lỗ hổng XSS.
9 Using Known Sử dụng các thư viện, plugin, module… có chứa các
Vulnerable lỗ hổng đã được công khai, dễ dàng dẫn đến việc bị
Components kẻ tấn công lợi dụng để tấn công vào hệ thống một
cách nhanh chóng.
10 Unvalidated Chuyển hướng không an toàn người dùng đến một

Redirects and đường dẫn bên ngoài. Kẻ tấn công lợi dụng để
Forwards chuyển hướng nạn nhân đến một trang đích được
chuẩn bị sẵn của kẻ tấn công.
Dựa trên các đặc trưng của từng loại lỗ hổng có các điểm giống nhau,
có thể phân thành một số loại lỗ hổng website chính như sau:
- Injection: Các lỗ hổng do không kiểm soát chặt chẽ dữ liệu đầu vào
giúp cho tin tặc chèn các mã lệnh bất hợp pháp để thực thi như SQL Injection,
XPath Injection, System Command Injection, LDAP Injection...
28
- Client Side: Loại lỗ hổng nhằm mục đích tấn công vào người dùng,
nó đặc biệt nguy hiểm với người quản trị. Ví dụ như Cross Site Scripting
(XSS), Cross-site Request Forgery (CSRF)...
- Parameter Manipulation: Loại lỗ hổng khi kẻ tấn công sửa đổi các
tham số trong yêu cầu gửi tới máy chủ. Một số lỗ hổng như Cookie
Manipulation, HTTP Form Field Manipulation,…
- Misconfiguration: Các lỗ hổng do người lập trình và quản trị cấu hình
hệ thống chưa an toàn như phân quyền không chính xác, cấu hình tài khoản,
mật khẩu mặc định...
- Information Disclosure: Các lỗ hổng làm lộ lọt các thông tin quan
trọng của hệ thống, tin tặc có thể lợi dụng điều này để biết thông tin hệ thống
và thực hiện các cuộc tấn công tiếp theo [20]. Ví dụ như: Path Traversal,
Predict Resource Location, Directory Listing...
1.2.2. Một số lỗ hổng bảo mật ứng dụng web chính
Mỗi lỗ hổng bảo mật sẽ có cách khai thác và phát hiện khác nhau. Dưới
đây là một số lỗ hổng chính và 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.2.2.1. Lỗ hổng Injection
a. Khái quát
Lỗ hổng injection là loại lỗ hổng liên quan tới việc thao tác với câu truy
vấn CSDL, cho phép những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ
liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ
sở dữ liệu trả về để thực hiện thay đổi cấu trúc câu truy vấn SQL và thực thi
chúng một cách bất hợp pháp [10].
Sql Injection có thể cho phép những kẻ tấn công thực hiện các thao tác,
thêm, sửa, xóa… trên cơ sở dữ liệu của ứng dụng. Lỗi này thường xảy ra trên
các ứng dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu
như SQL Server, MySQL, Oracle, DB2, Sysbase... hay dữ liệu XML.
Nguyên nhân chủ yếu là do người lập trình không kiểm soát hoặc có
kiểm soá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.
29
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.
Ví dụ: Giả sử ứng dụng web sử dụng câu truy vấn sau để kiểm tra đăng
nhập người dùng:
SELECT * FROM user WHERE username= “Username” AND password=

“Password”;
Người tấn công sử dụng ký tự đặc biệt SQL để thâm nhập vào hệ thống
như sau:
Username: admin” or 1-- -

Password:
Ta được câu truy vấn SQL như sau:
SELECT * FROM user WHERE username= “admin” or 1-- - AND

password= “”;
Điều kiện sau WHERE sẽ trở nên luôn đúng và kết quả là hệ quản trị
CSDL sẽ trả về tất cả các bản ghi có trong bảng users. Vì vậy, câu lệnh trên
cho phép đăng nhập vào hệ thống mà không đòi hỏi password.
b. Cơ chế phá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 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. Ví dụ
như khi thêm dấu nháy đơn ' sau một biến truy vấn, ta nhận được thông báo
lỗi từ SQL như dưới đây, điều đó chứng tỏ có thể khai thác lỗ hổng SQL
Injection.
You have an error in your SQL syntax; check the manual that corresponds
to your MySQL server version for the right syntax to use near '' ' '' at line 1
30
- Dựa trên kỹ thuật boolean based, kiểm tra kết quả trả về khác nhau
của các câu truy vấn khác nhau để xác định câu truy vấn sau khi được chèn có
được thực thi hay không, từ đó xác định lỗi hay không lỗi SQL, ví dụ như khi
chèn or 1=1, or 1=2 hay and 1=1, and 1=0,...
- Dựa trên kỹ thuật nối câu truy vấn, kỹ thuật này nhằm xác định các
thông tin về các trường thông tin của cơ sở dữ liệu. Ví dụ như UNION query.
- Dựa trên kỹ thuật time based: là kỹ thuật 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ề có
phù hợp với truy vấn sau khi chèn hay không. Ví dụ như sleep(),...
c. Cách thức phòng tránh
Lỗ hổng 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 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 chặt chẽ
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. Vì vậy để
phòng chống được lỗ hổng SQL Injection phải bảo vệ các câu truy vấn SQL
bằng cách kiểm soát chặt chẽ tất cả các dữ liệu nhập nhận được từ đối tượng
Request. Dưới đây là một số biện pháp phòng chống:
- Những kí tự nên được mã hoá trên địa chỉ URL trước khi được sử
dụng.
- Không cho hiển thị những thông điệp lỗi cho người dùng bằng cách
thay thế những thông báo lỗi bằng 1 trang do người phát triển thiết kế mỗi khi
lỗi xảy ra trên ứng dụng.
- Đối với giá trị numeric, thực hiện chuyển nó sang integer trước khi
thực thi câu truy vấnSQL, hoặc dùng ISNUMERIC để chắc chắn là một số
integer.
- Dùng thuật toán để mã hoá dữ liệu trong database.
31
- Kiểm tra và lọc các giá trị nhập vào của người dùng, loại bỏ những kí
tự đặc biệt. Sử dụng một số các hàm chống Sql injection như:
mysql_real_escape_string()
addslashes()
preg_match('/[&\-+\*\/\|#]/',$x)
preg_match('/(and|or|union)/i', $x)
- Cuối cùng, để hạn chế thiệt hại do tấn công SQL Injection, nên kiểm
soát chặt chẽ và giới hạn quyền xử lí dữ liệu của tài khoản người dùng mà
ứng dụng web đang sử dụng. Các ứng dụng thông thường nên tránh dùng các
quyền như dbo hay sa. Quyền càng hạn chế, thiệt hại càng ít.
1.2.2.2. Lỗ hổng Cross Site Script
a. Khái quát
Cross-site Scripting (XSS) là một lỗ hổng ứng dụng web trong đó một
người dùng cuối có thể tấn công bằng cách chèn vào các website động (ASP,
PHP, CGI, JSP ...) những thẻ HTML hay những đoạn mã script nguy hiểm có
thể gây nguy hại cho những người sử dụng khác. Lỗ hổng XSS đã tồn tại từ
lâu nhưng kịch bản hiện nay vẫn có thể thực hiện với những kiểu tấn công
mới trong tương lai [4].
Hiện nay có 3 loại tấn công cross site scripting phổ biến:
- Stored or Persistent vulnerability: Là lỗ hổng XSS mà đoạn mã chèn
thêm vào được lưu trữ trên server, như trong CSDL dưới dạng các comment
trong blog, message trong forum hoặc các visitor log.
- Non-Persistent or Reflected Vulnerability: Tương tự như Stored XSS
nhưng đoạn mã khai thác sẽ không được lưu trữ trên server, nó thường được
thực hiện trên URL hay trong các form truyền dữ liệu.
- Dom-Based XSS là một dạng tấn công XSS làm thay đổi cấu trúc của
trang web bằng cách thay đổi cấu trúc HTML. Đối với loại tấn công này,
hacker sẽ chèn các đoạn script nhằm thay đổi giao diện mặc định của trang
web thành một giao diện giả.
Khác với SQL Injection tấn công vào CSDL của website, lỗ hổng XSS
cho phép tin tặc tấn công trực tiếp vào người truy cập website:
32
- Lừa đảo người sử dụng để lấy cắp cookies, chiếm session... từ đó có
thể chiếm phiên làm việc và mạo danh người sử dụng trên website. Nó đặc
biệt nguy hiểm với người quản trị website, nó có chiếm quyển điều khiển
website.
- Thực thi các đoạn mã độc được viết bằng 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, XSS đang 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.
Ví dụ: Ta có một đoạn code cho phép hiển thị tên người dùng như sau:
<?php
if ( isset( $_GET['name'] ) ) {
echo '<h1>'. $_GET['name'] .'</h1>';
}
?>
Thay vì nhập dữ liệu hợp lệ thông thường, kẻ tấn công nhập một đoạn
mã HTML hoặc script, ví dụ như sau:
http://localhost/XSS/index.php?name=<script>alert(document.cookie)</
script>
Khi đó, thay vì trình duyệt hiển thị dữ liệu như bình thường thì hệ
thống sẽ trả về hộp thoại có chứa cookie của người dùng.
Hình 1.6. Hộp thoại lỗ hổng XSS chứa cookie

33
Tương tự như cơ chế hoạt động của XSS, một biến có tồn tại lỗ hổng
XSS nếu như giá trị của biến đó được được thay đổi bằng các đoạn mã HTML
hay script, nếu nó được hiện ra trên trình duyệt hoặc trong mã nguồn HTML.
Để 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ư:
<script>[code]</script>
“><script>[code]</script>
“onmouseover=[code] foo=”
<img src="javascript:[code] ">
<img src="livescript:[code] ">
<div style="behaviour:URL([link to code]);">
<div style="binding: URL([link to code]);">
<div style="width: expression([code]);">
.....
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.
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ị cần encode
tất cả các giá trị được in ra. Khi đó đ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
[20]. Ví dụ:
- Trong ngôn ngữ PHP có hàm htmlentities(), htmlspecialchars(),...
Hàm này chuyển các thể html trong chuỗi truyền vào sang dạng thực thể của
chúng.
- Trong ngôn ngữ C# có hàm htmlEncode(). Hàm này có chức năng
tương tự như các hàm trong PHP.
- Trong ngôn ngữ JSP có ${specialCharString} để encode html tag.
1.2.2.3. Lỗ hổng Directory Listing
a. Khái quát
34
Directory Listing là lỗ hổng do cấu hình máy chủ sai hoặc thiếu các tệp
tin index, làm hiển thị danh sách các thư mục và tệp tin tồn tại trên hệ thống,
nó mang lại thông tin nhạy cảm cho kẻ tấn công [12].
Trong hosting hay máy chủ web, dữ liệu website được lưu trữ trong các
thư mục và làm một phần đường dẫn cho website. Khi người dùng thực hiện
truy cập đến một website, tức nó đang truy cập đến thư mục gốc chứa dữ liệu
của hệ thống web, nếu tồn tại các tệp tin mặc định của hệ thống như
index.html, index.php,... thì nó sẽ được hiển thị trước tiên. Tuy nhiên, nếu
không tồn tại các tệp tin mặc định và không có 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. Ví dụ:
Hình 1.7. Website bị lỗi Directory Listing

Phát hiện lỗ hổng này trên hệ thống bằng cách thực hiện việc truy cập
vào các thư mục của hệ thống. Cụ thể thực hiện truy cập vào các URL có kết
thúc bằng dấu “/” và kiểm tra mã trạng thái trả về của hệ thống. Trong mã
HTML trả có chứa các từ thể hiện nó liệt kê danh sách các thư mục và tệp tin
của thư mục đó như “Directory”, “Name”,... thì đồng nghĩa với việc hệ thống
tồn tại lỗi Directory Listing.
Để phòng tránh lỗi Directory Listing rất đơn giản, có thể thực hiện
bằng một trong các phương pháp sau:
- Hạn chế quyền truy cập của người dùng vào các thư mục và tệp tin
không cần thiết.
35
- Tạo một tệp tin chỉ mục mặc định trong mỗi thư mục (index,
default…)
- Tắt danh sách thư mục trong cấu hình web hoặc ứng dụng web theo
mặc định. Thêm một số tệp tin cấu hình như .htaccess trong Apache để hạn
chế.
1.2.2.4. Lỗ hổng File Inclusion
a. Khái quá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 [20].
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ã
- 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.
Ví dụ: Giả sử website lấy trang mà người dùng yêu cầu theo tên file. Ta
có đoạn mã như sau:
<?php $file = $_GET['page']; //Trang web sẽ hiển thị ?>
Với đường dẫn truy cập ban đầu như sau:
http://localhost /fi/?page=index.php
Với lỗ hổng này người sử dụng chỉ cần thay đổi index.php đường dẫn
sang các tên các file khác mà kẻ tấn công mong muốn. Ví dụ như:
http://localhost /fi/?page=../../../etc/passwd
Sau khi thực thi đường dẫn trên, kẻ tấn công sẽ thu được thông tin toàn
bộ tài khoản của người dùng trên máy chủ như hình dưới đây:
36
Hình 1.8. Kết quả sau tấn công lỗ hổng LFI
Hoặc kẻ tấn công có thể xem cả nội dung của file bằng cách thay đổi
đường dẫn như sau:
http://localhost/fi/?page=php://filter/convert.base64-encode/
resource=index.php
Với thay đổi đường dẫn như trên ta sẽ thu được một đoạn mã hóa
base64 của mã nguồn như sau:
PD9waHANCgkkZmlsZSA9ICRfR0VUWydwYWdlJ107IC8vVHJhbmcgd
2ViIHNlzIMgaGnDqsyJbiB0aGnMow0KPz4NCg==
Sau khi decode đoạn mã base64 này ta sẽ nhận được đoạn mã nguồn
gốc như ban đầu. Từ đó kẻ thể đọc được tất cả mã nguồn của website, đó là
điều vô cùng nguy hiểm.
Cơ chế phát hiện lỗi này là chúng ta sẽ thực hiện đưa các giá trị đường
dẫn của các tệp tin quan trọng của hệ thống, thực hiện phân tích mã trạng thái
và kết quả trả về để đánh giá website sự tồn tại lỗ hổng. Ví dụ:
../../../etc/passwd
37
../../../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.
Để 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.
File Inclusion là một lỗ hổng cực kỳ nghiêm trọng. Lỗ hổng này xảy ra
khi việc kiểm tra đầu vào không được chú trọng. Vì vậy, người lập trình cần
quản lý và kiểm duyệt chặt chẽ các giá trị trên các biến mà người dùng truyền
dữ liệu vào. Một số biện pháp như:
- Chỉ chấp nhận kí tự và số cho tên tệp tin được gọi. Lọc và chặn toàn
bộ kí tự đặc biệt không được sử dụng.
- Giới hạn API cho phép việc gọi các tệp tin từ một chỉ mục xác định
nhằm tránh directory traversal.
- Không 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.
- Hạn chế tới mức tối thiểu phải sử dụng các biến từ “User Input” để
đưa vào hàm include hay eval
Tấn công File Inclusion có thể nguy hiểm hơn cả SQL Injection do đó
thực sự cần thiết phải có những biện pháp khắc phục lỗ hổng này. Kiểm tra dữ
liệu đầu vào hợp lý là chìa khóa để giải quyết vấn đề.
1.2.2.5. Lỗ hổng do cấu hình mặc định
a. Khái quát
Là những lỗi thuộc về người lập trình hay người quản trị cấu hình một
số yếu tố mặc định hay đơn giản giúp cho kẻ tấn công có thể dễ dàng đoán ra
như cấu hì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 không thay đổi tài khoản, mật khẩu truy cập mặc định,...
Ví dụ: Một website có đường dẫn mặc định tới trang quản trị như:
38
http://www.domain.com/administrator/login.php
http://www.domain.com/manager/login.php
http://www.domain.com/admincp /login.php
...
Hay trang quản trị để tài khoản và mật khẩu mặc định như hình:
Hình 1.9. Minh họa lỗ hổng cấu hình mặc định
Để 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.
Để khắc phục lỗ hổng này rất đơn giản, một số biện pháp để phòng
tránh lỗ hổng này như sau:
- Cấu hình phân quyền và cấm truy cập tới các đường dẫn chứa các tệp
tin cấu hình của hệ thống.
- Đặt tài khoản, mật khẩu đủ dài và mạnh, sửa đổi tên đường dẫn tới
trang quản trị làm tin tặc không thể đoán hay thực hiện tấn công vét cạn.
- 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.
39
1.3. Kỹ thuật Fuzzing
1.3.1. Lịch sử
Fuzzing có nguồn gốc từ năm 1988, bởi giáo sư Barton Miller, tại Đại
học Wisconsin.
Ông cùng sinh viên của mình thực hiện một dự án mang tên “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. Dự án được thực
hiện bằng cách thử nghiệm tấn công hệ thống với các dữ liệu đầu vào không
hợp lệ, bất ngờ hoặc ngẫu nhiên ở các cấp độ khác nhau, nhằm nỗ lực để
khám phá các hành vi bất ngờ hoặc và thất bại của hệ thống, bao gồm: treo hệ
thống, không khẳng định mã, rò rỉ bộ nhớ... Dự án cũng cung cấp bộ gỡ lỗi và
công cụ để xác định nguyên nhân và thể loại của mỗi kết quả phát hiện.
Mã nguồn của công cụ, các dữ liệu kết quả thô đã được công bố công
khai để các nhà nghiên cứu khác có thể để tiến hành các thử nghiệm tương tự
với các phần mềm khác. Hiện nay, các kết quả nghiên cứu của dự án vẫn
được cập nhật tại địa chỉ: http://pages.cs.wisc.edu/~bart/fuzz/.
Năm 1991, các công cụ crashme đã được phát hành, được dùng để
kiểm tra độ tin cậy của hệ điều hành Unix bằng cách thực hiện lệnh máy ngẫu
nhiên. Trong năm 1995, một fuzzer có giao diện GUI đã được sử dụng để thử
nghiệm các công cụ, giao thức mạng và các API hệ thống thư viện.
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.
Năm 2012, Google đã công bố ClusterFuzz, một hạ tầng kỹ thuật
fuzzing dựa trên đám mây cho các thành phần bảo mật quan trọng của
các trình duyệt web Chromium . Nghiên cứu bảo mật có thể tải lên các
fuzzers riêng có và thu thập tiền thưởng lỗi nếu ClusterFuzz thấy một vụ tai
nạn với fuzzer tải lên.
Năm 2016, Microsoft đã công bố dự án Springfield, một dịch vụ thử
nghiệm Fuzzing dựa trên điện toán đám mây cho việc tìm kiếm an ninh lỗi
nghiêm trọng trong phần mềm.
Năm 2016, Google đã công bố OSS-Fuzz, một chương trình mã nguồn
mở được phát triển dựa trên 2 dự án ClusterFuzz và Springfield, cho phép
40
fuzzing liên tục phần mềm mã nguồn mở. Giúp cho các mã nguồn mở đảm
bảo an toàn, bảo mật.
Đến nay, không chỉ các hãng lớn thực hiện nghiên cứu mà còn có nhiều
dự án mã nguồn mở đã được phát triển và ứng dụng rộng rãi trong cộng đồng
người sử dụng.
1.3.2. Phân loại Fuzzing
Phân loại fuzzing có thể tùy thuộc vào bộ dữ liệu fuzz, mục tiêu
fuzzing hay phương pháp fuzzing,…
1.3.2.1. Phân loại theo dữ liệu fuzz
a. Kiểm thử mờ dựa trên đột biến
Kiểm thử mờ dựa trên đột biến (Mutation Based Fuzzing) hay còn gọi
là kiểm thử mờ câm (Dumb Fuzzing) là phương pháp kiểm thử mà dữ liệu
fuzz được biến đổi từ mẫu dữ liệu hợp lệ hiện có để tạo thành dữ liệu kiểm
thử cho mục tiêu fuzzing.
Một số đặc điểm đối với cách tiếp cận này [16]:
- Người thực hiện không cần có nhiều hiểu biết về cấu trúc của các yếu
tố đầu vào.
- Tính dị thường được thêm vào đầu vào hợp lệ hiện có có thể hoàn
toàn ngẫu nhiên hoặc theo một số chuẩn đoán về mặt kinh nghiệm.
- Dữ liệu cho thực hiện fuzzing hoàn toàn phụ thuộc vào các yếu tố đầu
vào được sửa đổi.
- Yêu cầu ít hoặc việc thiết lập thời gian đơn giản hoặc không cần thiết.
Một số công cụ cho phép thực hiện fuzzing theo phương pháp này:
Taof, GPF, ProxyFuzz, Peach Fuzzer...
b. Kiểm thử mờ dựa trên thế hệ
Kiểm thử mờ dựa trên thế hệ (Generation Based Fuzzing) hay còn gọi
là kiểm thử mờ thông minh (Smart Fuzzing) là phương pháp kiểm thử mà dữ
liệu fuzz được xây dựng mới hoàn toàn dựa trên các mô tả đặc điểm kỹ thuật,
định dạng của mô hình đầu vào.
Đối với cách tiếp cận này [16]:
- Trường hợp thử nghiệm được tạo ra từ một số mô tả về các định dạng:
RFC, các định dạng tài liệu.
41
- Tính dị thường được thêm vào mỗi điểm có thể có trong các đầu vào.
- Hỗ trợ kiến thức về giao thức nên cho kết quả tốt hơn so với fuzzing
ngẫu nhiên.
- Có thể mất thời gian đáng kể để thiết lập.
Công cụ để thực hiện: SPIKE, Sulley, Mu-4000,...
1.3.2.2. Phân loại theo OWASP
The Open Web Application Security Project (OWASP) là một dự án
phi lợi nhuận phát triển các dự án liên quan tới bảo mật ứng dụng Web hàng
đầu thế giới, tổ chức này đưa ra 2 cách phân loại khác về Fuzzing hỗ trợ cho
kiểm thử mờ các ứng dụng Web như sau:
a. Fuzzing đệ quy
Fuzzing đệ quy (Recursive Fuzzing) là phương pháp kiểm thử mà
Fuzzer thực hiện duyệt qua bộ dữ liệu fuzz được xây dựng dựa trên tất cả các
kết hợp của bộ chữ cái Alphabet.
Giả sử ta gởi một request là một chuỗi có dạng:
http://www.domain.com/2af8rb03
Nếu chọn "2af8rb03" như một một điểm đầu vào thì bộ dữ liệu fuzzing
là một tập các chuỗi của bảng chữ cái Alphabet và số hệ thập lục phân (a-z, 0-
9) thuộc loại fuzzing đệ quy. Như vậy, bộ dữ liệu fuzzing sẽ có 16 8 chuỗi và
fuzzer sẽ thực hiện các request có dạng như sau:
http://www.domain.com/00000000
.....
http://www.domain.com/9999ffff
.....
http://www.domain.com/ffffffff
b. Fuzzing thay thế

Fuzzing thay thế (Replacive Fuzzing) là quá trình fuzzing mà một phần
của yêu cầu được thực hiện thông qua việc thay thế nó bằng một tập giá trị
mờ. Giá trị này được hiểu như một fuzz vector [16].
Xét trường hợp này:
42
http://www.example.com/2af8rb03
Để thực hiện kiểm tra sự tồn tại của lỗ hổng Cross Site Scripting
(XSS), fuzzer thực hiện kiểm thử bằng cách gửi đến server các fuzz vector
như sau:
http://www.example.com/>"><script>alert("XSS")</script>&
http://www.example.com/'';!--"<XSS>=&{()}
Các fuzz vector được xây dựng dựa trên các mô tả về loại lỗ hổng cần
kiểm thử. Tổng số lượng request mà fuzzer cần phải thực hiện phụ thuộc vào
số lượng các fuzz vector xác định.
1.3.3. Ưu nhược điểm của Fuzzing
1.3.3.1. Ưu điểm
Như bất kỳ kỹ thuật kiểm thử an toàn nào khác, kiểm thử Fuzzing có
ưu và nhược điểm của nó. Một trong những điểm mạnh của kiểm thử Fuzzing
là các loại điểm yếu an toàn trong mã nguồn mà nó xác định được thường rất
nghiêm trọng trong ứng dụng. Ví dụ, như tràn bộ đệm, lỗi số học số nguyên
hay SQL injection, đều là những lỗ hổng cho phép một người sử dụng ác ý có
thể nắm quyền kiểm soát hoàn toàn của một ứng dụng [7].
Những ưu điểm của kiểm thử fuzzing:
- Kết quả sử dụng kiểm thử Fuzzing hiệu quả hơn khi sử dụng các
phương pháp kiểm thử khác. Kiểm thử Fuzzing tập trung vào việc sử dụng
các giá trị đặc biệt như là đầu vào cho ứng dụng được kiểm thử, do đó giúp
việc phát hiện các lỗi quan trọng mà có thể không được phát hiện bằng
phương pháp tiếp cận dựa trên mô hình.
- Kiểm thử Fuzzing chỉ theo dõi các trường hợp mà kết quả trả về có sự
bất thường hay hành vi không mong muốn. Điều này giúp nó có khả năng
chạy hàng nghìn trường hợp thử nghiệm.
- Là một loại kiểm thử hộp đen nên có thể thực hiện kiểm thử cho các
ứng dụng không biết mã nguồn bên trong, vì vậy nó thường tìm ra được các lỗ
hổng nghiêm trọng và hầu hết là những lỗ hổng mà tin tặc thường khai thác.
- Các quá trình Fuzzing thường có lượng đầu vào thử nghiệm rất lớn,
độ bao phủ rộng nên hiệu quả trong việc tìm kiếm các lỗ hổng.
43
1.3.3.2. Nhược điểm
Bên cạnh những ưu điểm giúp cho fuzzing được trở nên ưa chuộng thì
nó cũng tồn tại những hạn chế:
- Khó có thể kiểm thử toàn diện và tìm thấy được tất cả các lỗi trong
một chương trình lớn, những lỗi đòi hỏi kiểm thử viên phải thực hiện phân
tích tĩnh.
- Fuzzing nằm trong phương pháp kiểm thử hộp đen nên không cung
cấp nhiều kiến thức về hoạt động nội bộ của các phần mềm, vì vậy khó có thể
tìm hiểu triệt để mà không hiểu chi tiết.
- Với chương trình có các đầu vào phức tạp để tìm ra các lỗi đòi hỏi
phải tốn nhiều thời gian, bởi với mỗi biến đang fuzzing phải thử N vector fuzz
và phải tạo ra một fuzzer đủ thông minh để phân tích các kết quả trả về.
- Fuzzing hoạt động không hiệu quả trong các chương trình có các kết
quả trả về không có các mã lỗi hay các dấu hiệu bất thường.
1.4. Lựa chọn Fuzzing cho kiểm tra lỗ hổng website
Trong kiểm thử bảo mật website và kiểm thử bảo mật phần mềm không
có quá nhiều điểm khác nhau nhưng đòi hỏi kiểm thử viên phải kết hợp với
các kiến thức công nghệ bảo mật web, công nghệ mạng, lập trình web và kinh
nghiệm thực tế về thâm nhập các hệ thống server. Vì vậy để xây dựng ứng
dụng tự động phát hiện lỗ hổng bảo mật cho website, đòi hỏi phải có một
phương pháp kiểm thử và phân tích đặc thù cho từng loại lỗ hổng trong bảo
mật web.
Hiện nay, fuzzing là kỹ thuật được sử dụng rất 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
website dịch vụ. Ngoài ra, fuzzing là một trong những phương pháp phổ biến
nhất được hacker sử dụng để tìm lỗ hổng của hệ thống.
Hệ thống Fuzzing sẽ gửi dữ liệu fuzz lên server chứa website hoặc truy
cập thẳng vào đường link của website kèm theo dữ liệu gây lỗi, nhận dữ liệu
từ website trả về và đưa vào bộ phân tích trước khi đưa ra kết luận về lỗ hổng.
Dữ liệu fuzz là một tập hợp chứa dữ liệu nhận dạng, được kết hợp với một số
thành phần của URL hoặc với những dữ liệu mà website xử lý.
Lựa chọn kỹ thuật Fuzzing, kiểm thử hộp đen để xây dựng ứng dụng
quét lỗ hổng website, ta có thể quét bất kỳ một trang web hoặc một ứng dụng
44
web, không phụ thuộc vào công nghệ hoặc các ngôn ngữ lập trình mà nó sử
dụng. Nó chủ yếu kiểm thử một trang web hoặc một ứng dụng web mà không
cần bất kỳ kiến thức về cách mà trang web làm việc, giống một kẻ tấn công
thực sự. Nên khi 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 hoặc những người kiểm thử web sử dụng
phương pháp này để kiểm thử sẽ giúp chương trình ngăn chặn trước được tấn
công từ hacker.
Trong phạm vi đồ án, tôi sẽ đi sâu vào phân tích kỹ thuật fuzzing đặc
thù cho việc kiểm tra, phát hiện lỗ hổng bảo mật ứng dụng web.
1.5. Kết luận chương 1
Chương đầu tiên đã trình bày toàn bộ cơ sở lý thuyết có liên quan tới
website và kiểm thử website. Các nội dung này đã làm rõ và đưa ra được vấn
để nghiên cứu của toàn bộ đồ án, đó là lỗ hổng bảo mật website và kỹ thuật
Fuzzing trong phát hiện các lỗ hổng bảo mật.
Những nội dung chính mà chương 1 trình bày:
- Mục 1.1, trình bày các khái niệm cơ bản có liên quan như website, lỗ
hổng bảo mật, kiểm thử, fuzzing,.. Đây là các khái niệm cơ tạo nền tảng ban
đầu cho các nghiên cứu và phát triển đồ án.
- Các loại lỗ hổng website, phần này đã trình bày về việc phân loại các
lỗ hổng website, cách phát hiện và phòng chống với từng loại lỗ hổng. Đây là
những đặc trưng phát hiện lỗ hổng cho việc xây dựng phần mềm. Phần này sẽ
được nêu chi tiết trong chương 2.
- Kỹ thuật Fuzzing, phần này đã trình bày khái quát về lịch sử, phân
loại và ưu nhược điểm của kỹ thuật Fuzzing trong kiểm thử bảo mật.
Từ những nội dung trình bày ở trên tôi đã trình bày lý do lựa chọn kỹ
thuật Fuzzing cho các nghiên cứu trong kiểm thử bảo mật website. Các nội
dung này là cơ sở lý thuyết cho việc nghiên cứu áp dụng kỹ thuật Fuzzing với
các lỗ hổng web trong chương 2.
45
Chương 2
KỸ THUẬT FUZZING TRONG
KIỂM TRA LỖ HỔNG BẢO MẬT WEBSITE
Chương này trình bày chi tiết về kỹ thuật Fuzzing trong phạm vi kiểm
tra và phát hiện lỗ hổng bảo mật của website. Trong phần đầu của chương
này trình bày về mô hình và quy trình fuzzing trong kiểm thử bảo mật web. Từ
đó, các phần tiếp thep trình bày chi tiết về kỹ thuật fuzzing trong một số giai
đoạn quan trọng của quy trình bao gồm: phương pháp thu thập điểm đầu
vào, nguyên lý chèn dữ liệu fuzz và các phương pháp phát hiện lỗ hổng bảo
mật. Đây là các giai đoạn quyết định tới hiệu quả của cả quá trình fuzzing
trong phát hiện lỗ hổng bảo mật, tạo cơ sở cho việc xây dựng ứng dụng tại
chương 3.
2.1. Mô hình Fuzzing cho ứng dụng website
2.1.1. Mô hình Fuzzing
Một ứng dụng web thao tác với người dùng qua trình duyệt và sử dụng
giao thức HTTP cổng 80 hoặc HTTPS cổng 443. Một hệ thống website sẽ
chứa các điểm đầu vào của hệ thống bao gồm: các form cho người dùng nhập
dữ liệu, các giá trị của biến được truyền trên các URL của website, các trường
thông tin trong HTTP Headers [15].
Quá trình kiểm thử chủ yếu được thực trên các điểm đầu vào của hệ
thống, cụ thể các trường dữ liệu của request headers được gửi qua phương
thức truyền dữ liệu của HTTP, chủ yếu là phương thức GET, POST. Fuzzer
sẽ phải thực hiện việc thu thập toàn bộ các điểm đầu vào của hệ thống trước
khi thực hiện fuzzing. Mô hình được mô tả như hình 2.1:
46
Hình 2.10. Mô hình Fuzzing cho ứng dụng web
Mô hình kiểm thử fuzzing cho website cũng tương tự như mô hình
fuzzing trong kiểm thử phần mềm, có 2 thành phần chủ yếu là fuzzer và web
server:
- Fuzzer là chương trình thực hiện kiểm thử tự động bằng kỹ thuật
fuzzing.
- Web server là hệ thống máy chủ web được fuzzer thực hiện kiểm thử.
Với mỗi loại lỗ hổng website sẽ có những dữ liệu fuzz để thực hiện
nhận dạng cho các ứng dụng đó, cụ thể chính là giá trị được thêm vào các
biến trước khi gửi tới hệ thống. Việc phân tích các Response trả về cũng được
thực hiện dựa trên các đặc điểm của từng loại hệ thống Web Server có mã
nguồn website được xây dựng trên loại ngôn ngữ lập trình nào.
2.1.2. Quy trình Fuzzing trong kiểm thử bảo mật website
Tùy thuộc vào các nhân tố khác nhau, việc lựa chọn cách tiếp cận
Fuzzing có thể khác nhau. Tuy nhiên, về cơ bản Fuzzing có các giai đoạn như
sau:
Hình 2.11. Quy trình Fuzzing

Các giai đoạn của Fuzzing được mô tả như sau:
1. Xác định mục tiêu
Mục tiêu được đánh giá có nguy cơ rủi ro cao gồm 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
47
Scripting, URL Redirect… Hoặc 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…
Fuzzer cần có đầu vào là địa chỉ IP hay domain của website cho việc
xác định đối tượng fuzzing.
2. Xác định vị trí đầu vào
Một ứng dụng web nhận các yêu cầu, dữ liệu từ người dùng thông qua
các URL hoặc trường biểu mẫu. Các yêu cầu của người dùng được chuyển
thành các gói tin theo giao thức HTTP và đưa tới Web Server. Các trường
trong phần tiêu đề của gói tin sẽ được chèn dữ liệu fuzzing.
Fuzzer thực hiện cuộc thử nghiệm thông qua phần tiêu đề khác nhau
của giao thức HTTP của website đó, do vậy, việc thực hiện thu thập được
toàn diện các điểm đầu vào là các URL, trường biểu mẫu giúp cho Fuzzer đi
vào được các ngóc ngách của website và thực hiện fuzzing.
3. Sinh dữ liệu Fuzz
Mục tiêu của fuzzing là cung cấp dữ liệu bất thường thông qua đầu vào
cho mục tiêu mà nó thường không mong đợi nhận được.
Giai đoạn này được xem là quan trọng nhất trong fuzzing. Ngày nay,
nó được nghiên cứu và phát triển đáng kể bởi các nhà khoa học. Mục đích của
một fuzzer là để kiểm tra sự tồn tại của lỗ hổng bảo mật trên các đầu vào của
ứng dụng. Do đó, fuzzer phải tạo ra dữ liệu thử nghiệm mà ở các mức độ mà
sau đó nó có thể được thông qua vào mục tiêu ứng dụng đầu vào. Dữ liệu
được tạo ra có thể dạng file nhị phân (Binary files), file văn bản (Text files)
được tạo ra lặp đi lặp lại vào thời điểm bắt đầu của mỗi lần test [16].
Toàn bộ phạm vi của dữ liệu thử nghiệm tạo ra cho fuzzing ứng với
một mục đích nhất định, nó bao gồm nhiều trường riêng biệt (gọi là test case).
Các cách tiếp cận chung để kiểm tra là để nó lặp đi lặp lại, cung cấp các
trường hợp thử nghiệm vào các mục tiêu và theo dõi các phản ứng. Trong
suốt quá trình kiểm thử, một test case được sử dụng để tìm ra các phản ứng
bất thường của ứng dụng, sự kết hợp của một trường hợp thử nghiệm cụ thể
và thông tin về bản chất của sự bất thường tạo ra một báo cáo về lỗ hổng. Báo
cáo lỗ hổng có thể được coi như là đầu ra của fuzzing, tạo điều kiện thuận lợi
cho các nhà phát triển trong quá trình khắc phục [16].
48
Các dữ liệu kiểm thử được tạo ra là một tập hợp các quy tắc hoặc các
luật, thông thường là được xác định bởi người sử dụng hoặc do chuyên gia đề
xuất.
Hiệu quả của quá trình kiểm thử phụ thuộc bộ dữ liệu đầu vào:
- Độ bao phủ không gian đầu vào: Không gian đầu vào của bộ dữ liệu
fuzz cho kiểm thử càng rộng thì hiệu quả đạt càng cao.
- Chất lượng của dữ liệu đầu vào: Các dữ liệu đầu vào độc hại tiêu biểu
và dị hình sẽ làm sẽ là tăng cường khả năng kiểm thử đối với các yếu tố hoặc
cấu trúc trong định nghĩa giao diện.
4. Chèn dữ liệu fuzz và thực thi các truy vấn
Server nắm bắt dữ liệu từ tiêu đề được gửi bởi khách hàng để thực hiện
một số nhiệm vụ ở phía máy chủ. Các dữ liệu lần lượt được chèn vào các
trường phần tiêu đề của HTTP Request.
Các trường tiêu đề sau đây có thể được chèn dữ liệu fuzz:
- Query parameters
- Path
- Accept language
- Cookie
- User-Agent
- POST Data
Ví dụ, ứng dụng sẽ dựa vào giá trị user-agent là admin hay user để
quyết định nội dung sẽ được chuyển lại cho người dùng. Nếu ứng dụng không
thực hiện xác nhận hợp lệ đầu vào chuỗi user-agent, nó có thể bị kẻ tấn công
khai thác.
Sau khi tham số đầu vào và dữ liệu fuzzing đã sẵn sàng, đó là lúc để
gửi nó tới đích.
5. Theo dõi và ghi chép
Khi bộ fuzzer bắt đầu fuzzing, fuzzer theo dõi mục tiêu và đợi cho ứng
dụng gặp phải tình trạng lỗi hay phản ứng bất thường do những dữ liệu không
thích hợp được truyền đến. Tình trạng lỗi và dữ liệu gây ra lỗi sẽ được ghi lại.
49
Dựa vào các thông báo lỗi được phản hồi lại bởi ứng dụng và mã
HTTP. Mã trạng thái 403 chỉ ra rằng tài nguyên mà bạn đang cố gắng truy cập
bị hạn chế và bạn không được phép xem nó, mã lỗi 404 nói rằng trang web
bạn đang cố gắng truy cập không khả dụng và mã lỗi 500 cho biết lỗi máy chủ
nội bộ.
6. Phân tích và khai thác
Giai đoạn này, không đơn thuần các fuzzers phát hiện các lỗ hổng qua
việc fuzzing mà phải định nghĩa các lỗ hổng được phát hiện. Điều này có ý
nghĩa hết sức quan trọng trong việc phân tích và báo cáo lỗ hổng. Để báo cáo
lỗ hổng đòi hỏi Fuzzer hiểu rõ về hoạt động xử lý và được tích hợp vào sự
kiện phân loại lỗ hổng tự động.
Ứng dụng web sẽ phản hồi lại với các thông báo lỗi của ứng dụng như
thông báo lỗi SQL cho lỗ hổng SQL Injection, các đặc trưng của dữ liệu fuzz
trong lỗ hổng XSS, truy nhập thành công cho lỗ hổng LFI,... Bằng cách sử
dụng này, Fuzzer căn cứ vào những đặc trưng quy định trước mà phát hiện lỗ
hổng.
2.2. Thu thập các điểm đầu vào
Để có thể kiểm thử và phát hiện các lỗ hổng của hệ thống, fuzzer cần
xác định được các điểm đầu vào của hệ thống. Các điểm đầu vào thường là
các đường dẫn, các form nhập dữ liệu của hệ thống và các thông tin trên các
trường của header của gói tin HTTP.
Từ tập hợp các điểm đầu vào của website, fuzzer mới có thể thực hiện
kiểm tra và phát hiện các lỗ hổng tồn tại trên hệ thống.
2.2.1. Cơ chế trích xuất URL từ mã HTML
HTML là ngôn ngữ cho giao diện của website, chúng đánh dấu bằng
thẻ (tag) và sử dụng các thẻ khác nhau để định dạng nội dung của một trang
web. Những thẻ này được chứa trong hai dấu ngoặc đơn <tên thẻ>. Ví dụ,
thẻ <html> có thẻ đóng tương ứng là </html> và thẻ <body> có thẻ đóng
tương ứng là </body> ...
Thu thập thông tin (web crawler) là quá trình lấy thông tin từ website,
trích xuất ra những thông tin người sử dụng cần, đồng thời cũng tìm những
liên kết có trong trang web đó và tự động truy cập vào những đường dẫn đó.
Nó lần lượt đi từ liên kết này đến các liên kết khác và thu thập tất cả các dữ
liệu của toàn bộ website.
50
Nguyên lý thu thập các điểm đầu vào của website cũng tương tự như
vậy, nó là quá trình thu thập các URL và form nhập dữ liệu dựa trên việc phân
tích các mã HTML trả về sau mỗi yêu cầu. Đơn giản nó là quá trình bóc tách
từng thẻ trong mã HTML trả về để tìm các URL của website trong đó.
Quá trình thu thập đầu vào dựa trên các thuộc tính và thẻ trong HTML,
danh sách các thuộc tính này được đưa ra trong bảng 2.1:
Bảng 2.6. Các thuộc tính và các thẻ đi kèm có chứa các URL của hệ thống
Thuộc tính Các thẻ có chứa thông tin URL
Nằm trong mã HTML. Các thẻ mà chứa thuộc tính href thì giá
href
trị của href chính là một URL.
src Nằm trong mã HTML, mã javascript.
Nằm trong mã HTML, giá trị của biến có chứa site là một đường
site
dẫn.
action Nằm trong mã HTML, nằm trong thẻ <form>.
location Nằm trong mã Javascript.
http:// Có chứa thông tin “http://” cũng xác định đường dẫn.
Thu thập các form trong các thẻ <form> của mã HTML, các thẻ
<input> có các thuộc tính name trong form là các biến mang giá trị đầu vào
cho liên kết trong thuộc tính action.
Với javascript, thực hiện tìm kiếm các liên kết dựa trên biểu thức chính
quy (Regular Expression).
Ví dụ: Ta có đoạn mã HTML khi truy cập vào tệp tin login.php trên
đường dẫn http://www.domain.com/login.php như sau:
<form action="xacthuc.php" method="post">

<input type="text" placeholder="Tài khoản" name="taikhoan">
<input type="password" placeholder="Mật khẩu" name="matkhau">
<button type="submit" name="login"> Đăng nhập </button>
51
</form>
Với đoạn mã HTML như trên, fuzzer cần trích xuất các liên kết tồn tại
trong đoạn mã này. Căn cứ dựa trên các thuộc tính của mã HTML, các liên
kết này bao gồm:
- URL: Với thẻ <form> và thuộc tính action, dữ liệu trong form được
gửi tới tệp tin xacthuc.php thực hiện quá trình xác thực, tệp tin này nằm
ngang với tệp tin login.php trong thư mục gốc. Như vậy fuzzer cho kết quả
một liên kết là http://www.domain.com/login.php.
- Form POST: Fuzzer thu thập dựa trên các thuộc tính của form dựa
trên các thẻ <input>, các biến truyền dữ liệu cho form post là taikhoan,
matkhau, login.
Fuzzer cần chuyển các URL tương đối sang các địa chỉ URL tuyệt đối
sử dụng URL cơ sở của trang web nơi chúng được trích ra. Các URL khác
nhau tương ứng với cùng một trang web có thể được ánh xạ vào một dạng
chuẩn đơn nhất. Điều này rất quan trọng nhằm tránh được việc nạp cùng một
trang web nhiều lần .
2.2.2. Phương pháp thu thập
2.2.2.1. Web crawler
Web crawler là các chương trình khai thác sơ đồ cấu trúc của web bằng
cách chuyển từ trang web này sang trang web khác.
Ban đầu, động cơ chủ yếu thúc đẩy việc thiết kế các web crawler là
việc lấy ra nội dung các trang web và thêm chúng hoặc thể hiện của chúng
vào các kho chứa cục bộ. Các kho chứa này, sau đó sẽ đáp ứng các ứng dụng
cụ thể chẳng hạn một hệ thống tìm kiếm trên Web. Ở dạng đơn giản nhất, một
chương trình crawler sẽ bắt đầu từ một địa chỉ nguồn khởi đầu nào đó và sử
dụng các liê n kết ngoài trong trang web đó để mở rộng ra các trang tiếp theo.
Quá trình này tiếp tục với các trang web mới, các trang này lại cung cấp các
liên kết ngoài khác để đi theo. Cứ như vậy cho tới khi đạt tới một số lượng
trang web xác định hoặc một mục tiêu nào đó đạt được. Phía sau sự mô tả một
cách đơn giản này là một mảng các vấn đề phức tạp có liên quan như việc kết
nối mạng, các tiêu chuẩn về một URL, việc duyệt các trang HTML và cách
thức để giao tiếp với các Server ở xa. Trên thực tế, các thế hệ web crawler gần
52
đây, có thể coi là một trong những phần phức tạp nhất của hệ thống mà nó đi
kèm [2].
Hình 2.3 biểu diễn đồ thị của một crawler tuần tự cơ bản. Một chương
trình crawler bao gồm một danh sách các URL chưa được thăm gọi là hàng
đợi URL. Danh sách này được khởi tạo bởi các URL hạt nhân đã được cung
cấp bởi người dùng hoặc các chương trình khác. Mỗi vòng lặp crawling bao
gồm:
- Lấy ra URL cần được duyệt tiếp theo từ hàng đợi URL, nạp trang web
tương ứng với URL đó bằng giao thức HTTP.
- Duyệt trang web vừa tải về để lấy ra các từ URL và các thông tin mà
ứng dụng cần.
- Cuối cùng, thêm các trang URL chưa được thăm vào hàng đợi URL
và thực hiện vòng lặp tiếp theo.
Trước khi các URL được thêm vào frontier chúng sẽ được gán cho một
độ đo thể hiện đánh giá hiệu quả khi thăm trang web tương ứng với URL đó.
Quá trình crawling có thể kết thúc khi một số lượng nhất định các trang
web đã được tải. Nếu chương trình crawler đã sẵn sàng để duyệt một trang
web khác và trạng thái của frontier là rỗng, một tín hiệu trạng thái kết thúc
(dead-end) sẽ được gửi cho crawler. Chương trình crawler sẽ không có trang
web mới để tải và nó sẽ dừng lại [2].
53
Hình 2.12. Sơ đồ của một crawler
Quá trình crawling sẽ kết thúc trong hai trường hợp:
- Khi đạt điều kiện dừng đã đặt ra, điều kiện có thể là: số lượng các
trang web được tải về đã đáp ứng được yêu cầu đặt ra, đã thu thập được thông
tin cần thiết.
- Hàng đợi URL tại hàng đợi URL rỗng, không tồn tại URL yêu cầu
crawler phải thực hiện tải về. Trong một số trường hợp bộ lọc URL chưa xử
lý kịp thời làm cho các URL mới chưa được chuyển kịp tới hàng đợi URL,
trong khi đó hàng đợi URL đang rỗng thì sẽ gây ra tình trạng không xử lý hết,
vì vậy cần phải có một thời gian trễ cho frontier chờ đợi các URL được
chuyển tới.
Công việc crawling có thể được xem như một bài toán duyệt đồ thị.
Toàn bộ thế giới Web được xem như một đồ thị lớn với các nút là các trang
54
web và các liên kết là các đường đi (cạnh). Một crawler bắt đầu tại một vài
nút hạt nhân và sau đó đi theo các cạnh để tới các nút khác. Quá trình tải một
trang web và trích ra các liên kết trong nó tương tự như việc mở rộng một nút
trong bài toán tìm kiếm trên đồ thị. Một crawler có chủ điểm cố gắng đi theo
các cạnh mà được kỳ vọng là dẫn tới các vị trí trong đồ thị là hợp lệ với chủ
điểm đó [2].
2.2.2.2. Quy trình thu thập điểm đầu vào
Một chương trình Fuzzer cần phải có tập hợp các điểm đầu vào (nơi
thực hiện chèn dữ liệu fuzz) để phục vụ cho quá trình fuzzing và tìm kiếm lỗ
hổng. Dựa trên mô hình web crawler, nguyên tắc thu thập toàn bộ các điểm
đầu vào của một website cũng như vậy, hay nói cách khác Crawler là một
phần của Fuzzer nhưng dữ liệu cần thu thập không chỉ URL mà cần thu thập
các biến và dữ liệu truyền trên mỗi đường dẫn đó.
Ban đầu Fuzzer thực hiện duyệt trang web với URL gốc, sau khi trang
web đã được tải về, Fuzzer duyệt nội dung của nó để lấy ra các thông tin sẽ
được nạp trở lại và giúp định hướng việc đi theo các đường dẫn tiếp theo.
Việc duyệt nội dung đơn giản chỉ bao hàm việc trích ra các URL mà trang
web chỉ tới hay có thể bao gồm các bước để chuẩn hóa các URL được lấy ra.
- Input: Đường dẫn gốc của website (http://www.domain.com).
- Output: Toàn bộ các liên kết trong website (danh sách URL cuối).
Mô hình thu thập URL theo mã HTML được mô tả như trong hình 2.3
dưới đây:
55
Hình 2.13. Mô hình thu thập URL theo mã HTML
Hàng đợi URL là một hàng đợi chứa danh sách các trang web chưa
được thăm hay nó là một danh sách chứa các nút chưa được mở rộng. Chúng
được lưu trữ như là các cấu trúc dữ liệu trong bộ nhớ trong. Hàng đợi này có
kích thước giới hạn nên cần một cơ chế để quyết định URL nào cần bị loại bỏ
khi số lượng trong hàng đợi này đạt tới giới hạn và nó có thể bị đầy nhanh
hơn so với số lượng trang web được duyệt. Với số lượng ước tính trung bình
có khoảng 7 đến 10 liên kết trong một trang web thì việc hàng đợi có thể bị
đầy nhanh hơn là điều dễ hiểu. Do vậy, điều cần thiết là phải đảm bảo rằng
không thêm các url lặp lại vào hàng đợi, cần có một cơ chế tìm kiếm và trích
xuất các URL mới trong nội dung trang web đang được duyệt.
Tại một thời điểm, chương trình có thể gặp vấn đề thu được một số
lượng lớn các URL khác nhau nhưng chúng cùng trỏ về một trang web. Có
thể giải quyết vấn đề này bằng cách loại bỏ các trang web không nằm trên
một tên miền xác định. Điều này đảm bảo rằng mọi chuỗi gồm k URL liên
tiếp được lấy ra thì chỉ trích xuất một địa chỉ URL chuẩn hóa. Điều này sẽ
56
tránh được việc phải truy cập và lấy nội dung một trang web quá nhiều lần và
nội dung các trang web được tải có xu hướng khác biệt nhau.
Để thu được nội dung trang web, cần phải gửi một yêu cầu HTTP tới
trang web yêu cầu và đọc các đáp ứng. Fuzzer cần phải có một thời gian quy
định trước để tránh cho việc lãng phí quá nhiều thời gian để thực hiện truy
cập tới máy chủ web có độ trễ cao hay kích thước nội dung web quá lớn. Trên
thực tế, chương trình cần phải loại bỏ các tệp tin không liên quan có nội dung
như ảnh, nhạc,... Chúng cũng duyệt các header để lấy mã trạng thái của trang
web và lưu thời gian trễ để xác định thời gian cập nhật của website.
Các bước thu thập URL một hệ thống website theo mô hình 2.4:
- Bước 1: Khởi tạo hàng đợi với 1 phần tử là URL gốc. Khởi tạo danh
sách URL cuối để lưu các URL cuối cùng của hệ thống.
- Bước 2: Fuzzer thêm vào URL gốc /robots.txt, /sitemap.xml,... và đưa
vào hàng đợi. Thực hiện việc lấy URL từ hàng đợi và gửi yêu cầu đến web
server.
- Bước 3: Phân tích mã HTML trả về từ Server và lọc lấy URL trong
các thuộc tính của các thẻ trong mã HTML.
- Bước 4: Nhận URL thu được từ bước 3 và thực hiện kiểm tra (URL
check) như sau:
+ Đưa vào trong hàng đợi nếu URL này không trùng hoặc tương đương
với URL nào trong các URL đã duyệt và các URL trong hàng đợi.
+ Đưa vào trong danh sách URL cuối nếu URL này không trùng hoặc
tương đương với URL nào trong danh sách các URL đã thu được (danh sách
URL cuối).
+ Loại bỏ trong các trường hợp còn lại.
- Bước 5: Kiểm tra nếu hàng đợi rỗng thì kết thúc. Nếu hàng đợi không
rỗng thì quay lại B2.
Mô hình được xây dựng đã dẫn tới một số vấn đề và điều đó cần thiết
phải có các giải pháp nhằm giải quyết các vấn đề trong quá trình hoạt động
của chương trình:
1. Thời gian giới hạn: Nếu server không trả lời thì chương trình sẽ bị
đóng băng. Vì thế Fuzzer cần xử lý trường hợp máy chủ web không trả lời sau
1 khoảng thời gian quy định bằng cách đơn giản là quy định thời gian chờ.
57
2. Truy cập lặp lại: Xảy ra khi fuzzer thực hiện gửi yêu cầu lặp lại trang
web đã được xử lý trước đó, chương trình có thể bị rơi vào vòng lặp vĩnh
viễn. Vì thế cần phải có phương pháp đánh dấu những liên kết đã xử lý. Đơn
giản nhất là lưu lại liên kết đã xử lý, trước khi thêm vào hàng đợi một liên kết
mới thì so sánh với những liên kết đã xử lý trước.
3. Bỏ sót đường dẫn: Với việc chỉ một đường dẫn gốc duy nhất làm cho
việc quét khó khăn hơn hoặc bỏ sót các đường dẫn mà nó không liên kết với
đường dẫn ta đang có. Vì vậy, Fuzzer phải thực hiện mở rộng đường dẫn gốc
bằng cách lấy các cấu trúc thư mục tại các tệp tin mặc định của website:
robots.txt, sitemap.xml,...
Tệp tin robots.txt chứa các thư mục và tệp tin mà website quy định cho
phép hay cấm các chương trình (bot) của các công cụ tìm kiếm đánh chỉ mục
một khu vực nào đó trong website. Nguyên tắc này cung cấp cho các nhà
quản trị web thông báo về quyền truy nhập tệp tin trên máy chủ. Nó cung cấp
các chính sách truy cập cho các User-agent khác nhau. Vì vậy ta có thể lấy
các đường dẫn tương ứng thông qua việc phân tích mã nguồn của tệp tin
robots.txt.
Sitemap (còn được gọi là sơ đồ của một trang web) là một tập tin văn
bản có chứa tất cả các URL của một trang web. Sitemap còn có thể chứa các
siêu dữ liệu về mỗi URL thông báo sẽ được gửi đến cho bạn khi nó mới được
cập nhật.
Hình 2.14. Các đường dẫn từ tệp tin robots.txt
58
4. Đường dẫn tương đương: Liên tục truy xuất tới tất cả các đường dẫn
tương tự nhau mà chỉ khác giá trị truyền vào của biến trên đường dẫn. Điều
này làm tăng số lượng yêu cầu gửi không cần thiết.
Cấu trúc một đường dẫn:
http://buigiap.com/path1/index.php?a=1&b=2#endpage
Giao Tên miền Cổng Đường dẫn Truy vấn Phân

thức mảnh
http buigiap.com 80 path1/index.php var1=a & endpage

var2=b
Đường dẫn tương đương là các đường dẫn hoàn toàn giống nhau về các
thành phần trên nó mà chỉ khác về các giá trị được truyền vào. Phần truy vấn
và phân mảnh là khác nhau, tuy nhiên trong phần truy vấn các biến là giống
nhau. Trong quá trình fuzzing, điều này giúp làm tránh các trường hợp kiểm
thử các đường dẫn cùng mang lại một kết quả như nhau.
Fuzzer cần phải có bước kiểm tra xem trong danh sách URL cuối xem
có tồn tại URL tương đương của nó không, nếu không tồn tại thì mới thực
hiện việc thêm URL này vào URL cuối. Ví dụ xét 2 đường dẫn như sau:
Liên kết 1:
http://www.domain.com/index.php?var1=1&var2=abc#endpage
Liên kết 2:
http://www.domain.com/index.php?var1=2&var2=cde#endpage
Đây là 2 đường dẫn tương đương bởi có các thành phần giống nhau về
giao thức, tên miền, đường dẫn và các biến.
Trong quá trình kiểm thử, fuzzer thực hiện chèn dữ liệu fuzz vào các
biến trên đường dẫn, nên với các đường dẫn tương đương sau khi chèn dữ liệu
fuzz thì chúng hoàn toàn giống nhau và kết quả cho cuộc tấn công kiểm thử là
như nhau. Vì vậy, việc lọc và loại bỏ các đường dẫn tương đương là hết sức
cần thiết trong quá trình thực hiện fuzzing.
Một số ví dụ về việc lọc và loại bỏ đường dẫn tương đương khi thực
hiện fuzzing được trình bày chi tiết trong bảng 2.2:
59
Bảng 2.7. Ví dụ trong fuzzing đường dẫn tương đương
URL Nội dung đường dẫn
URL1 http://www.domain.com/index.php?var1=1
Fuzzing 1 http://www.domain.com/index.php?var1=[Fuzz]
URL4 http://www.domain.com/index.php?action=home&var1=1
URL5 http://www.domain.com/index.php?action=news&var1=2
URL6 http://www.domain.com/index.php?action=main&var1=3
Fuzzing 2 http://www.domain.com/index.php?action=[Fuzz]&var1=[Fuzz]
Với các đường dẫn tương đương chúng được thay thế như sau:
(URL1, URL2, URL3) => Fuzzing 1
(URL4, URL5, URL6) => Fuzzing 2
Việc loại bỏ các đường dẫn tương đương giúp cho quá trình kiểm thử
website giảm thời gian đáng kể và giảm tổn hao tài nguyên của hệ thống.
2.3. Nguyên lý chèn dữ liệu fuzz
2.3.1. Chèn dữ liệu vào phương thức GET
Đường dẫn (URL) có 2 loại chính:
- Loại 1: URL có chứa các biến truyền giá trị vào cho web.
- Loại 2: URL không chứa các biến truy vấn mà chỉ trỏ đến các tệp tin
trên hệ thống.
Với từng loại lỗ hổng, kiểm thử viên cần xây dựng riêng những tập dữ
liệu fuzz cho từng loại lỗ hổng khai thác. Bộ dữ liệu có chất lượng và độ bao
phủ càng cao thì càng dễ phát hiện các lỗ hổng. Để thực hiện việc kiểm tra và
phát hiện các lỗ hổng, phải chèn tất cả các dữ liệu fuzzing vào tất cả các điểm
đầu vào hệ thống thu được trước khi thực hiện việc gửi yêu cầu. Nguyên tắc
chèn fuzzing vào các URL:
60
Bảng 2.8. Chèn dữ liệu fuzzing vào URL
Loại URL 1
URL http://localhost/index.php?var1=a
URL http://localhost/index.php?var1=[Fuzzing]
Fuzzing
Ví dụ http://localhost/index.php?var1=”onmouseover=alert(“signature”)
(XSS) foo=”
Loại URL 2
URL http://localhost/index.php
URL http://localhost/index.php?[Fuzzing] hoặc phải đoán biến (id, act,

Fuzzing page... )
http://localhost/index.php?id=[Fuzzing]
Ví dụ http://localhost/index.php?”onmouseover=alert(“XSS”)foo=”
(XSS) http://localhost/index.php?id=”onmouseover=alert(“XSS”) foo=”
http://localhost/index.php?act=”onmouseover=alert(“XSS”) foo=”
2.3.2. Chèn dữ liệu vào phương thức POST

Đối với các đường dẫn thu được là FORM POST (sử dụng phương thức
POST để truyền dữ liệu) chúng ta có thể thực hiện hoàn toàn tương tự, dữ liệu
Fuzzing được chèn vào các biến trong Form Data của gói tin request.
Nguyên tắc chèn dữ liệu vào data post:
Bảng 2.9. Chèn dữ liệu fuzzing vào phương thức POST
Kiểu FORM POST
URL POST /index.php HTTP/1.1

Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64)
Accept: text/html; charset=utf-8
Accept-Encoding: gzip, deflate
61
Accept-Language: vi
act=a&id=1
URL POST /index.php HTTP/1.1
Fuzzing Host: localhost
Accept: text/html
Accept-Language: vi
act=[Fuzzing]&id=[Fuzzing]
Ví dụ POST /index.php HTTP/1.1

(SQLi) Host: localhost
Accept: text/html
Accept-Language: vi
act=[Fuzzing]&id=-1 or 1=1-- -
2.4. Phương pháp phát hiện lỗ hổng bảo mật

Sau khi đã thu thập được các điểm đầu vào của hệ thống, Fuzzer bắt
đầu xử lý danh sách các mục tiêu đầu vào. Fuzzer thực hiện duyệt từng trường
dữ liệu fuzz của từng loại lỗ hổng với từng biểu mẫu yêu cầu. Đối với mỗi
biểu mẫu web, các địa chỉ được trích (hay mục tiêu) và phương thức (GET
hoặc POST), chúng căn cứ dựa trên phân loại trong quá trình thu thập được sử
dụng để gửi các nội dung yêu cầu. Sau một cuộc tấn công kiểm thử, thành
phần phân tích lỗ hổng bảo mật thực hiện phân tích kết quả trả về với các
phản ứng của máy chủ. Một thành phần phân tích sử dụng tiêu chuẩn đáp ứng
tấn công cụ thể và từ khóa để tính toán giá trị tin cậy để đưa ra các quyết định
về một cuộc tấn công có thành công và tồn tại lỗ hổng hay không.
Mô hình phát hiện lỗ hổng trong Fuzzing được mô tả như hình dưới:
62
Hình 2.15. Mô hình phân tích phát hiện lỗ hổng
Các bước thu thập URL một hệ thống website:
Bước 1: Xác định loại Fuzzing đang được thực hiện cho loại lỗ hổng
nào, từ đó, lấy ra các mẫu nhận dạng loại lỗ hổng đó.
Bước 2: Nhận HTTP Response từ Web Server và thực hiện phát hiện lỗ
hổng bảo mật bằng cách phân tích, đối sánh kết quả trả về với các mẫu nhận
dạng loại lỗ hổng. Nếu trùng với mẫu nhận dạng thì kết luận có tồn tại lỗ
hổng.
Bước 3: Đưa ra báo cáo lỗ hổng bảo mật website.
Căn cứ dựa trên loại lỗ hổng đang được kiểm tra mà Fuzzer thực hiện
tìm kiếm các đặc trưng của lỗ hổng đó trong kết quả trả về. Fuzzer cũng cần
phải duyệt header và lưu thời gian trả về để xác định trạng thái của website
đó. Việc kiểm tra các mã đặc trưng và ngoại lệ là rất quan trọng trong quá
trình phân tích và phát hiện lỗ hổng. Thu thập và thống kê về thời gian
timeout và các mã trạng thái cũng rất hữu ích cho việc xác định các vấn đề
nảy sinh.
Các ngôn ngữ lập trình hiện đại như C#, Java cung cấp các cơ chế đơn
giản cùng nhiều giao diện lập trình để tải các trang web. Nhưng việc sử dụng
63
ngôn ngữ bậc cao phải hết sức mềm dẻo bởi có thể sẽ khó tìm ra các lỗi ở bậc
thấp.
2.4.1. Phát hiện lỗ hổng dựa trên đặc trưng
Với mỗi loại lỗ hổng chúng mang những đặc trưng khác, vì vậy cần
phải có những cơ chế phân tích kết quả trả về khác nhau. Fuzzer dựa trên
những đặc điểm nhận dạng về lỗ hổng mà đánh giá và đưa ra kết luận một
giao dịch có tồn tại lỗ hổng hay không.
Các lỗ hổng trên hệ thống được phát hiện dựa trên các đặc điểm chính:
- Dựa vào mã trạng thái của hệ thống (status code): Mã trạng thái là
một phần quan trọng của kết quả trả về, nó cung cấp thông tin ban đầu về sự
thành công hay thất bại của yêu cầu. Fuzzer phân tích các phản hồi thô để xác
định các mã trạng thái, từ đó có thể xác định sự tồn tại của yêu cầu hay không
cho việc phân tích các thông tin tiếp theo. Ví dụ như các lỗ hổng liên quan tới
cấu hình mặc định hay tài khoản mật khẩu mặc định,...
- Dựa trên các loại lỗi của hệ thống (thông báo lỗi từ server): Các
trường hợp ngoại lệ không được quản lý và kiểm soát. Khi fuzzing ứng dụng
web có thể phát hiện lỗ hổng từ chính ứng dụng và từ máy chủ web mà nó
đang chạy. Do đó, theo dõi tình trạng máy chủ cũng rất quan trọng. Mặc dù
kết quả trả về từ máy chủ web cung cấp thông tin về lỗi xảy ra nhưng chúng
nó không đầy đủ. Có thể do yêu cầu fuzzing gây ra xử lý ngoại lệ hay máy
chủ không quản lý được mà dẫn đến các xung đột khai thác nếu đầu vào thay
đổi một chút. Thông báo lỗi từ ứng dụng có thể khác biệt, đặc biệt khi nó là
các cuộc tấn công SQL injection.
- Dựa vào sự xuất hiện của chữ ký (chữ ký đã gửi kèm trong các dữ liệu
fuzzing): Khi các trang web được tạo động có chứa dữ liệu đầu vào do người
dùng cung cấp, nó có thể tồn tại lỗ hổng như XSS... Người quản trị cần thiết
kế web lọc dữ liệu đầu vào của người dùng để đảm bảo web không bị tấn
công như vậy, nhưng việc lọc có thể là không đúng cách làm tồn tại kẻ hở tấn
công. Do đó, xác định dữ liệu đầu vào trong mã HTML phản hồi là một dấu
hiệu cho thấy ứng dụng web đang tồn tại lỗ hổng.
- Dựa trên việc các so sánh kết quả html nhận về từ 2 hoặc nhiều
request: Tương tự như dựa vào sự xuất hiện của chữ ký, đối với những dữ liệu
đầu vào giúp cho câu truy vấn được với phần điều kiện trở nên luôn đúng, nó
làm hệ thống trả về toàn bộ dữ liệu được hiển thị hay hiển thị sai khác so với
64
một câu truy vấn bình thường. Ví dụ như lỗ hổng blind SQL Injection dựa
trên ký thuật boolean based.
- Dựa trên thời gian xử lý của hệ thống: Như đã đề cập, thời gian chờ
phản hồi từ máy chủ là không nên bỏ qua. Chúng có thể chỉ ra trạng thái của
web có đúng như chương trình kiểm thử có mong muốn hay không. Ví dụ như
lỗ hổng blind SQL injection dựa trên kỹ thuật Time Based.
Dựa trên những đặc điểm của từng loại lỗ hổng mà bộ dữ liệu fuzz và
phương pháp kiểm thử áp dụng cho chúng. Kỹ thuật của từng phương pháp
này được mô tả như ở bảng 2.5:
Bảng 2.10. Cơ chế phát hiện các lỗ hổng hệ thống
Phương Lỗ hổng áp Mô tả kỹ thuật

pháp dụng
Dựa trên File Inclusion, Dựa vào kết quả thông báo lỗi của hệ
thông báo mã Path thống ta có thể biết được hệ thống có thực
trạng thái của Traversal, thi đoạn dữ liệu fuzzing đầu vào hay không
hệ thống Configuration, hoặc URL đó có tồn tại hay không.
… Ví dụ: Khi tìm một URL mặc định của hệ
thống. Nếu nó trả về giá trị lớn hơn hoặc
bằng 200 và nhỏ hơn 300. Thì có nghĩa là
URL đó là tồn tại.
Dựa trên các SQL Injection, Với từng loại lỗ hổng tương ứng fuzzer
lỗi của hệ Xpath phải phân tích và tìm kiếm các thông báo
thống Injection, lỗi tương ứng với request trong các mã
Code HTML trả về.
Injection, Ví dụ: Các thông báo lỗi về SQL Injection
LDAP được mô tả trong bảng 2.6.
Injection, …
Dựa trên sư Cross Site Chữ ký được đính kèm với dữ liệu fuzzing,
xuất hiện của Script nếu dữ liệu fuzzing này được thực thi sẽ
chữ ký xuất hiện chữ ký đó.
Ví dụ: Dữ liệu thực thi Fuzzing là:
65
<script>alert("XSS");</script>
Nếu đoạn script này được thực thi sẽ có
hộp thoại thông báo chữ ký “XSS”.
Dựa trên việc Blind SQLi, Thực hiện so sánh kết quả của 2 request
so sánh các Blind Xpath khi thực hiện chèn 2 đoạn dữ liệu fuzzing
kết quả của Injection, mang giá trị đối lập nhau.
HTML nhận Blind Ví dụ: SQL Injection với 2 mẫu đầu vào là:
được. Command
Injection, … -1’ or 1=1 -- - mang giá trị đúng
-1’ or 1=2 -- - mang giá trị sai
Dựa trên việc Blind SQL Thực hiện kiểm tra thời gian nhận được
kiểm tra thời Injection phản hồi của máy chủ sau khi thực thi yêu
gian phản hồi cầu có chèn dữ liệu fuzzing.
từ hệ thống. Ví dụ: SQL Injection sử dụng kỹ thuật
Time Base:
' and sleep(10) -- -
Với việc chèn vào đoạn fuzzing trên nếu
ứng dụng có lỗi Blind SQL injection trong
biến này thì hệ thống sẽ bị sleep(10) giây.
Ví dụ về mẫu nhận dạng của lỗ hổng SQL Injection dựa trên kỹ thuật
nhận dạng lỗi trả về từ hệ thống. Bảng 2.6 bao gồm những cụm ký tự đặc
trưng cho tất cả các loại hệ thống là Apache, ISS, Tomcat,.. mà nó có thể trả
về.
Bảng 2.11. Các mẫu thông báo lỗi từ SQL
Đầu vào Các thông báo lỗi từ hệ thống
' 1. 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 |
\xBF mysql_query | supplied argument is not a valid MySQL result
') resource in.
2. SQL command not properly ended | SQLException |
66
'') Supplied argument is not a valid PostgreSQL result | Syntax
or 1=1 error in query expression | The error occurred in | Unterminated
string constant | invalid query | is not allowed to access.
') or 1
3. \[Microsoft\]\[ODBC Microsoft Access Driver\]
%27
4. ASP\.NET is configured to show verbose error messages |
Microsoft OLE DB Provider for ODBC Drivers[\S\s]*error
5. java\.sql\.SQLException\: Syntax error or access violation
6. XPathException
7. Dynamic SQL Error
8. DB2 SQL error\:
2.4.2. Phát hiện lỗ hổng dựa trên cấu hình

Trong mỗi hệ thống luôn có những thành phần cần được bảo mật và nó
ảnh hưởng tới sự sinh tồn của cả hệ thống. Một hệ thống website cũng như
vậy, khi triển khai cần phải bảo mật những thông tin quan trọng, đặc biệt là
các thành phần trang quản trị. Một số thành phần quan trọng và nguyên nhân
cần làm lộ lọt thông tin hệ thống:
- Các đường dẫn tới tệp tin cấu hình hệ thống hiển thị trong mã HTML
hay để mặc định khi sử dụng mã nguồn mở.
- Các tệp tin cấu hình hệ thống, tệp tin dự phòng không được phân
quyền.
- Các đường dẫn mặc định trong các nền tảng ứng dụng (phpMyadmin,
manager.html…)
- Danh sách các thư mục và tệp tin hiển thị ra bên ngoài do không có
tệp tin index hay default mặc định.
- Cấu hình tài khoản, mật khẩu mặc định, không thay đổi so với ban
đầu.
Một tập dữ liệu fuzz bao gồm tên các thư mục và tệp tin mặc định của
hệ thống nó tạo thành các đường dẫn ngẫu nhiên để tìm kiếm chính xác trang
quản trị, các tệp tin mở rộng dự phòng, các tệp tin cấu hình, mặc định của hệ
thống. Khi đó để phát hiện những lỗi về cấu hình này, fuzzer cần phải gửi các
yêu cầu kèm theo các trường nằm trong bộ dữ liệu fuzz của lỗ hổng này, sau
67
đó thực hiện kiểm tra mã trạng thái trả về của hệ thống và mã nguồn HTML.
Mã trạng thái trả về 200 cho những truy cập thành công, 404 cho các truy cập
thất bại hay 302 chuyển hướng truy cập do không tồn tại tài nguyên đó. Khi
đó fuzzer hoàn toàn có thể phân tích, đánh giá việc tồn tại các lỗi về cấu hình
mặc định này. Một số phương pháp phân tích kết quả trả về để phát hiện các
lỗi cấu hình mặc định được trình này trong bảng 2.7:
Bảng 2.12. Phát hiện các lỗi do cấu hình
Kiểu lỗi Mô tả kỹ thuật phát hiện
Directory Đường dẫn được phân tách thành các đường dẫn trỏ tới các
Listing thư mục nhằm thực hiện kiểm tra các đường dẫn này có
hiển thị danh sách các tệp tin nằm trong nó hay không.
Được xác định dựa trên 2 đặc điểm:
- Mã trạng thái trả về từ 200 đến 299.
- Trong mã HTML trả về có chứa các từ khóa “index of”
hoặc “parent directory”.
Manager Path Thực hiện tấn công phỏng đoán đường dẫn tới trang quản
trị website bằng cách gửi các yêu cầu với các đường dẫn trỏ
tới trang quản trị như /admin, /administrator, /manager,…
Xác định dựa trên 2 đặc điểm chính là
- Mã trạng thái trả về từ 200 đến 299. Một số trường hợp
cần kiểm tra mã trạng thái từ 300 đến 399.
- Trong mã HTML trả về có chứa form đăng nhập, mà
trường nhận dạng chính là type = “password”.
Tệp tin cấu Thực hiện gửi yêu cầu tới các đường dẫn thư mục và nối
hình thêm tên các tệp tin cấu hình như .htaccess,... Truy cập vào
đường dẫn file cấu hình.
Xác định dựa trên đặc điểm:
- Mã trạng thái trả về từ 200 đến 299
- Mã HTML có chứa các từ khóa tương ứng của các tệp tin
cấu hình.
68
Tệp tin Back- Tương tự như tấn công thử nghiệm vào các tệp tin cấu hình.
up Các URL được trỏ đến tệp tin các extension mặc định của
update tệp tin (.back, ~, .bak...)
Đặc điểm nhận dạng chính là mã trạng thái trả về từ 200
đến 299.
Tài khoản, Bản chất của cuộc tấn công vào tài khoản, mật khẩu của
mật khẩu mặc một website là nó cố gắng sử dụng thuật toán vét cạn cho
định thực hiện đăng nhập tới khi đạt được điều mong muốn. Nó
chủ yếu được sử dụng để tấn công vào tài khoản quản trị,
người dùng và tài khoản cơ sở dữ liệu.
Xác định dựa trên đặc điểm:
- Mã trạng thái trả về là 302 cho sự chuyển hướng khi xác
thực thành công.
- Mã HTML khác so với giao diện đăng nhập.

Trong chương 2, với phạm vi nằm trong lĩnh vực kiểm thử bảo mật
website, kỹ thuật Fuzzing đã được trình bày một cách chi tiết. Cùng với đó là
các nguyên lý và phương pháp phát hiện lỗ hổng bảo mật web. Chi tiết các
phần như sau:
- Phần đầu trình bày tổng quan về mô hình và quy trình thực hiện
Fuzzing. Cho thấy rằng, quy trình này cũng tương tự như quy trình kiểm thử
phần mềm nhưng nó sử dụng các phương thức, đặc trưng phát hiện và bộ dữ
liệu dành riêng cho kiểm thử website.
- Trong các phần thu thập điểm đầu vào, chèn dữ liệu fuzzing, phương
pháp phát hiện lỗ hổng, đây là ba giai đoạn quan trọng nhất trong quy trình
fuzzing kiểm thử bảo mật website. Thu thập điểm đầu vào và chèn dữ liệu là
giai đoạn khởi đầu cho một cuộc tấn công kiểm thử, chúng thu thập những vị
trí chèn dữ liệu và lần lượt thực hiện chèn các dữ liệu này. Phương pháp phát
hiện là một phần trong giai đoạn phân tích lỗ hổng, đây là những căn cứ giúp
cho Fuzzer có thể nhận dạng lỗ hổng tồn tại trong kết quả trả về của các lượt
truy vấn.
69
Đây là nội dung nghiên cứu quan trọng cho việc đưa ra toàn bộ chi tiết
kỹ thuật, quy trình thực hiện xây dựng một ứng dụng kiểm tra và phát hiện lỗ
hổng bảo mật web.
70
Chương 3
XÂY DỰNG ỨNG DỤNG
KIỂM TRA LỖ HỔNG BẢO MẬT WEBSITE
Chương này sẽ trình bày việc mô tả ứng dụng, phân tích thiết kế hệ
thống, lựa chọn các phương thức xử lý như giao tiếp TCP/IP, xử lý bất đồng
bộ và thực hiện lập trình xây dựng ứng dụng kiểm tra lỗ hổng bảo mật
website trên ngôn ngữ C#. Đồng thời trình bày quá trình cài đặt, thử nghiệm
trên một số website. Từ đó, đưa ra các đánh giá về hiệu năng hoạt động của
ứng dụng.
3.1. Đặc tả chương trình
3.1.1. Mô tả
Ứng dụng kiểm tra lỗ hổng bảo mật website (Fuzzer) dựa trên kỹ thuật
Fuzzing là một phần mềm sử dụng kỹ thuật phân tích động với hướng tiếp cận
dựa trên phỏng đoán, sử dụng thuật toán Fuzzing với tập dữ liệu đầu vào là
được xây dựng dựa trên kinh nghiệm từ các chuyên gia, cho phép người dùng
kiểm tra tự động hoặc thủ công các lỗ hổng bảo mật của website như SQL
Injection, Cross Site Script,... tìm kiếm những chính sách đăng nhập cũng như
những phương thức xác thực vào website, nhằm hỗ trợ cho quản trị viên phát
hiện và khắc phục các lỗ hổng bảo mật mà tin tặc có thể khai thác tấn công.
Chương trình sẽ có khả năng kiểm tra hệ thống web có mắc phải các lỗi
bảo mật hay không. Bằng cách thực hiện các tiến trình:
- Lấy về toàn bộ nội dung website, lọc ra tất cả các liên kết trên site dựa
trên tệp tin robots.txt, sitemap.xml,... sau đó hiển thị chi tiết cấu trúc này.
- Sau tiến trình lấy toàn bộ liên kết website và kiểm tra tình trạng web,
Fuzzer tự động phát động các cuộc tấn công đã được lập trình sẵn dựa trên
các lỗ hổng, giống như một người tấn công vào website thực sự. Sau đó phân
tích các phản hồi trả về để tìm kiếm lỗ hổng, với những vị trí có thể nhập dữ
liệu cùng và sự kết hợp khác nhau của dữ liệu đầu vào có thể làm cho website
hiển thị thông tin nhạy cảm của hệ thống.
- Sau khi tìm ra các lỗ hổng, chương trình sẽ thông báo các lỗ hổng
gồm thông tin, mức độ nguy hiểm và các khuyến nghị về cách thức khắc
phục.
Bộ dữ liệu fuzz được cập nhật thường xuyên và càng đa dạng cho từng
loại lỗ hổng thì hiệu quả càng cao, sử dụng kỹ thuật lập trình bất đồng bộ giúp
71
giảm thời gian thực thi các luồng dữ liệu. Xây dựng trên giao diện đồ họa
người dùng giúp cho ứng dụng đơn giản, dễ dàng sử dụng.
3.1.2. Yêu cầu
3.1.2.1. Yêu cầu chức năng
Từ những mô tả về chương trình kiểm tra lỗ hổng website như trên,
ứng dụng có các yêu cầu sau:
- Chương trình quét toàn bộ nội dung của của website, trích lọc được
các liên kết và đưa ra cấu trúc webiste.
- Kiểm tra, phát hiện các loại lỗ hổng bảo mật đang tồn tại của một
website.
- Phân loại các lỗ hổng tìm được, thông báo kết quả kiểm tra.
- Đối với các lỗ hổng phát hiện được, đưa ra lời khuyên để khắc phục
cho từng lỗ hổng.
- Chương trình có phần cho người dùng thực hiện Fuzzing thủ công dựa
trên hiểu biết của người dùng.
- Người dùng có thể tùy chỉnh sửa bộ dữ liệu fuzz cho từng loại lỗ
hổng.
3.1.2.2. Yêu cầu phi chức năng
Ứng dụng phải đáp ứng được các tiêu chí phi chức năng về chất lượng
và hiệu quả kiểm thử như sau:
- Người dùng không phải thủ công dò từng trang của website để kiểm
tra, mà chương trình cho phép quét tự động toàn bộ nội dung của website.
- Ứng dụng phải cung cấp một giao diện trực quan, rõ ràng, dễ sử dụng.
- Ứng dụng thực hiện kiểm tra và phát hiện lỗ hổng phải nhanh chóng.
- Thực hiện phát hiện các lỗ hổng có độ chính xác cao.
3.2. Thiết kế hệ thống
3.2.1. Kiến trúc chương trình
Ứng dụng xây dựng theo một kiến trúc linh hoạt, bao gồm các tầng,
trong mỗi tầng có các thành phần xử lý riêng biệt. Với giao diện đồ họa,
người dùng có thể cấu hình đơn lẻ hay kết hợp cho một cuộc tấn công. Với
kiến trúc phân tầng, chương trình được chia làm 2 tầng chính:
72
- Tầng 1: Tầng giao diện, có nhiệm vụ hiện thị kết quả xử lý lên giao
diện cho người dùng xem kết quả:
+ Các URL thu thập được của một website.
+ Hiển thị các thông báo về lỗ hổng tồn tại trên website, đưa ra các
khuyến nghị và biện pháp khắc phục của từng lỗ hổng.
- Tầng 2: Tầng xử lý, đảm nhiệm xử lý toàn bộ hoạt động của ứng
dụng. Tầng này được phân tách thành các thành phần đảm nhiệm từng xử lý
riêng biệt, bao gồm: thành phần thu thập điểm đầu vào, thành phần tấn công,
thành phần xử lý. Tầng này có nhiệm vụ:
+ Xử lý các thông tin trả lời từ máy chủ và thu thập toàn bộ URL và
các điểm đầu vào.
+ Thực hiện cuộc tấn công thử nghiệm Fuzzing vào tất cả các điểm đầu
vào thu thập được.
+ Phân tích các phản hồi trả về của cuộc tấn công Fuzzing, xác định sự
tồn tại của lỗ hổng và đưa ra kết quả.
Kiến trúc phân tầng của ứng dụng kiểm tra lỗ hổng bảo mật website
được mô tả như hình 3.1 dưới đây:
73
Hình 3.16. Kiến trúc phân tầng của ứng dụng
3.2.2. Thiết kế chức năng hệ thống
3.2.2.1. Chức năng thu thập URL website
Thông tin chung: Mục này đặc tả chức năng thu thập toàn bộ liên kết
của website, mục đích chính của nó là cung cấp các điểm đầu vào cho quá
trình Fuzzing.
Luồng xử lý chức năng: Luồng xử lý xuất phát từ người dùng nhập
URL gốc, URL này được kiểm tra và tương tác với website nhằm tìm kiếm
các URL tiếp theo. Luồng xử lý chức năng này được mô tả như hình 3.2:
74
Hình 3.17. Luồng xử lý chức năng thu thập URL
Dòng sự kiện: Bắt đầu sự kiện khi người dùng muốn hiển thị toàn bộ
liên kết và cấu trúc của website. Hệ thống yêu cầu người sử dụng nhập vào
địa chỉ chính xác của website cần thu thập.
Điều kiện thực hiện: Để thực hiện người dùng cần phải nhập địa chỉ
website là địa chỉ gốc của website đó.
Kết quả xử lý: Nếu thực hiện thành công thì hiển thị danh sách các
URL ra màn hình, nếu không thì thông báo nguyên nhân và kết quả xử lý cho
người sử dụng.
3.2.2.2. Chức năng quét lỗ hổng website
Thông tin chung: Mục này dùng để đặc tả chức năng quét lỗ hổng bảo
mật của toàn bộ website.
Luồng xử lý chức năng: Mô tả như hình 3.3 dưới đây:
75
Hình 3.18. Luồng xử lý chức năng quét lỗ hổng website
Dòng sự kiện: Bắt đầu sự kiện khi người một người muốn sử dụng
chức năng toàn bộ quét lỗ hổng bảo mật cho website. Hệ thống yêu cầu người
sử dụng phải nhập địa chị website cần đánh giá.
Điều kiện thực hiện: Để thực hiện chức năng này người sử dụng phải
nhập chính xác địa chỉ website cần quét. Thực hiện chọn chức năng tự động
đánh giá toàn bộ website.
Kết quả xử lý: Nếu thực hiện quét thành công và đánh giá là lỗ hổng thì
hiển thị các lỗ hổng ra màn hình, nếu không thì thông báo nguyên nhân và kết
quả xử lý cho người sử dụng.
3.2.2.3. Chức năng đưa ra lời khuyên
Thông tin chung: Mục này để đặc tả chức năng đưa ra lời khuyên đối
với các loại lỗ hổng phát hiện được.
Luồng xử lý chức năng: Được mô tả như hình 3.4 dưới đây:
76
Hình 3.19. Luồng xử lý chức năng đưa ra lời khuyên
Dòng sự kiện: Bắt đầu sự kiện khi người dùng muốn đánh giá lỗ hổng
của website. Với mỗi lỗ hổng phát hiện được thì đưa ra những lời khuyên
khắc phục lỗ hổng để người quản trị có thể sửa chữa cho website.
Điều kiện thực hiện: Để thực hiện được chức năng này cần phải có dữ
liệu về các lời khuyên tương ứng với từng loại lỗ hổng đó.
Kết quả xử lý: Khi phát hiện được lỗ hổng thì đồng thời người sử dụng
sẽ được thông báo về thông tin của lỗ hổng, đồng thời biện pháp khắc phục
của lỗ hổng đó.
3.3. Xây dựng chương trình
3.3.1. Phương thức xử lý
3.3.1.1. Ngôn ngữ sử dụng
C# là một trong những ngôn ngữ lập trình được sử dụng rộng rãi nhất.
Đi kèm với framework .NET nên C# được hỗ trợ nhiều tính năng, có thể tạo
ra những chương trình hay hệ thống mạnh mẽ. C# được miêu tả là ngôn ngữ
có được sự cân bằng giữa C++, Visual Basic, Delphi và Java.
Để xây dựng một công cụ kiểm tra lỗ hổng bảo mật website đơn giản,
thân thiện với người dùng, chúng ta cần xây dựng nó với giao diện GUI. C# là
một ngôn ngữ lập trình hướng đối tượng được phát triển bởi Microsoft, hoạt
động dựa trên framework .NET của Windows. C# được sử dụng để xây dựng
ứng dụng này với 3 lý do chính như sau:
77
- C# cho phép thiết kế với giao diện đồ họa GUI chuyên nghiệp.
- C# cung cấp một số lớp, thư viện hỗ trợ cho việc gửi và nhận gói tin
mạng.
- Nó cung cấp cơ chế lập trình xử lý không đồng bộ phù hợp cho xây
dựng ứng dụng cần trao đổi nhiều gói tin.
Nhược điểm tồn tại khi sử dụng C# đó là nó gắn liền với nền tảng
Windows mà khó chuyển sang sử dụng tại các nền tảng khác.
3.3.1.2. Giao tiếp giữa ứng dụng và máy chủ web
Giao tiếp giữa ứng dụng và máy chủ là giao tiếp giữa client và server.
Trong đó client kết nối đến server theo kiểu stream socket. Giao tiếp giữa
máy chủ web với chương trình Fuzzer:
Hình 3.20. Giao tiếp giữa Fuzzer và Server

C# cung cấp lớp WebClient bao gồm các chức năng xử lý yêu cầu và
phản hồi HTTP. Nó đáp ứng đầy đủ các chức năng để xử lý các yêu cầu của
một Fuzzer, C # cung cấp các lớp HTTPWebRequest và HTTPWebResponse.
Các lớp này tiện lợi và có nhiều chức năng tiên tiến như khả năng sử dụng
proxy. Nhưng nó lại không phù hợp để xây dựng một Fuzzer với số lượng
request rất lớn. Thay vào đó, lớp TcpClient được thiết kế cho bất kỳ gói tin
TCP nào. Các lớp và hàm tiêu chuẩn có sẵn không phù hợp với nhu cầu xử lý
dữ liệu cần thiết. Để xây dựng một Fuzzer, điều cần thiết phải kiểm soát hoàn
toàn yêu cầu HTTP thô, mà điều đó nhiều lớp có sẵn lại không cung cấp với
mức độ chi tiết.
78
Ví dụ:
Stream data = webClient.OpenRead(“http://buigiap.com”);
StreamReader rd = new StreamReader(data);
Một đoạn mã đơn giản với yêu cầu được gửi là từ lớp WebClient. Tuy
nhiên, khi bắt lưu lượng truy cập thực tế, yêu cầu được gửi đi như sau:
GET /HTTP/1.1
Host: buigiap.com
Connection: Keep-Alive
Trong gói tin yêu cầu thực tế, hai trường thông tin bổ sung đã được
thêm là Host và Connection. Đó cũng là lý do này mà chúng ta không thể sử
dụng các lớp có sẵn. Chúng ta cần phải xây dựng các yêu cầu ở một mức độ
thấp hơn và có thể điều khiển hoàn toàn quá trình Fuzzing. Trong trường hợp
này, sử dụng lớp TcpClient cho các thành phần kết nối của ứng dụng là điều
cần thiết.
3.3.1.3. Xử lý bất đồng bộ
Lập trình bất đồng bộ là lập trình các tác vụ với khả năng thực thi độc
lập nhau, nghĩa là chúng không nhất thiết phải chạy một cách tuần tự hoặc xử
lý này không phải đợi xử lý khác giúp cho việc cải thiện hiệu suất hoạt động
của ứng dụng.
Rất nhiều ngôn ngữ lập trình hiện nay hỗ trợ lập trình xử lý bất đồng bộ
(Asynchronous), vì vậy nó đã trở nên khá phổ biến. Lập trình xử lý bất đồng
bộ là rất tốt để cải thiện hiệu năng cho ứng dụng chúng ta. Tuy nhiên với công
nghệ trước đây, việc viết ứng dụng bất đồng bộ là khá phức tạp, khó khăn để
viết, debug và bảo trì.
Trong C# bắt đầu thực thi từ phương thức Main và kết thúc khi phương
thức Main được trả về. Trong đó tất cả các xử lý thực hiện một cách tuần tự
hết cái này đến cái khác. Một xử lý phải đợi xử lý trước đó hoàn thành. Do
vậy, .Net Framework 4.5 ra đời có một cách tiếp cập đơn giản để thúc đẩy lập
trình bất đồng bộ trở nên dễ dàng hơn bao giờ hết.
Lập trình bất đồng bộ thường được sử dụng trong các xử lý tiềm ẩn độ
trễ về mặt thời gian, như việc truy cập tới website, việc truy cập tài nguyên
của một website thường có sự chậm trễ. Vì vậy, để tránh lãng phí thời gian và
79
hiệu năng trong gửi yêu cầu và nhận phản hồi thì lập trình bất đồng bộ là một
giải pháp tối ưu. Lập trình bất đồng bộ được mô tả như hình 3.6 dưới đây:
Hình 3.21. Xử lý đồng bộ và bất đồng bộ
Giao tiếp mạng có thể được thực hiện bằng cách sử dụng socket với
đồng bộ hoặc không đồng bộ. Mặc dù sử dụng socket với không đồng bộ yêu
thêm một số xử lý nhưng việc sử dụng chúng là một điều hoàn toàn phù hợp
cho giải quyết các vấn đề thực hiện hàng trăm nghìn giao dịch.
Một giao dịch sử dụng socket đồng bộ bị chặn hay có độ trễ lớn, điều
này có nghĩa là yêu cầu hoặc phản hồi đang gặp phải sự chậm trễ trong giao
dịch. Như vậy máy chủ hay máy khách sẽ dừng lại và chờ đợi cho giao dịch
đó hoàn thành trước khi thực hiện một giao dịch tiếp theo. Với một ứng dụng
Fuzzer, quá trình fuzzing được thực hiện dựa trên bộ dữ liệu bất thường, như
vậy một số yêu cầu gửi đi có khả năng cao xảy ra sẽ bị chặn hay xảy ra sự cố.
Một fuzzer không thể đứng im chờ đợi một giao dịch có thể không bao giờ
thành công, điều đó làm cho Fuzzer hoạt động không hiệu quả. Socket với
không đồng bộ khởi động các luồng riêng biệt để xử lý và sử dụng chức năng
gọi lại để báo hiệu một giao dịch hoàn thành. Điều này cho phép các sự kiện
khác được xử lý mà không bị gián đoạn.
Chúng được mô tả dưới đoạn mã sau:
TcpClient client;
NetworkStream stream;
80
ClientState cs;
client = new TcpClient();

client.Connect(reqHost, Convert.ToInt32(tbxPort.Text));
stream = client.GetStream();
cs = new ClientState(stream, reqBytes);
IAsyncResult result = stream.BeginWrite(cs.ByteBuffer, 0,

cs.ByteBuffer.Length, new AsyncCallback(OnWriteComplete), cs);
result.AsyncWaitHandle.WaitOne();
Sau khi tạo một Client TCP và NetworkSteam, chúng gọi phương thức
BeginWrite() với 5 đối số như sau:
- Byte[] array: Một bộ đệm chứa luồng dữ liệu muốn gửi.
- Int offset: Vị trí trong bộ đệm để bắt đầu gửi dữ liệu.
- Int numBytes: Số byte đối đa để ghi gửi dữ liệu.
- AsyncCallback userCallback: Phương thức gọi lại, sẽ được gọi khi kết
nối hoàn tất.
- Object stateObject: Một đối tượng để phân biệt yêu cầu viết không
đồng bộ này từ các yêu cầu khác.
AsyncWaitHandle.WaitOne() làm cho sự kiện lắng nghe bị khóa cho
tới khi yêu cầu được gửi thành công. Tại thời điểm đó, chức năng gọi lại sẽ
được thực hiện bằng mã lệnh sau:
ClientState cs = (ClientState)ar.AsyncState;
cs.NetStream.EndWrite();
Khi chúng tôi viết xong yêu cầu của chúng tôi đến luồng mạng, chúng
tôi sẽ có thể nhận được kết quả từ máy chủ:
result = stream.BeginRead(cs.ByteBuffer, cs.TotalBytes,
cs.ByteBuffer.Length - cs.TotalBytes, new
AsyncCallback(OnReadComplete), cs);
Tại thời điểm này, chúng ta có thể gọi socket không đồng bộ một lần
nữa nhưng tốt hơn hết là sử dụng khoảng thời gian nên sử dụng để nhận phản
hồi. Chúng ta gọi phương thức BeginRead(), lấy các đối số giống như phương
81
thức BeginWrite(), sử dụng hàm OnReadComplete() như là phương thức gọi
lại của chúng ta:
public void OnReadComplete(IAsyncResult ar)
{
cs.NetStream.BeginRead(cs.ByteBuffer, cs.TotalBytes,
cs.ByteBuffer.Length - cs.TotalBytes, new
AsyncCallback(OnReadComplete), cs);
}
Chúng ta có thể bắt đầu OnReadComplete() bằng cách tạo một bộ đếm
thời gian (readTimeout) sẽ gọi ReadDone.Set() nếu đạt đến khoảng thời gian
chờ do người dùng xác định. Điều này cho phép chúng ta đảm bảo rằng một
giao dịch không hoạt động vô hạn nếu việc nhận phản hồi không được hoàn
thành. Nó cung cấp cho người dùng một phương tiện để kiểm soát độ dài thời
gian trễ.
3.3.2. Xây dựng các thành phần chính
Dựa trên kiến trúc của chương trình, ứng dụng bao gồm 3 phần chính.
Đầu tiên là thành phần thu thập điểm đầu vào, nó sẽ thu thập toàn bộ các liên
kết trong website. Sau đó, thành phần tấn công thực hiện các cuộc tấn công
vào mục tiêu này. Cuối cùng, thành phần phân tích thực hiện kiểm tra kết quả
trả về bởi các ứng dụng web để xác định lỗ hổng tồn tại:
- Thành phần thu thập điểm đầu vào:
Để thực hiện một phiên làm việc với thành phần thu thập điểm đầu vào,
ứng dụng cần được bắt đầu với một địa chỉ website gốc. Nó được bắt đầu như
là một điểm khởi đầu, trình thu thập điểm đầu vào lặp lại quá trình thực hiện
thu thập tất cả các liên kết và các biểu mẫu web trong suốt quá trình xử lý. Để
giảm số lượng thực hiện gửi yêu cầu, thành phần thu thập điểm đầu vào lọc và
loại bỏ các liên kết không thuộc tên miền gốc mà người dùng nhập, kể cả tên
miền phụ.
Cũng giống như những trình thu thập dữ liệu, chúng cũng có những tùy
chọn cấu hình cho quá trình thực hiện. Thành phần thu thập điểm đầu vào
được xây dựng tách biệt trong phần thu thập thủ công và trong cả quá trình tự
động quét lỗ hổng.
Hình 3.7 mô tả một phần đoạn mã hàm thực hiện chức năng Crawling
bằng ngôn ngữ C#:
82
Hình 3.22. Thành phần thu thập điểm đầu vào
- Thành phần tấn công:
Sau quá trình thu thập các điểm đầu vào được hoàn thành, ứng dụng bắt
đầu xử lý danh sách các mục tiêu tấn công này. Thành phần tấn công thực
hiện quét từng mục tiêu với mỗi biểu mẫu có trên trang web. Với mỗi mục
tiêu biểu mẫu web hay liên kết được trích, đi cùng với phương thức là GET
hay POST, các trường thông số của một gói tin HTTP sẽ được sử dụng để gửi
nội dung yêu cầu fuzzing. Sau đó, tùy thuộc vào cuộc tấn công thực tế mà giá
trị trên các trường được thay đổi cho phù hợp. Cuối cùng yêu cầu sẽ được gửi
lên máy chủ xác định bằng phương thức GET hay POST yêu cầu.
Hình 3.23. Thành phần tấn công
83
- Thành phần phân tích:
Sau một cuộc tấn công vào các mục tiêu của một website, các phản hồi
gửi trả về cho ứng dụng. Công việc lúc này thuộc về thành phần phân tích, nó
thực hiện phân tích và giải thích các phản ứng từ máy chủ. Dựa trên các tiêu
chuẩn tấn công cụ thể, từ khóa để tìm kiếm các biểu hiện của lỗ hổng mà cuộc
tấn công đó đang thực hiện và tính toán đưa ra quyết định cuộc tấn công đó đã
thành công, website có tồn tại lỗ hổng.
Hình 3.24. Thành phần phân tích

3.4. Triển khai, thử nghiệm
3.4.1. Cài đặt ứng dụng
Ứng dụng kiểm tra lỗ hổng website được xây dựng với các phần chính
là: Fuzzing Manual - thực hiện fuzzing thủ công, Crawler URL - thu thập
URL website, Auto Fuzzing & Scan Vulnerability - tự động quét và phân tích
lỗ hổng website. Người dùng cài đặt các thông số chung như Port để kết nối,
Timeout cho thời gian chờ đợi phản hồi của yêu cầu.
3.4.1.1. Fuzzing Manual
Cho phép người sử dụng có thể thực hiện fuzzing thủ công với bộ dữ
liệu Fuzz có sẵn trên hệ thống. Nội dung Request Headers được người dùng
tùy chỉnh theo ý muốn.
Người dùng tự cài đặt các thông số cho quá trình này bằng cách nhấp
chuột phải vào Request Header tại vị trí muốn chèn thông số, một hộp thoại
84
bao gồm các lựa chọn về Add Header, Add Fuzz Type như hình 3.10. Sau khi
hoàn thành các thông số, nhấn Request để thực hiện chức năng này.
Hình 3.25. Danh sách các thông số tùy chọn

Kết quả trả về là danh sách các phản hồi từ máy chủ trả về nằm trong
Respnses, người dùng có thể nhấp chọn để xem chi tiết các truy vấn được
hiển thị tại các hộp thoại dưới cùng.
Hình 3.11 mô tả giao diện của Fuzzing Manual cho quá trình quét thủ
công:
Hình 3.26. Giao diện Fuzzing thủ công
85
3.4.1.2. Crawler URL
Chức năng này để người dùng thực hiện chức năng crawl tách biệt khỏi
quá trình Fuzzing, thu thập toàn bộ các liên kết khác nhau của một website.
Để sử dụng chức năng này, người dùng chỉ cần nhấn chọn Crawler
URL và nhập địa chỉ website mong muốn vào URL root. Sau đó nhấn nút
Start Crawl để bắt đầu quá trình thu thập. Quá trình này diên ra trong thời
gian khá dài, tùy độ phức tạp của website.
Kết quả trả về là danh sách các đường dẫn khác nhau của website mà
người dùng nhập. Nó được tách thành các thành phần khác nhau: Path,
Method, Parameter Query,...
Hình 3.27. Giao diện Crawler URL

3.4.1.3. Auto Fuzzing & Scan Vulnerability
Auto Fuzzing & Scan Vulnerability bao gồm 2 thành phần chính là
Crawling và Fuzzing, 2 thành phần này thực hiện các chức năng là thu thập
86
điểm đầu vào, thực thi tấn công và phân tích lỗ hổng. Chức năng này được mô
tả như hình 3.13:
Hình 3.28. Giao diện Auto Fuzzing & Scan Vulnerability

Với chức năng này, quá trình thực thi diễn ra sẽ hoàn toàn tự động.
Người dùng chỉ cần nhập địa chỉ website cần rà quét lỗ hổng, sau đó nhấp vào
nút Start để thực hiện quét. Quá trình quét lỗ hổng diễn ra qua các giai đoạn
Crawling, Filtering, Fuzzing và khi hoàn thành sẽ hiển thị Done.
Kết quả trả về là danh sách các lỗ hổng tồn tại trên website đó. Danh
sách các lỗ hổng này được thể hiện qua cấu trúc thư mục cây, với mỗi nút
chính là một loại lỗ hổng và mỗi nút con là một lỗ hổng.
Người dùng có thể nhấn chọn từng lỗ hổng để xem chi tiết về lỗ hổng
và cách khắc phục lỗ hổng đó. Các thông tin chi tiết về từng lỗ hổng được mô
tả trong Info Vulnerablity và cách khắc phục lỗ hổng này được mô tả trong
phần How to fix.
87
3.4.2. Thử nghiệm, đánh giá
3.4.2.1. Dữ liệu
Dữ liệu đầu vào là một website có địa chỉ: http://192.168.1.128 /Apple/
Thông tin về máy chủ web: Linux buituan 2.6.32 - 431.el6.i686,
Apache/2.2.15 (CentOS), PHP/5.3.3, MySQL Version 5.3.3.
Hình 3.29. Website thử nghiệm

3.4.2.2. Kết quả
Quá trình thực hiện chức năng Auto Fuzzing & Scan Vulnerability
trong từng giai đoạn như sau:
Bảng 3.13. Kết quả quá trình thu thập
STT Quá trình Số lượng Thời gian Kết quả

truy vấn thực thi
1 Crawling 26 ~0.849s Thu được 26 URL
2 Filtering 0 ~0.115s Lọc còn 5 URL
3 Fuzzing 1028 ~2.124s Phát hiện 3 lỗ hổng
Kết quả sau quá trình thực hiện Fuzzing phát hiện được 3 lỗ hổng: 2 lỗ
hổng SQL Injection và 1 lỗ hổng XSS. Chi tiết các lỗ hổng được mô tả chi tiết
trong bảng sau:
88
Bảng 3.14. Danh sách các lỗ hổng phát hiện
STT Lỗ hổng Điểm đầu vào Dữ liệu fuzz
1 SQL http://192.168.1.128/Apple/ '

Injection index.php?ac=chitiet&id=MC1
2 SQL http://192.168.1.128/Apple/ '

Injection index.php?ac=timkiem
3 Cross http://192.168.1.128/Apple/ "><script>

Script Site index.php?ac=timkiem alert("XSS");
</script>
Tổng thời gian quá trình thực hiện khoảng 3 giây.
Hình 3.30. Danh sách các lỗ hổng website thử nghiệm

Kiểm tra lại các lỗ hổng vừa phát hiện được, ta thấy rằng các lỗ hổng
này hoàn toàn tồn tại. Đoạn mã "><script> alert("XSS"); </script> được thực
thi sau khi chèn vào nội dung tìm kiếm của website:
Hình 3.31. Lỗ hổng XSS được phát hiện
89
3.4.2.3. Đánh giá
a. Ưu điểm
- Phần mềm sau khi xây dựng và thực thi đã kiểm tra và phát hiện được
một số lỗ hổng nghiêm trọng của website.
- Tốc độ thu thập điểm đầu vào và thực thi tấn công của các website
local nhanh.
- Phát hiện các loại lỗ hổng có độ chính xác cao.
- Cho phép người dùng có thể thực hiện từng công đoạn tấn công và
phát hiện lỗ hổng.
b. Nhược điểm
- Quá trình crawling tại một số website trực tuyến còn chậm so với một
số phần mềm chuyên nghiệp.
- Quá trình lọc điểm đầu vào tương tự còn chưa chính xác, với một số
website có thiết kế đặc biệt thì khả năng bỏ xót là lớn.
- Thực thi với tất cả các loại fuzzing mà chưa kiểm soát được điểm đầu
vào nào phù hợp với loại tấn công nào.
- Bộ dữ liệu Fuzzing chưa đa dạng để phát hiện được tất cả các loại lỗi.
Trong chương 3, tác giả đã sử dụng công cụ lập trình để xây dựng
thành công ứng dụng kiểm tra lỗ hổng bảo mật website với hiệu năng và độ
chính xác của lỗ hổng ở mức tin cậy.
Chương này cũng đã trình bày chi tiết quá trình xây dựng ứng dụng từ
phân tích thiết kế hệ thống theo sơ đồ luồng xử lý của các chức năng thu thập
điểm đầu vào, quét lỗ hổng bảo mật, đưa ra lời khuyên. Kết hợp xây dựng ứng
dụng bằng ngôn ngữ lập trình C# với phương thức xử lý bất đồng bộ giúp
giảm thời gian trễ cho việc thực hiện hàng ngàn lượt truy vấn được gửi từ
Fuzzer tới máy chủ web. Ứng dụng đã được thử nghiệm với website có cấu
hình một số lỗ hổng mặc định, kết quả cho thấy ứng dụng đã hoạt động và
phát hiện được các lỗ hổng đang tồn tại trên website thử nghiệm. Các đánh
giá về ứng dụng đã được trình bày trong phần triển khai thử nghiệm tại
chương này.
90
Do hạn chế về mặt kiến thức và thời gian nên ứng dụng mới chỉ phát
hiện được các website có dạng đơn giản, tốc độ xử lý còn chưa ổn định.
91
KẾT LUẬN
Ngày nay, website đang ngày càng mở rộng và phát triển mạnh mẽ, vì
vậy vấn đề bảo mật cho website cũng ngày càng được quan tâm và trú trọng.
Nó trở thành yếu tố quyết định sinh tồn của một website hay hơn nữa là của
cả một tổ chức, doanh nghiệp đứng sau nó. Kiểm thử website đã trở thành
một hoạt động không thể thiếu trong quá trình xây dựng và vận hành, nhằm
đảm bảo hoạt động và quyết định chất lượng của website. Việc lựa chọn
phương pháp kiểm thử là kỹ thuật Fuzzing giúp cho việc kiểm thử web trở
nên hiệu quả, giảm chi phí và thời gian.
1. Kết luận
Sau khoảng thời gian nghiên cứu và thực hiện đồ án, theo yêu cầu ban
đầu đặt ra là nghiên cứu kỹ thuật Fuzzing và áp dụng trong kiểm tra lỗ hổng
bảo mật website, đồ án đã đạt được những kết quả như sau:
- Đưa ra được cơ sở lý thuyết về website, cách thức hoạt động, phân
loại lỗ hổng bảo mật website và giải pháp khắc phục cho từng loại lỗ hổng,
tạo nền tảng cho việc nghiên cứu phương thức phát hiện lỗ hổng bảo mật web
trong ngôn ngữ máy.
- Trình bày tổng quan về các phương pháp kiểm thử phần mềm như
kiểm thử hộp đen, hộp trắng, hộp xám. Đi sâu nghiên cứu kỹ thuật Fuzzing
trong phương pháp kiểm thử hộp đen, từ đó áp dụng cho kiểm thử bảo mật
ứng dụng web.
- Đưa ra được bộ dữ liệu Fuzzing phục vụ cho quá trình xây dựng phần
mềm, cũng như trong quá trình quét và phát hiện lỗ hổng.
- Nghiên cứu kỹ thuật lập trình bất đồng bộ trên ngôn ngữ C# nhằm
tăng tốc độ truy vấn lấy toàn bộ nội dung website, đồng thời trích xuất liên
kết và xây dựng lại cấu trúc một website.
- Xây dựng được ứng dụng kiểm tra lỗ hổng bảo mật website dựa trên
kỹ thuật Fuzzing dựa trên ngôn ngữ .NET với các chức năng chính như tự
động quét, phát hiện và thông báo lỗ hổng website, cho phép người dùng thực
hiện thủ công quá trình Fuzzing theo từng loại lỗ hổng hay quá trình thu thập
đầu vào.
- Đã thực hiện thử nghiệm trên một số website và đưa ra đánh giá về
hiệu năng của phần mềm.
92
Trong quá trình nghiên cứu và thực hiện đồ án, mặc dù đã nghiên cứu,
áp dụng nhiều kỹ thuật nhằm gia tăng hiệu năng của ứng dụng kiểm tra lỗ
hổng website nhưng vẫn tồn tại một số hạn chế như sau:
- Quá trình thực hiện quét và phát hiện lỗ hổng của phần mềm còn
chậm bởi chưa tối ưu hóa được số lượng yêu cầu gửi đi, tạo ra số lượng lớn
yêu cầu không cần thiết làm giảm tốc độ hoàn thành quét một website.
- Chưa xử lý đa dạng cho các trường hợp trong các mô hình website có
độ phức tạp lớn.
- Kết quả phát hiện lỗ hổng chỉ mang tính tương đối, mà chưa có độ
chính xác cao.
2. Hướng phát triển
Bước đầu đồ án đã đạt được các yêu cầu đề ra, tuy nhiên kết quả nghiên
cứu còn ở mức khá khiêm tốn. Tác giả xin đề xuất một số hướng phát triển
của đồ án trong quá trình thực hiện tiếp theo:
- Nghiên cứu và áp một số kỹ thuật trong các phương pháp kiểm thử
hộp trắng, hộp xám nhằm tận dụng trong việc thực hiện kiểm thử khi đã biết
cấu trúc hay có sẵn mã nguồn của website.
- Phát triển, nâng cấp và mở rộng các trường hợp xử lý cho việc thực
hiện kiểm thử trên mô hình bài toán website rộng hơn, phức tạp hơn. Phát
triển sâu hơn để bảo mật ở mức hệ thống mạng và dịch vụ.
- Nghiên cứu một số thuật toán và kỹ thuật mới nhằm nâng cao chất
lượng phần mềm về tốc độ lấy dữ liệu và độ chính xác trong phân tích lỗ hổng
tồn tại trong kết quả trả về từ máy chủ web.
- Phát triển phần mềm để có thể phát hiện được các lỗ hổng có liên
quan đến tính sẵn sàng của website như DOS/DDOS,...
93
TÀI LIỆU THAM KHẢO
Tiếng Việt
[1] Nguyễn Văn Đại (2011), “Ứng dụng web và vấn đề bảo mật”, Đồ án tốt
nghiệp, Đại học Công thương, Hà Nội.
[2] Nguyễn Thị Hương Giang (2009), “Khai phá dữ liệu web và máy tìm
kiếm”, Luận văn thạc sĩ, Đại học Sư phạm Hà Nội, Hà Nội.
[3] Đặng Quốc Hữu Nhân (2012), “Tìm hiểu về an ninh mạng và kỹ thuật
tấn công ứng dựng web”, Đồ án tốt nghiệp, Đại học Công Nghệ Thông
tin, Hà Nội.
[4] Nguyễn Ngọc Quân (2014), “Lỗ hổng Cross Site Scripting (XSS) và
biện pháp khắc phục”, Bài báo tạp chí, Học viện Công nghệ Bưu chính
Viễn thông, Hà Nội.
[5] Lê Ngọc Thức (2012), “Xây dựng công cụ đánh giá an toàn website”,
Luận văn thạc sĩ, Đại học Lạc Hồng, Đồng Nai.
[6] Phạm Thị Trang (2009), “Thiết kế test case trong kiểm thử phần mềm”,
Đồ án tốt nghiệp, Đại học Thái Nguyên, Thái Nguyên.
[7] Phạm Thị Ngọc Trâm (2016), “Nghiên cứu phương pháp và công cụ
kiểm thử tự động tính bảo mật ứng dụng web”, Đồ án tốt nghiệp, Học
viện Kỹ thuật mật mã, Hà Nội.
Tiếng Anh
[8] Glenford J. Myers (2004), “The Art of software testing”, Canada.
[9] IEEE 610.12:1990 (1990), “Standard Glossary of Software Engineering
Terminology”, IEEE Standards Board, United States of America.
[10] Justin Clarke (2009), “SQL Injection Attacks and Defense”, Gotham
Digital Science, UK.
[11] OWASP (2013), “The ten most critical web application security risks”,
OWASP, USA.
[12] OWASP (2009), “Testing Guide 4.0”, OWASP, USA.
[13] The Internet Society (1999), “Request for Comments (RFC) 2616”,
Internet Engineering Task Force - IETF, USA.
94
Website
[14] http://securitydaily.net/cac-phuong-phap-kiem-tra-ung-dung-web/
[15] https://books.google.com.vn/books?
id=smEMCAAAQBAJ&printsec=frontcover&hl=vi&source=gbs_ge_su
mmary_r&cad=0#v=onepage&q&f=false
[16] http://kcntt.duytan.edu.vn/Home/ArticleDetail/vn/128/2461/bai-01-so-
luoc-ve-fuzzing-testing
[17] https://vi.wikipedia.org/wiki
[18] http://vietjack.com/http/http_status_codes.jsp
[19] https://itsecuritykma.blogspot.com/2014/01/tim-hieu-web-application-
1.html
[20] https://viblo.asia/tran.thi.huong.trang/posts/RQqKLM64Z7z
95

123doc Do An Ung Dung Fuzzing Trong Kiem Thu Khai Thac Lo Hong Bao Mat Website Co Code 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

123doc Do An Ung Dung Fuzzing Trong Kiem Thu Khai Thac Lo Hong Bao Mat Website Co Code 1

Uploaded by

Copyright:

Available Formats

MỤC LỤC

Từ viết tắt Nghĩa Tiếng Anh Nghĩa Tiếng Việt

TCP Transmission Control Protocol Giao thức truyền TCP

XML Extensible Markup Language Ngôn ngữ đánh dấu mở rộng

SSL Secure Sockets Layer Lớp bảo mật socket

XSS Cross Script Site Lỗ hổng XSS

CSRF Cross - Site Request Forgery Lỗ hổng CSRF

URL Uniform Resource Locator Địa chỉ tài nguyên

RFI Remote File Inclusion Lỗ hổng RFI

LFI Local File Inclusion Lỗ hổng LFI

GUI Graphical User Interface Giao diện đồ họa người dùng

CSDL Database Cơ sở dữ liệu

GET /Apple/index.php HTTP/1.1

STT Trường Mô tả

3 Accept Các loại nội dung có thể chấp nhận.

5 Accept-Encoding Danh sách các loại mã hóa được chấp nhận.

7 User-Agent Trường User-Agent chứa các thông tin về tác

10 Range Xác định phần nội dung được yêu cầu.

STT Mã Mô tả

3 3xx Redirection (Chuyển hướng): Mã trạng thái này cho biết

4 4xx Client Error (Lỗi Client): Nó nghĩa là request chứa cú pháp

STT Trường Mô tả

1 Date Thời điểm phản hồi từ phía Server.

3 Content-Length Độ dài của gói tin HTTP Response.

4 Content-Type Loại nội dung gói tin gửi về.

9 Pragma Các chỉ dẫn cụ thể để thực hiện.

Domain Flag Path Secure Expiration Name Value

www.redhat.co FALSE / FALSE 1154029490 Apache 64.3.40.151.16

Set-Cookie: Apache="64.3.40.151.16018996349247480"; path="/";

Hình 1.3. Kiểm thử hộp đen

Hình 1.4. Kiểm thử hộp trắng

Hình 1.5. Kiểm thử hộp xám

Top 10 OWASP 2013

STT Lỗ hổng Mô tả

2 Broken Xác thực hay quản lý phiên thiếu chính xác. Sơ hở

10 Unvalidated Chuyển hướng không an toàn người dùng đến một

SELECT * FROM user WHERE username= “Username” AND password=

Username: admin” or 1-- -

Ta được câu truy vấn SQL như sau:

SELECT * FROM user WHERE username= “admin” or 1-- - AND

Hình 1.6. Hộp thoại lỗ hổng XSS chứa cookie

Hình 1.7. Website bị lỗi Directory Listing

<?php $file = $_GET['page']; //Trang web sẽ hiển thị ?>

Với đường dẫn truy cập ban đầu như sau:

b. Fuzzing thay thế

Hình 2.11. Quy trình Fuzzing

Thuộc tính Các thẻ có chứa thông tin URL

src Nằm trong mã HTML, mã javascript.

action Nằm trong mã HTML, nằm trong thẻ <form>.

location Nằm trong mã Javascript.

<form action="xacthuc.php" method="post">

Hình 2.14. Các đường dẫn từ tệp tin robots.txt

Giao Tên miền Cổng Đường dẫn Truy vấn Phân

http buigiap.com 80 path1/index.php var1=a & endpage

URL Nội dung đường dẫn

URL http://localhost/index.php?[Fuzzing] hoặc phải đoán biến (id, act,

2.3.2. Chèn dữ liệu vào phương thức POST

Kiểu FORM POST

URL POST /index.php HTTP/1.1

Ví dụ POST /index.php HTTP/1.1

2.4. Phương pháp phát hiện lỗ hổng bảo mật

Phương Lỗ hổng áp Mô tả kỹ thuật

Đầu vào Các thông báo lỗi từ hệ thống