Nhóm 7 Báo Cáo Chính TH C

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KĨ THUẬT MẬT MÃ
ĐỀ CƯƠNG CHI TIẾT HỌC PHẦN

KĨ THUẬT LẬP TRÌNH
Đề Tài: Kiểm thử Fuzzing ứng dụng Web
Ngành: An toàn thông tin
Sinh viên thực hiện:

Lê Anh Đức Mã SV: AT180611
Tào Minh Đức Mã SV: AT180610
Mai Huy Việt Hoàng Mã SV: AT180619
Trần Minh Khánh Mã SV: AT180625
Lê Đăng Phương Mã SV: AT180638
Người hướng dẫn : TS. Bùi Việt Thắng

Khoa An toàn thông tin - Học viện Kỹ thuật mật mã
Hà Nội, 2024
MỤC LỤC
MỤC LỤC 2
DANH MỤC HÌNH 5
DANH MỤC BẢNG 6
DANH MỤC TỪ VIẾT TẮT 7
MỞ ĐẦU 8
Chương 1: Tổng quan về kiểm thử bảo mật website 10
1. Giới thiệu về ứng dụng web 10
1.1. Khái niệm ứng dụng web 10
1.2. Mô tả hoạt động của website 11
1.3. Lỗ hổng website 11
2. Kiểm thử phần mềm 12
3. Kiểm thử web 14
4. Các loại lỗ hổng bảo mật web 14
4.1. Phân loại lỗ hổng bảo mật web 14
4.2. Một số lỗ hổng bảo mật ứng dụng web chính 16
5. Kỹ thuật fuzzing 23
5.1. Khái niệm 23
5.2. Ưu nhược điểm của kiểm thử fuzzing 24
5.3. Tầm quan trọng của kỹ thuật fuzzing trong kiểm thử bảo mật web 25
6. Tổng kết chương 1 26
Chương 2: Kỹ thuật Fuzzing trong kiểm tra lỗ hổng bảo mật Website 27
1. Các giai đoạn trong kiểm thử Fuzzing 27
1.1. Xác định mục tiêu (Identify target) 27
1.2. Xác định đầu vào 28
1.3. Sinh dữ liệu fuzz hay còn gọi là tạo các ca kiểm thử 28
1.4. Thực thi dữ liệu fuzz 30
1.5. Giám sát dữ liệu fuzz 30
2
1.6. Đăng lỗi và phân tích 31
2. Thu thập các điểm đầu vào 31
2.1. Thu thập dữ liệu web với web crawler 31
2.2. Quy trình thu thập 31
2.3. Trích xuất URL từ mã HTTP 35
3. Nguyên lý chèn dữ liệu fuzz 36
3.1. Chèn dữ liệu với phương thức get 36
3.2. Chèn dữ liệu với phương thức post 37
4. Phương pháp phát hiện lỗ hổng bảo mật 38
4.1. Phát hiện lỗ hổng bảo mật dựa trên đặc trưng 39
5. Các lỗ hổng được phát hiện bởi kiểm thử Fuzzing 42
6. Tổng kết chương 2 43
Chương 3: Xây dựng ứng dụng kiểm tra lỗ hổng bảo mật Website 45
1. Đặc tả chương trình 45
1.1. Mô tả 45
1.2. Yêu cầu 45
2. Thiết kế hệ thống 46
2.1. Kiến trúc chương trình 46
2.2. Thiết kế chức năng hệ thống 47
3. Xây dựng chương trình 49
3.1. Phương thức xử lý 49
3.2. Xây dựng các thành phần chính 51
4. Triển khai, thử nghiệm 55
4.1. Crawler URL 55
4.2. SQL Injection scan 55
4.3. Cross-Site Scripting scan 56
4.4. File Inclusion 56
4.5. Auto scan 56
5. Thử nghiệm, đánh giá 57
3
5.1. Dữ liệu 57
5.2. Kết quả 57
5.3. Đánh giá 59
6. Kết luận chương 3 59
TỔNG KẾT CHUNG 60
TÀI LIỆU THAM KHẢO 61
BẢNG PHÂN CÔNG NHIỆM VỤ 63
4
DANH MỤC HÌNH
Hình 1.1. Kiểm thử hộp đen 13
Hình 1.2. Kiểm thử hộp trắng 14
Hình 1.3. Kiểm thử hộp xám 14
Hình 1. 4. Hộp thoại lỗ hổng XSS chứa cookie 21
Hình 1.5. Kết quả sau tấn công lỗ hổng LFI 23
Hình 1.6. Minh họa lỗ hổng cấu hình mặc định 25
Hình 2.1 Các giai đoạn trong kiểm thử fuzz 30
Hình 2. 2 Mô hình thu thập URL theo mã HTML 35
Hình 2. 3 Mô hình phân tích phát hiện lỗ hổng 42
Hình 2.4. Các giai đoạn trong SDLC mà các lỗ hổng phát hiện được 46
Hình 3.1. Kiến trúc phân tầng của ứng dụng 50
Hình 3.2. Luồng xử lý chức năng thu thập URL 51
Hình 3.3. Luồng xử lý chức năng quét lỗ hổng website 52
Hình 3.4. Giao tiếp giữa Fuzzer và Server 53
Hình 3.5. Thành phần thu thập điểm đầu vào 55
Hình 3.6. Thành phần tấn công với lỗ hổng SQL injection 56
Hình 3.7. Thành phần tấn công với lỗ hổng XSS 57
Hình 3.8. Thành phần tấn công với lỗ hổng File inclusion 57
Hình 3.9. Thành phần phân tích với lỗ hổng SQL injection 58
Hình 3.10. Thành phần phân tích với lỗ hổng XSS 58
Hình 3.11. Thành phần phân tích với lỗ hổng File inclusion 58
Hình 3.12. Giao diện ứng dụng 59
Hình 3.13. Website thử nghiệm 61
Hình 3.14. Các lỗ hổng SQL Injection được phát hiện 61
Hình 3.15. Các lỗ hổng XSS được phát hiện 62
Hình 3.16. Các lỗ hổng File Inclusion được phát hiện 62
Hình 3.17. Các lỗ hổng được phát hiện 63
5
DANH MỤC BẢNG
Bảng 1.1. Top 10 lỗ hổng website phổ biến nhất năm 2013 (OWASP) 16
Bảng 2.1. Ví dụ trong fuzzing đường dẫn tương đương 38
Bảng 2.2. Các thuộc tính và các thẻ đi kèm có chứa các URL của hệ thống 39
Bảng 2.3. Chèn dữ liệu fuzzing vào URL 41
Bảng 2.4. Chèn dữ liệu fuzzing vào phương thức POST 42
Bảng 2.5. Cơ chế phát hiện các lỗ hổng hệ thống 45
Bảng 2.6. Các mẫu thông báo lỗi từ SQL 46
6
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 ApplicationDự á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
7
MỞ ĐẦU
Tên bài tập lớn: “Kiểm thử Fuzzing ứng dụng Web”.
1. Lý do chọn đề tài
Kiểm thử fuzzing trong ứng dụng web là một kỹ thuật kiểm thử phần mềm quan
trọng và cần thiết trong bối cảnh xã hội hiện đại ngày càng phụ thuộc vào các dịch vụ
trực tuyến. Theo thống kê từ các báo cáo an ninh mạng, các cuộc tấn công vào ứng dụng
web chiếm một tỷ lệ đáng kể trong tổng số các cuộc tấn công mạng trên toàn cầu, và
những sự cố liên quan đến lỗ hổng bảo mật trong ứng dụng web ngày càng gia tă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. Điều này cho thấy sự cần
thiết của các phương pháp kiểm thử và bảo mật mạnh mẽ hơn để bảo vệ ứng dụng web
khỏi các mối đe dọa an ninh mạng.
Kiểm thử fuzzing là một kỹ thuật kiểm thử tự động giúp phát hiện sớm các lỗ
hổng bảo mật tiềm ẩn trong ứng dụng web. Các lỗ hổng như SQL injection, cross-site
scripting (XSS), và cross-site request forgery (CSRF) có thể dẫn đến hậu quả nghiêm
trọng như rò rỉ dữ liệu, lạm dụng thông tin cá nhân, chiếm đoạt tài khoản người dùng, và
gây mất an toàn cho ứng dụng. Bằng cách cung cấp dữ liệu đầu vào ngẫu nhiên hoặc bất
thường vào chương trình, fuzzing kiểm tra phản ứng của ứng dụng để phát hiện các lỗi
hoặc lỗ hổng.
Cách thức kiểm thử fuzzing thường bao gồm việc tạo ra các dữ liệu đầu vào ngẫu
nhiên theo các mẫu hoặc quy tắc cụ thể, rồi quan sát cách ứng dụng phản hồi. Nếu ứng
dụng gặp sự cố hoặc xử lý không đúng cách với dữ liệu đầu vào này, công cụ fuzzing sẽ
ghi lại lỗi hoặc lỗ hổng đó để đội ngũ phát triển có thể khắc phục.
Việc thực hiện kiểm thử fuzzing một cách hệ thống và liên tục giúp đảm bảo rằng
ứng dụng web hoạt động ổn định, đáng tin cậy và an toà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̣. Nhờ đó, fuzzing không chỉ bảo vệ người dùng
khỏi các rủi ro không mong muốn mà còn góp phần nâng cao uy tín và danh tiếng của
doanh nghiệp. Hơn nữa, một ứng dụng web an toàn và chất lượng cao sẽ thúc đẩy sự
phát triển bền vững của xã hội số hóa, tạo điều kiện cho các dịch vụ trực tuyến phát triển
và cải thiện chất lượng cuộc sống của người dân.
Xuất phát từ thực tế trên,chúng em đã lựa chọn đề tài “Kiểm thử Fuzzing ứng
dụng Web” thuộc phạm vi các vấn đề đã nêu để làm đề tài 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. 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.
- 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.
3. Nhiệm vụ nghiên cứu
Nhiệm vụ nghiên cứu 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: 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.
4. Đối tượng nghiên cứu
- 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.
5. 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.
+ 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.
9
+ 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.
6. Phạm vi nghiên cứu
- Không gian, thời gian: Trong phạm vi đề tài
- 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.
7. 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ử bảo mật 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.
Chương 1: Tổng quan về kiểm thử bảo mật website

Chương 1 tập trung vào tổng quan về kiểm thử bảo mật website. Nó bao gồm giới
thiệu về ứng dụng web, giải thích khái niệm ứng dụng web và các lỗ hổng phổ biến có
thể ảnh hưởng đến tính bảo mật và hiệu suất của trang web. Chương cũng đề cập đến
kiểm thử phần mềm và kiểm thử web, mô tả các phương pháp và quy trình kiểm tra tính
bảo mật của ứng dụng web. Ngoài ra, chương phân loại các loại lỗ hổng bảo mật web
khác nhau và giải thích các lỗ hổng chính trong ứng dụng web, bao gồm cách chúng
hoạt động và bị khai thác. Cuối cùng, chương trình bày về kỹ thuật fuzzing, cung cấp cái
nhìn tổng quan về khái niệm, ưu nhược điểm, và tầm quan trọng của kỹ thuật này trong
kiểm thử bảo mật web.
1. Giới thiệu về ứng dụng web

1.1. Khái niệm ứng dụng web
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
10
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…).
Ứ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.
1.2.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. 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.
1.3.Lỗ hổng website
Lỗ hổng website là những điểm yếu của hệ thống website mà tin tặc có thể lợi
dụng để khai thác nhằm thu thập thông tin về hệ thống, tấn công lấy cắp thông tin, tấn
công vào người dùng hệ thống hay tấn công chiếm quyền điều khiển hệ thống website .
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:
11
- 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.
2. Kiểm thử phần mềm
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)
2.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 [12].
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)
12
Hình 1.1. 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.
2.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.2. 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.
2.3.Kiểm thử hộp xám
Là sự kết hợp của kiểm thử hộp đen và hộp trắng. 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ó 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.
13
Hình 1.3. 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 [5].
3. Kiểm thử web
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.
4. Các loại lỗ hổng bảo mật web
4.1. Phân loại lỗ hổng bảo mật web
Bảng 1.1. Top 10 lỗ hổng website phổ biến nhất năm 2013 (OWASP)
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ở này
Authentication cho phép kẻ tấn công có thể lợi dụng để đạt được mật
14
and Session khẩu, khóa hay phiên làm việc, từ đó mạo danh phiên
Management 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 (XSS) đến rủi ro này. Các dữ liệu bất hợp lệ được gửi đến
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 tham
Object Referenceschiếu trực tiếp đến một đối tượng nội bộ hay 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
Misconfiguration khung ứng dụng, máy chủ ứng dụng, máy chủ cơ sở 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 Function Thiếu các điều khoản trong việc phân quyền quản trị
Level Access các mức, dẫn đến việc kẻ tấn công có thể lợi dụng và
Control 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 Forgery nạn nhân thực hiện các hành động nguy hiểm mà nạn
(CSRF) nhân không hề hay biết, ví dụ như chuyển tiền 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 lỗ
Vulnerable hổng đã được công khai, dễ dàng dẫn đến việc bị kẻ tấn
Components 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 để chuyển
Forwards hướng nạn nhân đến một trang đích được chuẩn bị sẵn
của kẻ tấn công.
15
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...
- 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 . Ví dụ như: Path Traversal, Predict Resource Location, Directory
Listing...
4.2. Một số lỗ hổng bảo mật ứng dụng web chí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.
4.2.1. Lỗ hổng injection
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 [8].
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.
16
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.
Cơ chế phát hiện
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
- 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(),...
17
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̃
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.
- 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.
- 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.
4.2.2. Lỗ hổng Cross Site Script
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[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.
18
- 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ả.
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.
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. 4. Hộp thoại lỗ hổng XSS chứa cookie

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ư:
19
<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 . 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.
4.2.3. Lỗ hổng File Inclusion
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 .
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.
20
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:
Hình 1.5. Kết quả sau tấn công lỗ hổng LFI
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
../../../etc/shadow
../.../apache/logs/access.log
21
Việc chèn số các “../” là do chương trình phát hiện sẽ tự động thêm vào.
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 đề.
4.2.4. Lỗ hổng do cấu hình mặc định
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ư:
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:
22
Hình 1.6. 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.
5. Kỹ thuật fuzzing
5.1. Khái niệm
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 các lỗ hổng bảo mật tiềm ẩn của phần mềm. Dữ liệu không mong
23
đợ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 [13].
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),...
5.2. Ưu nhược điểm của kiểm thử fuzzing

5.2.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
Error: Reference source not found.
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.
5.2.2. Nhược điểm
24
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.
5.3. Tầm quan trọng của kỹ thuật fuzzing trong kiểm thử bảo mật web
Fuzzing là một phương pháp kiểm thử bảo mật quan trọng và hiệu quả trong lĩnh vực
kiểm thử ứng dụng web, đóng vai trò quan trọng trong việc đảm bảo an toàn và chất
lượng của ứng dụng. Phương pháp này dựa trên việc cung cấp đầu vào bất thường hoặc
không mong muốn cho ứng dụng web và theo dõi phản hồi của ứng dụng để phát hiện
các lỗ hổng tiềm ẩn. Với khả năng kiểm thử rộng, fuzzing có thể áp dụng cho nhiều
thành phần của ứng dụng web, bao gồm giao diện người dùng, API, và cơ sở dữ liệu.
Điều này mang lại sự đánh giá toàn diện về mức độ an toàn của ứng dụng.
Một trong những lợi ích quan trọng của fuzzing là khả năng tự động hóa quá trình
kiểm thử và tích hợp vào quy trình phát triển liên tục (CI/CD). Nhờ vậy, fuzzing giúp
phát hiện lỗ hổng sớm hơn, cải thiện chất lượng phần mềm ngay từ giai đoạn phát triển,
và giảm thiểu rủi ro an ninh trong các giai đoạn triển khai và bảo trì.
Phương pháp fuzzing cũng cho phép thử nghiệm nhiều phương pháp tấn công khác
nhau, từ các kỹ thuật tấn công đã biết đến các phương pháp mới nổi. Điều này giúp tìm
ra các lỗ hổng zero-day, tức là những lỗ hổng chưa được công bố trước đó, nâng cao tính
an toàn cho ứng dụng và người dùng.
Khi phát hiện và sửa chữa các lỗ hổng bảo mật sớm thông qua fuzzing, nguy cơ tấn
công thực sự có thể giảm đáng kể, giúp bảo vệ ứng dụng và người dùng khỏi các mối đe
dọa bảo mật tiềm ẩn. Điều này không chỉ tăng cường an ninh cho ứng dụng mà còn cải
thiện chất lượng tổng thể của nó, bao gồm hiệu suất và tính ổn định. Do đó, fuzzing là
một công cụ quan trọng trong kiểm thử bảo mật web, góp phần tạo ra những ứng dụng
an toàn và đáng tin cậy cho người dùng.
25
6. Tổng kết chương 1
Chương 1 cung cấp cái nhìn tổng quan về kiểm thử bảo mật website, bao gồm giới
thiệu về ứng dụng web, kiểm thử phần mềm, kiểm thử web và các loại lỗ hổng bảo mật.
Đầu tiên, chương trình bày về khái niệm ứng dụng web, phân loại và các lỗ hổng tiềm ẩn
có thể ảnh hưởng đến bảo mật của ứng dụng.
Kiểm thử phần mềm và kiểm thử web được thảo luận như là những phương pháp cơ
bản để đảm bảo chất lượng và tính toàn vẹn của các ứng dụng web. Kiểm thử web bao
gồm các kỹ thuật và công cụ khác nhau nhằm kiểm tra chức năng, hiệu suất và tính bảo
mật của ứng dụng.
Phần tiếp theo tập trung vào việc phân loại các lỗ hổng bảo mật web, bao gồm một số
lỗ hổng chính như SQL Injection, Cross-Site Scripting (XSS), và các lỗ hổng khác. Kiến
thức về những lỗ hổng này là cần thiết để phát triển các chiến lược kiểm thử và bảo mật
hiệu quả.
Cuối cùng, chương trình bày khái niệm kỹ thuật fuzzing, ưu và nhược điểm của kiểm
thử fuzzing, và tầm quan trọng của kỹ thuật này trong kiểm thử bảo mật web. Fuzzing là
một phương pháp mạnh mẽ để phát hiện lỗ hổng bảo mật thông qua việc tạo ra các
trường hợp kiểm thử đa dạng và bất ngờ.
Tổng kết lại, Chương 1 cung cấp một nền tảng lý thuyết quan trọng về kiểm thử bảo
mật web, bao gồm kiến thức về ứng dụng web, lỗ hổng bảo mật, và phương pháp kiểm
thử và fuzzing. Những kiến thức này là cần thiết cho việc xây dựng và triển khai các giải
pháp kiểm thử bảo mật web hiệu quả.
26
Chương 2: Kỹ thuật Fuzzing trong kiểm tra lỗ hổng bảo mật
Website
Chương 2 tập trung vào kỹ thuật fuzzing trong kiểm tra lỗ hổng bảo mật website.
Chương mô tả các giai đoạn của kiểm thử fuzzing, bao gồm xác định mục tiêu, đầu vào,
sinh dữ liệu fuzz, thực thi và giám sát dữ liệu fuzz, cũng như đăng lỗi và phân tích. Tiếp
theo là thu thập các điểm đầu vào thông qua web crawler, quy trình thu thập và trích
xuất URL từ mã HTTP. Chương cũng giải thích nguyên lý chèn dữ liệu fuzz thông qua
phương thức GET và POST. Ngoài ra, chương cung cấp các phương pháp phát hiện lỗ
hổng bảo mật dựa trên đặc trưng và các lỗ hổng được phát hiện bởi kiểm thử fuzzing.
1. Các giai đoạn trong kiểm thử Fuzzing

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 :
1.1.Xác định mục tiêu (Identify target)

Tùy theo mục đích, tác động, nguy cơ và người dùng mà ở giai đoạn này các mục
tiêu khác nhau có thể được lựa chọn. Hiện nay, các mục tiêu được đánh giá có nguy cơ
rủi ro cao:
-Các ứng dụng như nhận dữ liệu qua mạng - có khả năng bị tổn hại từ xa, tạo điều
kiện thực thi mã từ xa, để tạo ra các chương trình độc hại (virus, worm ,,,).
- Các ứng dụng chạy ở mức ưu đãi cao hơn so với một người sử dụng - những điều
đó có tiềm năng để cho phép kẻ tấn công thực thi mã ở mức độ đặc quyền cao hơn của
chính họ, được gọi là leo thang đặc quyền.
- Các ứng dụng xử lý thông tin có giá trị - một kẻ tấn công có thể phá vỡ các điều
khiển và vi phạm sự toàn vẹn, tin cậy hoặc sẵn sàng có của dữ liệu có giá trị.
- Các ứng dụng xử lý thông tin cá nhân – một kẻ tấn công có thể phá vỡ các điều
khiển và vi phạm sự toàn vẹn, tin cậy hoặc sẵn sang có của dữ liệu cá nhân có giá
trị(Windows Explorer, Window Registry, Media files, Office Documents, Configuration
files)
27
Hình 2.1 Các giai đoạn trong kiểm thử fuzz
1.2. Xác định đầu vào
Đầu vào ứng dụng có thể có nhiều hình thức, hoặc từ xa (mạng traffic), hoặc
cục bộ (các file, các khóa registry, các biến môi trường, đối số dòng lệnh, tên đối
tượng …). Một số fuzzer đã tiến hóa để phục vụ cho nhiều loại đầu vào. Các lớp đầu
vào ứng với fuzzers phổ biến như sau:
1. Command line arguments
2. Environment variables (ShareFuzz)
3. Web applications (WebFuzz)
4. File formats (FileFuzz)
5. Network protocols (SPIKE)
6. Memory
7. COM objects (COMRaider)
8. Inter Process Communication

1.3. Sinh dữ liệu fuzz hay còn gọi là tạo các ca kiểm thử
28
Mục đích của một bộ kiểm thử Fuzz là để kiểm tra sự tồn tại của lỗ hổng bảo
mật có thể truy cập thông qua đầu vào trong các ứng dụng phần mềm. Do đó dữ liệu
sinh ra trong kiểm thử Fuzz phải đạt được những yêu cầu sau:
- Tạo ra dữ liệu thử nghiệm ở các mức độ khác nhau, đảm bảo thỏa mãn điều
kiện đầu vào của ứng dụng.
- Dữ liệu đầu vào được tạo ra có thể có dạng tệp tin nhị phân (Binary files), tệp
tin văn bản (Text files) được sử dụng lặp đi lặp lại trong quá trình kiểm tra
- Việc tạo ra dữ liệu kiểm thử với nhiều ca kiểm thử lặp đi lặp lại để bắt lỗi khi
chạy chương trình.
Bộ kiểm thử Fuzz được phân loại dựa trên hai tiêu chí khác nhau:
- Vector đơn ánh (Injection vector) hoặc vector tấn công (Attack vector)
Các bộ kiểm thử Fuzz có thể được chia dựa trên các lĩnh vực ứng dụng mà
chúng sử dụng, nhưng về cơ bản theo hướng vector tấn công. Đối với bộ kiểm thử
Fuzz theo loai vector đơn ánh nó sẽ thực hiện kiểm thử hộp đen thông qua viêc nhập
dữ liệu đầu vào. Các bộ kiểm thử Fuzz loại này dùng để kiểm thử phía client và môt
số khác để kiểm thử phía server. Đối với bộ kiểm thử Fuzz kiểm thử phı́a client với
giao thức HTTP hoặc TLS sẽ nhằm mục tiêu vào các trình duyệt. Đối với các bộ kiểm
thử Fuzz kiểm thử phı́a Server sẽ thực hiện kiểm thử trên máy chủ Web Server. Một
số bộ kiểm thử Fuzz khác hỗ trợ kiểm thử trên cả hai Server và Client, hoặc thậm chí
cả hai (dùng để phân tı́ch proxy hoặc phân tích lưu lượng).
- Kỹ thuật ca kiểm thử
Bộ kiểm thử Fuzz cũng có thể được phân loại dựa trên cá c ca kiểm thử phức
tạp. Các ca kiểm thử được tạo ra trong kiểm thử Fuzz với mục tiêu tạo ra các lớp khác
nhau trong phần mềm, và nhờ đó có thể thâm nhập vào các lớp logic khác nhau trong
ứng dụng.
Bộ kiểm thử Fuzz mà thay đổi các giá trị khác nhau trong các giao thức sẽ kiểm
tra được các dạng lỗ hổng như là các vấn đề về số nguyên. Khi cấu trúc thông điệp bị
biến đổi di ̣thường, các bộ kiểm thử Fuzz sẽ tìm thấy sai sót trong phân tích cú pháp
thông điệp (ví dụ như trong đặc tả XML và ASN.1).
Một số phương pháp phân loại dựa trên sự phức tạp của ca kiểm thử trong một
bộ kiểm thử Fuzz:
- Bộ kiểm thử Fuzz dựa trên mẫu tĩnh và ngẫu nhiên (Static and random
template-based Fuzzer): thường chỉ kiểm tra các giao thức đáp ứng những yêu cầu
đơn giản hoặc các định dạng tập tin.
- Bộ kiểm thử Fuzz dựa trên khối (Block-based Fuzzer): sẽ thực hiện cấu trúc
cơ bản cho một giao thức đáp ứng yêu cầu đơn giản và có thể chứa một số chức năng
động thô sơ như tính toán về kiểm tra tổng và chiều dài các giá trị (lengthvalues).
- Bộ kiểm thử Fuzz dựa trên tiến hóa hoặc bộ sinh động (Dynamic generation or
evolution based Fuzzer): những bộ kiểm thử Fuzz này không nhất thiết phải hiểu
29
được giao thức hoặc định dạng tập tin đang được làm mờ, nhưng có thể tìm hiểu nó
dựa trên một vòng phản hồi từ hệ thống mục tiêu.
- Bộ kiểm thử Fuzz dựa trên mô phỏng hoặc dựa trên mô hình (Model-based or
simulation-based Fuzzer): những bộ kiểm thử Fuzz này thực hiện kiểm thử giao diện
hoặc thông qua một mô hình hay là một mô phỏng, hoặc nó cũng có thể được triển
khai đầy đủ theo một giao thức nào đó. Không chỉ có cấu trúc thông điệp được làm
mờ, mà những thông điệp bất thường trong chuỗi được tạo ra cũng có thể được làm
mờ.
Hiệu quả của kiểm thử Fuzz phu ̣thuộc vào:
- Độ bao phủ không gian đầu vào: Không gian đầu vào của giao diện kiểm thử
càng tốt thı̀ hiêu quả đạt càng cao.
- Chất lượng của dữ liệu kiểm thử: Các đầu vào đôc hai tiêu biểu và di ̣hình sẽ
làm tăng khả năng kiểm tra đối với các yếu tố hoăc cấu trúc trong định nghĩa giao
diện.
1.4. Thực thi dữ liệu fuzz
Trong giai đoạn này, các bộ kiểm thử Fuzz thực hiện phần lớn các chức năng
của các cách tiếp cận nêu trên nhưng bằng các giải pháp đặc biệt để tự động hóa quá
trình xử lý kiểm thử.
Đối tượng tiếp cận của kiểm thử Fuzz bao gồm:
- Số (số nguyên dương, số âm, số thực...)
- Ký tự (urls, đầu vào dòng lệnh)
- Siêu dữ liệu
- Các chuỗi nhị phân, đinh dạng tệp tin (.pdf, png, .wav, .mpg…)
- Các giao thức mạng (http, SOAP, SNMP…)
- Các giao diện đầu I/O , các dòng lệnh tùy chọn, nhập/ xuất, các biểu mẫu, nội
dung hay yêu cầu do người dùng tạo ra v.v…
Cách tiếp cận chung cho kiểm thử Fuzz là :
- Sinh tập dữ liệu giá trị nguy hiểm (còn được gọi là fuzz vectors) ứng vớ i từng
loại đầu vào cụ thể, các lỗ hổng, các định dạng tệp tin, mã nguồn, các giao thức hoặc
tổ hợp của các dữ liệu này.
- Chèn thêm mã thực thi vào mã máy của chương trình.
- Phân tích hoạt động của chương trình trong quá trình thực thi.
1.5. Giám sát dữ liệu fuzz
Trong giai đoạn này, các bộ kiểm thử Fuzz không chỉ đơn thuần phát hiện các
lỗ hổng qua quá trình kiểm thử mà còn phải định nghĩa các lỗi đượ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ỗi. Để có được
một báo cáo lỗi đầy đủ và rõ ràng, đòi hỏi sự hiểu biết rõ về hoạt động xử lý. Quá
trình này có thể được tích hợp vào trong sự kiện phân loại lỗi tự động.
1.6. Đăng lỗi và phân tích
30
Sau khi một hoặc một số lỗi phần mềm đã được xác định, các bộ kiểm thử Fuzz
gửi một danh sách các lỗi này tới đội ngũ phát triển để họ có thể sửa chữa chúng.
2. Thu thập các điểm đầu vào
2.1. Thu thập dữ liệu web với web crawler
Trình thu thập web, hay còn gọi là Web crawler, là một chương trình khai thác cấu
trúc đồ thị của web bằng cách di chuyển từ trang này sang trang khác. Ban đầu, chúng
được gọi bằng những cái tên như bọ web, rô-bốt, nhện và sâu, nhưng ngày nay tên gọi
phổ biến nhất là trình thu thập web.
Quá trình thu thập web bắt đầu bằng việc chọn một số đường dẫn (URL) của các
trang web gọi là trang hạt giống. Khi ghé thăm một trang hạt giống, trình thu thập đọc
nội dung trang web và lọc ra các siêu liên kết có trong trang. Các URL tương ứng với
các siêu liên kết này được đưa vào danh sách biên giới (frontier) và được tiếp tục
duyệt đệ quy để ghé thăm tất cả các URL chưa được duyệt.
Việc thu thập web dừng lại khi trình thu thập đã thu thập đủ số trang yêu cầu hoặc
danh sách biên giới không còn URL để duyệt. Sau khi có danh sách URL để thu thập,
quá trình lấy trang diễn ra và các trang được lưu vào cơ sở dữ liệu giống như của
công cụ tìm kiếm. Việc cập nhật thông tin liên tục được tiến hành do web là một thực
thể năng động, thay đổi nhanh chóng.
Các trang web thường được viết bằng ngôn ngữ đánh dấu như HTML, XHTML và
chứa đựng thông tin hữu ích cho người dùng. Kỹ thuật bóc tách và trích xuất thông
tin tự động được sử dụng để lấy dữ liệu từ các trang web. Quá trình thu thập web
tương tự như việc duyệt đệ quy một đồ thị, với các trang là các đỉnh và các siêu liên
kết là các cạnh.
Trình thu thập web là thành phần đầu tiên trong toàn bộ hệ thống search engine,
nhằm duy trì cơ sở dữ liệu được đánh chỉ mục và trả về kết quả cho hàng triệu truy
vấn từ người dùng. Ngoài ra, trình thu thập web còn có thể được sử dụng để xây dựng
phần mềm tập trung thông tin và trang web tổng hợp thông tin dựa trên cơ chế tự
động tìm và phát hiện tài nguyên.
2.2.Quy trình thu thập
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
31
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.4 dưới đây:
Hình 2. 2 Mô hình thu thập URL theo mã HTML

Để 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.
32
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,... 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ờ.
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́.
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://nhom7.com/path1/index.php?a=1&b=2#endpage
33
Giao Tên miền Cổng Đường dẫn Truy vấn Phân mảnh
thức
http Nhom7.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. 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.
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.1:
Bảng 2.1. 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.
34
2.3.Trích xuất URL từ mã HTTP
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.
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.2:
Bảng 2.2. 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á trị
href
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.
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:
35
<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>
</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 .
3. Nguyên lý chèn dữ liệu fuzz
3.1. Chèn dữ liệu với 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:
Bảng 2.3. Chèn dữ liệu fuzzing vào URL
36
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=”
3.2. Chèn dữ liệu với 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.4. 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
Accept-Language: vi
37
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í POST /index.php HTTP/1.1

dụ
(SQLi) Host: localhost
Accept: text/html
Accept-Language: vi
act=[Fuzzing]&id=-1 or 1=1-- -
4. Phương pháp phát hiện lỗ hổng bả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:
38
Hình 2. 3 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.
4.1. Phát hiện lỗ hổng bảo mật 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
39
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 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.5. Cơ chế phát hiện các lỗ hổng hệ thống
Phương pháp Lỗ hổng áp

Mô tả kỹ thuật
dụng
Dựa trên thông

File Inclusion,
Dựa vào kết quả thông báo lỗi của hệ thống ta
báo mã trạngPath Traversal,
có thể biết được hệ thống có thực thi đoạn dữ
40
thái của hệ thốngConfiguration, …liệu fuzzing đầu vào hay không 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 lỗi

SQL Injection,
Với từng loại lỗ hổng tương ứng fuzzer phải
của hệ thống Xpath Injection,
phân tích và tìm kiếm các thông báo lỗi tương
Code Injection,
ứng với request trong các mã HTML trả về.
LDAP Injection,
Ví dụ: Các thông báo lỗi về SQL Injection
… được mô tả trong bảng 2.6.
Dựa trên sư xuất Cross Site ScriptChữ ký được đính kèm với dữ liệu fuzzing,
hiện của chữ ký nếu dữ liệu fuzzing này được thực thi sẽ xuất
hiện chữ ký đó.
Ví dụ: Dữ liệu thực thi Fuzzing là:
<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”.
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.6. 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 | mysql_query | supplied
\xBF argument is not a valid MySQL result resource in.
') 2. SQL command not properly ended | SQLException | Supplied
'') argument is not a valid PostgreSQL result | Syntax error in query
or 1=1 expression | The error occurred in | Unterminated string constant |
invalid query | is not allowed to access.
') or 1
3. \[Microsoft\]\[ODBC Microsoft Access Driver\]
%27
41
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\:
5. Các lỗ hổng được phát hiện bởi kiểm thử Fuzzing
Hình 2.4. Các giai đoạn trong SDLC mà các lỗ hổng phát hiện được
Lỗ hổng của ứng dụng phần mềm được tạo ra trong giai đoạn khác nhau của chu
trı̀nh vòng đời phát triển phần mềm (SDLC): đặc tả, sản xuất và phát triển. Chính vı̀ điều
đó nên sản phẩm cuối cùng không tránh khỏi các vấn đề về an toàn. Kiểm thử Fuzz
thường có thể phát hiện các khuyết tật bị bỏ qua khi phần mềm được viết và sửa lỗi.
Thực tế cho thấy hơn 70% số lỗ hổng bảo mật hiện đại do lập trình sai sót, chỉ có ít hơn
10% là vấn đề cấu hình và khoảng 20% là vấn đề thiết kế.
Kiểm thử Fuzz làm việc tốt nhất trong việc phát hiện ra lỗi về tràn bô ̣nhớ (buffer
overflow), kịch bản hóa chéo trang (XSS), từ chối dịch vụ (DoS), lỗi chuỗi định dạng
42
(Format String Errors), chèn câu truy vấn (SQL Injection) v.v... Vı̀ thế với kiểm thử
Fuzz người ta có thể kiểm tra sự an toàn của bất kỳ quá trình, dịch vu, thiết bị, hệ ̣ thống,
hoặc mạng máy tı́nh v.v…
Đối với việc kiểm tra tính bảo mật, một kỹ thuật phổ biến là kiểm thử dựa trên tập
vector fuzz cụ thể nào đó, bao gồm các kịch bản để kích hoạt các loại của lỗ hổng cụ thể:
- Kịch bản hóa chéo trang (XSS)
- Tràn bộ đệm và lỗi chuỗi định dạng
- Tràn số nguyên
- Chèn truy vấn SQL
- Chèn truy vấn SQL chủ động/ bị động
- Chèn LDAP
- Chèn XML/XPATH v.v…
Kiểm thử Fuzz cũng có thể được sử dụng bởi tin tặc trong việc tìm cách có được
thông tin về các hệ thống và đáp ứng hệ thống để sử dụng trong việc xây dựng các cuộc
tấn công. Vì vậy điều quan trọng là phải xác định, đánh giá được rủi ro và nguy cơ trong
việc tấn công các ứng dụng của mình.
Kiểm thử Fuzz một mình không thể cung cấp một bức tranh hoàn chỉnh của bảo
mật tổng thể, chất lượng, hiệu quả của một chương trình trong một tình huống hoặc ứng
dụng cụ thể. Các bộ kiểm thử fuzz (Fuzzer) có hiệu quả nhất khi được sử dụng kết hợp
với mở rộng kiểm thử hộp đen, kiểm thử beta và các phương pháp gỡ lỗi đã được chứng
minh khác.
6. Tổng kết chương 2
Chương 2 tập trung vào việc trình bày các kỹ thuật Fuzzing trong kiểm tra lỗ hổng
bảo mật của website, với một số giai đoạn quan trọng trong quá trình này. Đầu tiên, xác
định mục tiêu và đầu vào là bước khởi đầu để chuẩn bị cho quá trình kiểm thử Fuzzing.
Tiếp theo, quá trình sinh dữ liệu fuzz và thực thi dữ liệu này được triển khai nhằm tạo ra
các trường hợp kiểm thử đa dạng, giúp phát hiện lỗ hổng tiềm ẩn trong ứng dụng web.
Giám sát dữ liệu fuzz và phân tích phản hồi từ ứng dụng web là những bước then
chốt để đánh giá hiệu quả của các kỹ thuật Fuzzing. Thông qua việc thu thập các điểm
đầu vào và quy trình thu thập, các kỹ thuật như web crawler được sử dụng để lấy dữ liệu
từ website mục tiêu. Ngoài ra, trích xuất URL từ mã HTTP cũng đóng vai trò quan trọng
trong việc xác định và xử lý các điểm đầu vào.
Nguyên lý chèn dữ liệu fuzz với các phương thức GET và POST đã được giải
thích cặn kẽ, giúp người đọc hiểu cách sử dụng các phương thức này trong quá trình
kiểm thử. Cuối cùng, phương pháp phát hiện lỗ hổng bảo mật dựa trên đặc trưng và các
lỗ hổng được phát hiện bởi kiểm thử Fuzzing đã được thảo luận chi tiết.
43
Chương này cung cấp một cái nhìn tổng quan về quá trình kiểm thử Fuzzing, bao
gồm các bước và kỹ thuật cần thiết để phát hiện lỗ hổng bảo mật trong ứng dụng web.
Kiến thức này là nền tảng quan trọng cho việc xây dựng và triển khai các giải pháp kiểm
thử bảo mật website hiệu quả.
44
Chương 3: Xây dựng ứng dụng kiểm tra lỗ hổng bảo mật
Website
1. Đặc tả chương trình
1.1. Mô tả
Ứ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 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.
- 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.
1.2. Yêu cầu
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.
- 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.
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 dụng thực hiện kiểm tra và phát hiện lỗ hổng phải nhanh chóng.
45
- Thực hiện phát hiện các lỗ hổng có độ chính xác cao.
2. Thiết kế hệ thống
2.1. Kiến trúc chương trình
Kỹ thuật Fuzzing kiểm tra lỗ hổng bảo mật website chia làm 2 bước chính:
- Bước 1 có nhiệm vụ chuẩn bị cho quá trình fuzzing:
 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 .
- Bước 2: Tiến hành phân tích điểm đầu vào chèn payload và sử dụng kỹ thuật
tấn công brute force:
 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:
Hình 3.1. Kiến trúc phân tầng của ứng dụng
46
2.2. Thiết kế chức năng hệ thống
2.2.1. Chức năng thu thập URL
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:
Hình 3.2. 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.
2.2.2. Chức năng quét lỗ hổng
47
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:
Hình 3.3. 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. Xây dựng chương trình
3.1. Phương thức xử lý
3.1.1. Ngôn ngữ sử dụng
48
Python là một ngôn ngữ lập trình phổ biến trên toàn thế giới và được sử dụng rộng
rãi trong cộng đồng lập trình. Nó có một số thư viện và framework hữu ích, như Pandas,
NumPy, Flask và Django, giúp người lập trình phát triển các ứng dụng nhanh chóng và
hiệu quả.
Python có thể được sử dụng để phát triển nhiều loại ứng dụng khác nhau, bao gồm
các ứng dụng web, ứng dụng máy tính cá nhân, ứng dụng di động và nhiều hơn nữa. Nó
cũng có thể được sử dụng để xử lý dữ liệu, làm việc với cơ sở dữ liệu, và thực hiện nhiều
loại tác vụ khác.
3.1.2. Giao tiếp giữa các ứng dụng và máy chủ 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.4. Giao tiếp giữa Fuzzer và Server

Module Requests là một thư viện Python phổ biến được sử dụng để gửi các yêu
cầu HTTP đến các API và dịch vụ web khác nhau. Nó đơn giản hóa quá trình gửi yêu
cầu HTTP và cho phép các nhà phát triển làm việc với yêu cầu HTTP một cách Pythonic
hơn.
Requests cho phép bạn gửi các yêu cầu HTTP sử dụng các phương thức HTTP
khác nhau như GET, POST, PUT, DELETE và nhiều hơn nữa. Nó cũng hỗ trợ truyền
tham số URL, thiết lập tiêu đề tùy chỉnh và xử lý cookie. Thư viện này cũng có thể xử lý
xác thực, quản lý phiên và chuyển hướng.
49
Ví dụ:
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:
3.2.
Xây dựng các thành phần chí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. Để 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ụ.
50
Hình 3.5. 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.
Các hình dưới đây mô tả một phần đoạn mã hàm thực hiện chức năng tấn công đối
với 3 loại lỗ hổng:
 SQL Injection:
51
Hình 3.6. Thành phần tấn công với lỗ hổng SQL injection
 Cross-Site Scripting (XSS):
Hình 3.7. Thành phần tấn công với lỗ hổng XSS

 File Inclusion:
52
Hình 3.8. Thành phần tấn công với lỗ hổng File inclusion
- 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.
Các hình dưới đây mô tả một phần đoạn mã hàm thực hiện chức năng phân tích
đối với 3 loại lỗ hổng:
 SQL Injection:
Hình 3.9. Thành phần phân tích với lỗ hổng SQL injection
 Cross-Site Scripting(XSS):
Hình 3.10. Thành phần phân tích với lỗ hổng XSS

 File Inclusion:
53
Hình 3.11. Thành phần phân tích với lỗ hổng File inclusion
4. Triển khai, thử nghiệm
Ứng dụng kiểm tra lỗ hổng website được xây dựng trên phiên bản python 3.x cùng
với đó là các thư viện yêu cầu như bs4, prettytable, requests
Ứng dụng được xây dựng dưới dạng một tool kiểm thử và được giao tiếp bằng
dòng lệnh .
Hình 3.12. Giao diện ứng dụng

4.1. 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 chạy lệnh
python fuzzing.py -u [TARGET URL] -c
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.
4.2. SQL Injection scan
54
Chức năng này để người dùng thực hiện 2 chức năng crawl url và scan sql
injection thông qua việc phân tích url rồi chèn các payload để gửi yêu cầu lên server.
python fuzzing.py -u [TARGET URL] -s
hoặc python fuzzing.py -u [TARGET URL] --sql
Kết quả trả về là danh sách các đường dẫn khác nhau của website mà có thể có sự
hiện diện của sql injection.
4.3. Cross-Site Scripting scan
Chức năng này để người dùng thực hiện 2 chức năng crawl url và scan sql
injection thông qua việc phân tích url rồi chèn các payload để gửi yêu cầu lên server.
python fuzzing.py -u [TARGET URL] -s
hoặc python fuzzing.py -u [TARGET URL] --sql
hiện diện của sql injection.
4.4. File Inclusion
Chức năng này để người dùng thực hiện 2 chức năng crawl url và scan File Inclusion
thông qua việc phân tích url rồi chèn các payload để gửi yêu cầu lên server.
python fuzzing.py -u [TARGET URL] -f
hoặc python python fuzzing.py -u [TARGET URL] --file
hiện diện của File Inclusion.
4.5. Auto scan
Chức năng này để người dùng thực hiện 2 chức năng crawl url và sẽ scan tự động toàn
bộ trang web để tìm các lỗ hổng, chức năng này là sự kết hợp của cả ba chức năng phía
trên và để giảm thời gian chúng ta sẽ sử dụng kỹ thuật lập trình đa luồng để triển khai.
python fuzzing.py -u [TARGET URL] -f
hoặc python python fuzzing.py -u [TARGET URL] --file
55
Kết quả trả về là danh sách các đường dẫn khác nhau của website mà có thể có sự hiện
diện của File Inclusion.
5. Thử nghiệm, đánh giá

5.1. Dữ liệu
Dữ liệu đầu vào là một website được acunetix phát triển và triển khai lên mạng
được sử dụng làm lab cho quá trình pentest:
http://testphp.vulnweb.com/categories.php
Hình 3.13. Website thử nghiệm

5.2. Kết quả
 SQL Injection:
Hình 3.14. Các lỗ hổng SQL Injection được phát hiện

 Cross-Site Scripting(XSS):
56
Hình 3.15. Các lỗ hổng XSS được phát hiện
 File Inclusion:
Hình 3.16. Các lỗ hổng File Inclusion được phát hiện
57
Hình 3.17. Các lỗ hổng được phát hiện
5.3. Đánh giá
5.3.1. Ư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.
- 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.
5.3.2. 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ỏ só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.
6. Kết luận chương 3
Trong chương 3, 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
Python 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.
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.
58
TỔNG KẾT CHUNG
Sau quá trình nghiên cứu và thực hiện đồ án theo mục tiêu ban đầu về kỹ thuật
fuzzing trong kiểm tra lỗ hổng bảo mật website, đồ án đã đạt được một số kết quả
tích cực. Cụ thể, đã xây dựng được nền tảng lý thuyết về hoạt động của website, phân
loại các lỗ hổng bảo mật và cách khắc phục tương ứng, từ đó mở đường cho việc
nghiên cứu và phát hiện lỗ hổng bảo mật web. Bên cạnh đó, đồ án cũng đã tổng hợp
và phân tích các phương pháp kiểm thử phần mềm, đi sâu vào kỹ thuật fuzzing trong
kiểm thử hộp đen và áp dụng vào kiểm thử bảo mật ứng dụng web.
Tuy nhiên, trong quá trình thử nghiệm, một số hạn chế vẫn tồn tại. Quá trình
quét và phát hiện lỗ hổng còn chậm do chưa tối ưu hóa được số lượng yêu cầu gửi đi,
gây ra tình trạng giảm tốc độ xử lý. Đồng thời, các mô hình website phức tạp chưa
được xử lý đa dạng, và kết quả phát hiện lỗ hổng chỉ mang tính tương đối, chưa đạt
độ chính xác cao.
59
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] 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.
Tiếng Anh
[6] Glenford J. Myers (2004), “The Art of software testing”, Canada.
[7] IEEE 610.12:1990 (1990), “Standard Glossary of Software Engineering
Terminology”, IEEE Standards Board, United States of America.
[8] Justin Clarke (2009), “SQL Injection Attacks and Defense”, Gotham Digital
Science, UK.
[9] OWASP (2013), “The ten most critical web application security risks”,
OWASP, USA.
[10] OWASP (2009), “Testing Guide 4.0”, OWASP, USA.
[11] The Internet Society (1999), “Request for Comments (RFC) 2616”, Internet
Engineering Task Force - IETF, USA.
Website
[12] http://securitydaily.net/cac-phuong-phap-kiem-tra-ung-dung-web/
[13] http://kcntt.duytan.edu.vn/Home/ArticleDetail/vn/128/2461/bai-01-so-luoc-ve-
fuzzing-testing
[14] https://vi.wikipedia.org/wiki
[15] https://itsecuritykma.blogspot.com/2014/01/tim-hieu-web-application-1.html
https://viblo.asia/tran.thi.huong.trang/posts/RQqKLM64Z7z
60
61
LỜI CẢM ƠN
Nhóm chúng em xin gửi lời cảm ơn chân thành nhất đến thầy Bùi Việt Thắng, giảng
viên khoa An toàn thông tin, Học viện Kỹ thuật mật mã đã hướng dẫn và chỉ bảo chúng
em trong quá trình thực hiện báo cáo này. Sự hỗ trợ của thầy đã giúp chúng em có thêm
nhiều kiến thức mới cũng như học được nhiều kỹ năng mới để phục vụ cho tương lai sau
này.
62
BẢNG PHÂN CÔNG NHIỆM VỤ
Nội dung Minh Đức Anh Đức Hoàng Khánh Phương
Mục lục, danh mục kí hiệu, x x

chữ viết tắt và giải thích
Lời nói đầu x
Chương 1 Giới thiệu về x x

ứng dụng web,
kiểm thử phần
mềm, kiểm thử
web
Kỹ thuật x
fuzzing
Chương 2 Các giai đoạn x x x

trong kiểm thử
fuzzing,
phương pháp
phát hiện lỗ
hổng bảo mật,
các lỗ hổng
được phát hiện
bởi kiểm thử
fuzzing
Thu thập các x x

điểm đầu vào,
nguyên lý chèn
dữ liệu fuzz
Chương 3 x x x x x
Tổng kết chung, tài liệu tham x x

khảo, lời cảm ơn
63
Chỉnh sửa báo cáo x x
64

Nhóm 7 Báo Cáo Chính TH C

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

Nhóm 7 Báo Cáo Chính TH C

Uploaded by

Copyright:

Available Formats

BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KĨ THUẬT MẬT MÃ

ĐỀ CƯƠNG CHI TIẾT HỌC PHẦN

Đề Tài: Kiểm thử Fuzzing ứng dụng Web

Ngành: An toàn thông tin

Sinh viên thực hiện:

Người hướng dẫn : TS. Bùi Việt Thắng

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

Chương 1: Tổng quan về kiểm thử bảo mật website

1. Giới thiệu về ứng dụng web

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

Top 10 OWASP 2013

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

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 password=

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

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

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

5.2. Ưu nhược điểm của kiểm thử fuzzing

1. Các giai đoạn trong kiểm thử Fuzzing

1.1.Xác định mục tiêu (Identify target)

1. Command line arguments

2. Environment variables (ShareFuzz)

3. Web applications (WebFuzz)

4. File formats (FileFuzz)

5. Network protocols (SPIKE)

7. COM objects (COMRaider)

8. Inter Process Communication

2.2.Quy trình thu thập

Hình 2. 2 Mô hình thu thập URL theo mã HTML

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

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

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.

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

3.2. Chèn dữ liệu với phương thức post

Kiểu FORM POST

URL POST /index.php HTTP/1.1

Ví POST /index.php HTTP/1.1

Phương pháp Lỗ hổng áp

Dựa trên thông

Dựa trên các lỗi

Đầ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

5. Các lỗ hổng được phát hiện bởi kiểm thử Fuzzing

Hình 3.1. Kiến trúc phân tầng của ứng dụng

Hình 3.2. Luồng xử lý chức năng thu thập URL

Hình 3.3. Luồng xử lý chức năng quét lỗ hổng website

Hình 3.4. Giao tiếp giữa Fuzzer và Server