Tìm hiểu bài toán web an toàn và đề xuất giải pháp Firewall cho các ứng dụng web

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------

Đỗ Đức Ngun

TÌM HIỂU BÀI TỐN WEB AN TỒN VÀ
ĐỀ XUẤT GIẢI PHÁP FIREWALL CHO CÁC ỨNG DỤNG WEB

Chuyên ngành: Mạng máy tính và truyền thơng dữ liệu

LUẬN VĂN THẠC SĨ KỸ THUẬT
MẠNG MÁY TÍNH VÀ TRUYỀN THƠNG DỮ LIỆU

NGƯỜI HƯỚNG DẪN KHOA HỌC

TS. Phạm Huy Hoàng

Hà Nội – Năm 2018


Mục lục
LỜI CAM ĐOAN ................................................................................................................ 3
LỜI CẢM ƠN ...................................................................................................................... 4
DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT ......................................................... 5
DANH MỤC CÁC BẢNG .................................................................................................. 6
DANH MỤC CÁC HÌNH VẼ ............................................................................................. 7
CHƯƠNG 1: MỞ ĐẦU ....................................................................................................... 8
1. Lý do chọn đề tài ....................................................................................................... 8
2. Nhiệm vụ đặt ra cho đề tài......................................................................................... 8
3. Hướng tiếp cận và giải quyết..................................................................................... 9

4. Bố cục của luận văn ................................................................................................... 9
CHƯƠNG 2: ỨNG DỤNG WEB VÀ CÁC LỖ HỔNG BẢO MẬT PHỔ BIẾN TRONG
ỨNG DỤNG WEB ............................................................................................................ 11
1. Khái niệm ứng dụng web ........................................................................................ 11
2. Các lỗ hổng bảo mật phổ biến trong ứng dụng web................................................ 11
2.1.

Giới thiệu về Open Web Application Security Project (OWASP) ................... 11

2.2.

Lịch sử của OWASP Top 10 ............................................................................ 12

2.3.

A1 - Lỗi nhúng mã – Injection ......................................................................... 15

2.4.

A2 – Phá vỡ tính xác thực – Broken Authentication ........................................ 15

2.5.

A3 – Để lộ các dữ liệu nhạy cảm – Sensitive Data Exposure .......................... 15

2.6.

A4 – Thực thể bên ngoài XML - XML External Entities (XXE) .................... 16

2.7.

A5 – Phá vỡ kiểm soát truy cập – Broken access control ................................ 16

2.8.

A6 – Sai sót trong cấu hình an ninh – Security Misconfiguration ................... 16

2.9.

A7 - Thực thi mã script – Cross-Site Scripting (XSS) .................................... 17

2.10.

A8 – Giải tuần tự hóa khơng an tồn - Insecure Deserialization .................. 17

2.11. A9 – Sử dụng các thành phần có lỗ hổng đã biết – Using Components with
Known Vulnerabilities ................................................................................................ 17
2.12.

A10 – Không đủ nhật ký giám sát – Insufficient Logging & Monitoring .... 18

CHƯƠNG 3: ĐỀ XUẤT GIẢI PHÁP TƯỜNG LỬA ỨNG DỤNG WEB ..................... 19
Trang 1


1. Tại sao cần tường lửa ứng dụng web? ..................................................................... 19
2. Đề xuất giải pháp tường lửa mã nguồn mở ModSecurity ....................................... 19
2.1.

Lý do lựa chọn giải pháp mã nguồn mở ........................................................... 19

2.2.

Các giải pháp tường lửa mã nguồn mở............................................................. 20

2.3.

Giới thiệu ModSecurity .................................................................................... 21

2.4.

Hoạt động của ModSecurity ............................................................................. 21

3. Mơ hình triển khai và hướng dẫn cài đặt ................................................................. 23
3.1.

Mơ hình triển khai ............................................................................................ 23

3.2.

Hướng dẫn cài đặt ............................................................................................. 26

4. Tìm hiểu về rule ...................................................................................................... 27
5. Thử nghiệm một số kịch bản tấn công khai thác lỗ hổng ....................................... 28
5.1.

Tổng quan kịch bản thử nghiệm ....................................................................... 28

5.2.

Thử nghiệm khai thác lỗ hổng nhúng mã – Injection ....................................... 29

5.3.

Thử nghiệm khai thác lỗ hổng phá vỡ tính xác thực – Broken Authentication 34

5.4.

Thử nghiệm khai thác lỗ hổng thực thi mã script XSS .................................... 40

5.5.

Đánh giá mức độ an toàn của một số website cụ thể........................................ 43

CHƯƠNG 4: KẾT LUẬN ................................................................................................. 50
TÀI LIỆU THAM KHẢO ................................................................................................. 52

Trang 2


LỜI CAM ĐOAN
Tôi xin cam đoan đề tài nghiên cứu của tơi hồn tồn do tơi tự làm dưới sự hướng dẫn
của thầy giáo TS.Phạm Huy Hoàng. Những kết quả tìm hiểu và nghiên cứu trình bày trong
luận văn là hồn tồn trung thực và chưa từng được cơng bố trong bất cứ cơng trình nào.
Nếu xảy ra bất cứ điều không đúng như những lời cam đoan trên, tôi xin chịu hoàn toàn
trách nhiệm trước Viện và Nhà trường.

Ngày 15 tháng 09 năm 2018
Học viên

Đỗ Đức Nguyên

Trang 3


LỜI CẢM ƠN
Em xin chân thành cảm ơn thầy giáo TS.Phạm Huy Hồng đã có những hướng dẫn và
góp ý q báu giúp em hồn thành luận văn của mình.
Em xin gửi lời cảm ơn đến các thầy cô giáo viện Công nghệ thông tin và truyền thông
trường Đại học Bách Khoa Hà Nội đã hướng dẫn và đưa ra những lời khuyên bổ ích.
Cuối cùng, em xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp và người thân đã
động viên, giúp đỡ trong quá trình thực hiện đồ án tốt nghiệp.
Xin chân thành cảm ơn tất cả!

Trang 4


DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT
THUẬT NGỮ

GIẢI THÍCH

WAF

Web Application Firewall: Tường lửa ứng dụng web

FIREWALL

Tường lửa

WEBAPP

Ứng dụng web

HTTP (S)

Hypertext Transfer Protocol (Secure): Giao thức truyền tải
siêu văn bản (bảo mật)

OWASP

Open Web Application Security Project: Dự án về bảo mật
ứng dụng web

OWASP TOP 10

Open Web Application Security Project top 10: 10 lỗ hổng
phổ biến nhất theo OWASP

DATABASE

Cơ sở dữ liệu

SQL

Structured Query Language: ngơn ngữ truy vấn mang tính
cấu trúc

VULNERABILITY

Lỗ hổng

PROXY

Máy chủ trung gian giữa người dùng và máy chủ web

URL

Uniform Resource Locator: Định vị Tài nguyên thống nhất

ID

Identification: Định danh

XML

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

BRUTE FORCE

Một kiểu tấn công bảo mật

CRS

Core Rule Set: Bộ quy tắc cốt lõi

Trang 5


DANH MỤC CÁC BẢNG

Bảng
Bảng 3.1

Mô tả
So sánh giữa các giải pháp firewall

Trang 6

Trang
22


DANH MỤC CÁC HÌNH VẼ
Hình

Mơ tả

Trang

Hình 2.1

Ứng dụng web

11

Hình 2.2

Các tiêu chí đánh giá rủi ro lỗ hổng

12

Hình 3.1

Các pha trong hoạt động của ModSecurity

23

Hình 3.2

Mơ hình tích hợp vào web server (embedded)

25

Hình 3.3

Mơ hình tích hợp reverse proxy

27

Hình 3.4

Mơ hình thử nghiệm

29

Hình 3.5

Máy chủ web OWASP Mutillidae

30

Hình 5.1

Giao diện WAF-FLE

53

Hình 5.2

Các giải pháp WAF chuyên dụng

53

Trang 7


CHƯƠNG 1: MỞ ĐẦU
1. Lý do chọn đề tài
Thực trạng an tồn thơng tin tại Việt Nam ngày càng diễn biến phức tạp và nguy hiểm.
Các cuộc tấn công mạng có quy mơ, mức độ phức tạp và được chuẩn bị một cách kỹ lưỡng.
Trong đó, các mục tiêu tấn công đang dần chuyển dịch từ các mục tiêu cá nhân, sang các
mục tiêu là các tập đoàn kinh tế lớn hay nghiêm trọng hơn là các hệ thống thông tin quan
trọng của các quốc gia. Hàng loạt các hệ thống website của các Ngân hàng lớn, doanh
nghiệp lớn đã bị tấn công gây thiệt hại đáng kể [19].
Thực tế với tình hình hiện nay, các ứng dụng web ngày một nhiều. Sự thay đổi chóng
mặt của cơng nghệ đã giúp ứng dụng web được cải tiến nâng cao rất nhiều, và vấn đề bảo
mật cho ứng dụng web không ngừng tăng lên. Một khi ứng dụng web bị rò rỉ lỗ hổng, các
tin tặc sẽ dễ dàng chiếm quyền quản trị web, ứng dụng và phần mềm của công ty. Nguyên
nhân dẫn đến các ứng dụng web bị rò rỉ thông tin, các nguy cơ về lỗ hổng, là do các đoạn
mã lệnh, mã code không phù hợp trong ứng dụng web. Chỉ cần một lỗ hổng, tin tặc cũng

có thể xâm nhập và truy cập vào cơ sở dữ liệu, thông tin và thực hiện các hành vi sai trái
như đánh cắp, thay đổi, chỉnh sửa, mã hóa dữ liệu…[11].
Để đối phó với các nguy cơ rủi ro đó, có rất nhiều cơng cụ, giải pháp được phát triển
nhằm mục đích bảo vệ các ứng dụng web khỏi các lỗi bảo mật và các cuộc tấn công, mã
độc từ tin tặc.Các giải pháp đó được gọi là tường lửa ứng dụng web (Web Application
Firewall – WAF). WAF là một thiết bị phần cứng hoặc phần mềm được cài lên máy chủ
có chức năng theo dõi các thơng tin được truyền qua giao thức http/https giữa trình duyệt
của người dùng và máy chủ web tại lớp 7. Một WAF có khả năng thực thi các chính sách
bảo mật dựa trên các dấu hiệu tấn công, các giao thức tiêu chuẩn và các lưu lượng truy cập
ứng dụng web bất thường. Đây là điều mà các tường lửa mạng khác khơng làm được.
Với mong muốn phân tích và tìm hiểu sâu hơn về các lỗ hổng trong ứng dụng web cũng
như phương thức hoạt động, khả năng ngăn chặn của WAF, học viên đã lựa chọn đề tài
“Tìm hiểu bài tốn Web an tồn và đề xuất giải pháp Firewall cho các ứng dụng Web”
làm luận văn tốt nghiệp của mình.
2. Nhiệm vụ đặt ra cho đề tài
Nhiệm vụ của đề tài này là tìm hiểu các lỗ hổng bảo mật trong ứng dụng web và đề xuất
một giải pháp WAF để bảo vệ ứng dụng web khỏi các lỗ hổng bảo mật đó. Trong đó:

Trang 8


[1] Tìm hiểu các lỗ hổng bảo mật trong ứng dụng web là: tìm hiểu về 10 lỗ hổng tiêu
biểu theo tổ chức OWASP đánh giá vào năm 2017 (OWASP Top 10)
[2] Giải pháp WAF được đề xuất cần đạt được các nhiệm vụ sau:
- Giải pháp có thể ngăn chặn được tin tặc khai thác các lỗ hổng tiêu biểu.
- Giải pháp phải cho phép người quản trị có thể cấu hình chính sách một cách linh
-

hoạt.
Giải pháp phải có khả năng triển khai và áp dụng vào thực tế.

3. Hướng tiếp cận và giải quyết
Đầu tiên học viên cần tìm hiểu về danh sách các lỗ hổng bảo mật tiêu biểu theo tổ chức
OWASP đánh giá. Danh sách đánh giá cần được đảm bảo là mới nhất khi thực hiện đề tài.
Để quá trình tìm hiểu được hiệu quả, việc cài đặt một máy chủ web chứa các lỗ hổng để có
thể tiến hành khai thác thử là cần thiết. Việc nắm vững các lỗ hổng sẽ là điều kiện tiên
quyết để học viên có thể thực hiện nhiệm vụ tiếp theo là đề xuất một giải pháp WAF.
Trong phạm vi nghiên cứu luận văn, một giải pháp WAF mã nguồn mở là lựa chọn hợp
lý. Tuy nhiên, giải pháp vẫn cần phải đáp ứng các nhiệm vụ đã đặt ra tại phần 2. Học viên
cần phân tích và chỉ ra sự khác nhau cũng như lợi ích đem lại của hệ thống trước khi và
sau khi triển khai WAF.
Các nội dụng thực hiện trong đề tài:
Tìm hiểu các lỗ hổng bảo mật trong ứng dụng web (OWASP Top 10)
Tìm hiểu, cài đặt, thử nghiệm một máy chủ web chứa các lỗ hổng và một phần mềm
mã nguồn mở WAF ModSecurity
- Xây dựng bộ chính sách ngăn chặn khai thác các lỗ hổng
- Thử nghiệm giải pháp bằng cách khai thác các lỗ hổng và so sánh kết quả trước khi
và sau khi triển khai WAF.
4. Bố cục của luận văn
Bố cục luận văn được chia thành 5 chương như sau:
-

Chương 1: Mở đầu: Mô tả chi tiết về mục tiêu, nhiệm vụ đề tài và hướng tiếp cận.
Chương 2: Ứng dụng web và các lỗ hổng bảo mật trong ứng dụng web : Nghiên
cứu cơ sở lý thuyết về ứng dụng web và các lỗ hổng bảo mật trong ứng dụng web theo
đánh giá của tổ chức OWASP.
Chương 3: Đề xuất giải pháp tường lửa ứng dụng web: Tìm hiểu và đề xuất một giải
pháp tường lửa ứng dụng web, bao gồm các nội dung: (1) Giới thiệu giải pháp, (2) Mơ hình

Trang 9

triển khai và hướng dẫn cài đặt, (3) Cấu hình chính sách, (4) Thử nghiệm một số kịch bản
tấn cơng khai thác lỗ hổng.
Chương 4: Đánh giá kết quả: Đưa ra đánh giá dựa trên kết quả thử nghiệm và đưa ra
kết quả so sánh với nhiệm vụ ban đầu đã đề ra.
Chương 5: Kết luận: Đưa ra kết luận, tự nhận xét các ưu điểm và hạn chế, định hướng
phát triển và áp dụng vào thực tế.

Trang 10


CHƯƠNG 2: ỨNG DỤNG WEB VÀ CÁC LỖ HỔNG BẢO MẬT PHỔ BIẾN
TRONG ỨNG DỤNG WEB
1. Khái niệm ứng dụng web
Trong kỹ thuật phần mềm, một ứng dụng web là một trình ứng dụng mà có thể tiếp cận
qua web thông qua mạng như internet hay intranet. Ứng dụng web phổ biến nhờ vào sự có
mặt vào bất cứ nơi đâu của một chương trình. Khả năng cập nhật và bảo trì ứng dụng web
mà khơng phải phân phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho
sự phổ biến của nó. Ứng dụng web được dùng để hiện thực Webmail, bán hàng trực tuyến,
đấu giá trực tuyến, wiki, diễn đàn thảo luận, Weblog, MMORPG, Hệ quản trị nội dung,
Phần mềm quản lý nguồn nhân lực và nhiều chức năng khác [8].
Tuy nhiên tính tương tác cao của ứng dụng web cũng gây ra nhiều rủi ro về bảo mật.
Nếu ứng dụng web tồn tại lỗ hổng thì tin tặc có thể xâm nhập và thực hiện các hành vi xấu
như giả mạo, đánh cắp thông tin, tấn công phá hoại, gián đoạn dịch vụ, … 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 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. Phần tiếp theo chúng ta cùng đi tìm hiểu về các lỗ hổng phổ
biến trong ứng dụng web.
2. Các lỗ hổng bảo mật phổ biến trong ứng dụng web

2.1. Giới thiệu về Open Web Application Security Project (OWASP)
OWASP là một tổ chức bao gồm các chuyên gia bảo mật hàng đầu thế giới, chuyên cung
cấp các thông tin về những ứng dụng và rủi ro đặt ra một cách trực tiếp, khách quan và
thực tế nhất, đặc biệt là ứng dụng web. Định kỳ, OWASP tiến hành đánh giá và công bố
danh sách Top 10 các rủi ro bảo mật ứng dụng lớn nhất, được gọi là OWASP Top 10 [14].
Mục tiêu chính của OWASP Top 10 là để hướng dẫn cho những người tham gia vào xây
dựng hệ thống, quản trị hệ thống, bảo mật hệ thống hiểu về các lỗ hổng và hậu quả của nó
có thể gây ra. Dựa vào phương pháp đánh giá rủi ro bao gồm các tiêu chí như khả năng
khai thác, mức độ phổ biến, khả năng phát hiện, ảnh hưởng,…

Trang 11


Hình 2.2: Các tiêu chí đánh giá rủi ro lỗ hổng [6]
Tiếp theo chúng ta cùng tìm hiểu lịch sử của OWASP TOP 10.
2.2. Lịch sử của OWASP Top 10
OWASP được thành lập vào năm 2001. Năm 2003, tổ chức lần đầu tiên đưa ra danh
sách 10 lỗ hổng tiêu biểu. Gọi là OWASP Top 10 – 2003. Danh sách bao gồm như sau:
• A1 2003 - Unvalidated Input
• A2 2003 - Missing Functional Level Access Control
• A3 2003 - Broken Authentication and Session Management
• A4 2003 - Cross Site Scripting (XSS)
• A5 2003 - Buffer Overflows
• A6 2003 - Injection
• A7 2003 - Information Leakage and Improper Error Handling
• A8 2003 - Sensitive Data Exposure
• A9 2003 - Remote Administration Flaws
• A10 2003 - Security Misconfiguration
Tuy nhiên, một năm sau đó tổ chức có tiến hành cập nhật danh sách Top 10 để phù hợp
với hiện trạng của an tồn thơng tin trên thế giới thời điểm đó. Gọi là OWASP Top 10 –

2004. Từ năm 2004, OWASP tiến hành đánh giá và bình chọn danh sách 3 năm 1 lần (đến
năm 2013). Danh sách OWASP Top 10 – 2004 bao gồm:
• A1 2004 - Unvalidated Input
• A2 2004 - Broken Access Control
• A3 2004 - Broken Authentication and Session Management
• A4 2004 - Cross Site Scripting
• A5 2004 - Buffer Overflow
• A6 2004 - Injection Flaws
Trang 12


• A7 2004 - Improper Error Handling
• A8 2004 - Insecure Storage
• A9 2004 - Application Denial of Service
• A10 2004 - Insecure Configuration Management
Ta nhận thấy rằng việc thay đổi giữa 2004 và 2003 là không nhiều. Chủ yếu là thay đổi
các tên gọi cho phù hợp. Ba năm sau, OWASP tiến hành đánh giá và đưa ra danh sách Top
10 – 2007. Danh sách như sau:
• A1 2007 - Cross Site Scripting (XSS)
• A2 2007 - Injection Flaws
• A3 2007 - Malicious File Execution
• A4 2007 - Insecure Direct Object Reference
• A5 2007 - Cross Site Request Forgery (CSRF)
• A6 2007 - Information Leakage and Improper Error Handling
• A7 2007 - Broken Authentication and Session Management
• A8 2007 - Insecure Cryptographic Storage
• A9 2007 - Insecure Communications
• A10 2007 - Failure to Restrict URL Access
Đã có sự thay đổi rõ rệt so với năm 2004. Các lỗ hổng A1 2004 - Unvalidated Input, A5
2004 - Buffer Overflow, A9 2004 - Application Denial of Service, A10 2004 - Insecure

Configuration Management đã được thay thế bằng các lỗ hổng mới: A3 2007 - Malicious
File Execution, A5 2007 - Cross Site Request Forgery (CSRF), A9 2007 - Insecure
Communications và A10 2007 - Failure to Restrict URL Access. Sau đó 3 năm, OWASP
tiến hành đánh giá và đưa ra danh sách Top 10 – 2010. Danh sách như sau:
• A1 2010 - Injection
• A2 2010 - Cross-Site Scripting (XSS)
• A3 2010 - Broken Authentication and Session Management
• A4 2010 - Insecure Direct Object References
• A5 2010 - Cross-Site Request Forgery (CSRF)
• A6 2010 - Security Misconfiguration
• A7 2010 - Insecure Cryptographic Storage
• A8 2010 - Failure to Restrict URL Access
• A9 2010 - Insufficient Transport Layer Protection
Trang 13


• A10 2010 - Unvalidated Redirects and Forwards
So với 2007, OWASP đã bỏ đi 2 lỗ hổng là A3 2007 - Malicious File Execution và A6
2007 - Information Leakage and Improper Error Handling. Đồng thời bổ sung 2 lỗ hổng
mới là A6 2010 - Security Misconfiguration và A10 2010 - Unvalidated Redirects and
Forwards. Sau đó 3 năm, OWASP tiếp tục tiến hành đánh giá và đưa ra danh sách Top 10
– 2013. Danh sách như sau:
• A1 2013 - Injection
• A2 2013 - Broken Authentication and Session Management
• A3 2013 - Cross-Site Scripting (XSS)
• A4 2013 - Insecure Direct Object References
• A5 2013 - Security Misconfiguration
• A6 2013 - Sensitive Data Exposure
• A7 2013 - Missing Function Level Access Control
• A8 2013 - Cross-Site Request Forgery (CSRF)

• A9 2013 - Using Known Vulnerable Components
• A10 2013 - Unvalidated Redirects and Forwards
Khơng có khác biệt nhiều so với năm 2010. OWASP đã tiến hành gộp A7 2010 Insecure Cryptographic Storage với A9 2010 - Insufficient Transport Layer Protection
thành A6 2013 - Sensitive Data Exposure. Đồng thời tách A6 2010 - Security
Misconfiguration thành A5 2013 - Security Misconfiguration và A9 2013 - Using Known
Vulnerable Components. Sau đó 4 năm, OWASP tiếp tục đánh giá theo chu kỳ mới và đưa
ra danh sách Top 10 – 2017. Đây cũng là danh sách mới nhất tính đến thời điểm hiện tại.
Chi tiết như sau:
• A1 2017 - Injection
• A2 2017 - Broken Authentication
• A3 2017 - Sensitive Data Exposure
• A4 2017 - XML External Entities (XXE)
• A5 2017 - Broken Access Control
• A6 2017 - Security Misconfiguration
• A7 2017 - Cross-Site Scripting (XSS)
• A8 2017 - Insecure Deserialization
• A9 2017 - Using Components with Known Vulnerabilities
Trang 14


• A10 2017 - Insufficient Logging&Monitoring
OWASP đã tiến hành gộp A4 2013 - Insecure Direct Object References và A7 2013 Missing Function Level Access Control thành A5 2017 - Broken Access Control. Sau đó
bỏ đi A8 2013 - Cross-Site Request Forgery (CSRF) và A10 2013 - Unvalidated Redirects
and Forwards. Đồng thời bổ sung A4 2017 - XML External Entities (XXE) và A10 2017 Insufficient Logging&Monitoring. Phần tiếp thheo, chúng ta sẽ đi tìm hiểu và phân tích chi
tiết hơn về các lỗ hổng trong danh sách OWASP Top 10 – 2017.
2.3.

A1 - Lỗi nhúng mã – Injection

Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

3 (dễ dàng)

2 (phổ biến)

3 (dễ dàng)

3 (nghiêm trọng)

Lỗ hổng Injection là kết quả của sự thiếu sót trong việc lọc các đầu vào khơng đáng tin
cậy. Nó có thể xảy ra khi bạn truyền các dữ liệu chưa được lọc tới Database (SQL injection),
tới trình duyệt (XSS), tới máy chủ LDAP (LDAP Injection) hoặc tới bất cứ vị trí nào khác
[14,15]. Trong các loại lỗ hổng Injection, phổ biến nhất là tấn công SQL, còn được biết
đến là SQLi. SQL injection là một kỹ thuật 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ề để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp [15].
2.4.

A2 – Phá vỡ tính xác thực – Broken Authentication

Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

3 (dễ dàng)

2 (phổ biến)

2 (trung bình)

3 (nghiêm trọng)

Khi các chức năng của ứng dụng được thực hiện không chính xác, tin tặc có thể dễ dàng
xâm nhập, ăn cắp thông tin tài khoản, mật khẩu và khai thác các lỗ hổng khác bằng cách
sử dụng các chứng chỉ đã đánh cắp. Tài khoản mỗi người dùng cá nhân nên là duy nhất,
khơng bị trùng lặp dưới bất kì hình thức nào. Nếu khơng có bất kì sự quản lý cần thiết nào
thì tin tặc có thể lẻn vào, ngụy trang thành người dùng để ăn cắp thông tin tài khoản, mật
khẩu và sử dụng cho những lần truy cập sau này [14,15].
2.5. A3 – Để lộ các dữ liệu nhạy cảm – Sensitive Data Exposure
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

2 (trung bình)

3 (rộng rãi)

2 (trung bình)

3 (nghiêm trọng)

Trang 15


Việc tiếp xúc dữ liệu nhạy cảm xảy ra khi các kiểm sốt bảo mật, giúp tin tặc có thể ăn
cắp thông tin tài khoản, mật khẩu, địa chỉ hay bất cứ thơng tin có giá trị nào khác. Vì vậy,
các ứng dụng cần đảm bảo truy cập được xác thực và dữ liệu đã được mã hóa [14,15]. Sai
lầm phổ biến chủ yếu là khơng mã hóa các dữ liệu cần được mã hóa. Các tổ chức cần xác
định đâu là dữ liệu quan trọng của mình và tiến hành mã hóa nó.
2.6.

A4 – Thực thể bên ngồi XML - XML External Entities (XXE)

Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

2 (trung bình)

2 (phổ biến)

3 (dễ dàng)

3 (nghiêm trọng)

Khai báo external entity tronng XML chính là điểm mấu chốt trong kỹ thuật tấn công
XXE. Kỹ thuật tấn công này dựa vào việc cho phép khai báo External Entity trong phần
kiểu tài liệu của dữ liệu XML. Tin tặc có thể khai báo một thực thể để đọc nội dung của
file bất kỳ trong hệ thống nếu trình phân tích XML (parser) được cấu hình khơng tốt [16].
2.7. A5 – Phá vỡ kiểm soát truy cập – Broken access control
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

2 (trung bình)

2 (phổ biến)

2 (trung bình)

3 (nghiêm trọng)

Kiểm sốt truy cập nhằm mục đích kiểm sốt người dùng được ủy quyền được phép hay
không được phép làm gì trong một ứng dụng và để thiết lập quyền kiểm sốt truy cập một
cách hợp lí, ứng dụng phải đảm bảo rằng nó đang nghiêm túc thực hiện kiểm tra ủy quyền
và xác thực hợp lệ để xác định người dùng được đặc quyền, thực tế là những người dùng
Internet ngẫu nhiên. Việc bị khai thác thường dẫn đến việc tiết lộ thông tin trái phép, sửa
đổi dữ liệu hoặc thực hiện chức năng nào đó ngồi giới hạn của người dùng [14,15].

2.8. A6 – Sai sót trong cấu hình an ninh – Security Misconfiguration
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

3 (dễ dàng)

3 (rộng rãi)

3 (dễ dàng)

2 (trung bình)

Một cơ chế an ninh tốt cần phải định nghĩa những hiệu chỉnh về an ninh và triển khai nó
cho các ứng dụng, khn mẫu, máy chủ ứng dụng, máy chủ web, máy chủ dữ liệu và các
ứng dụng nền tảng. Tất cả các thiết lập nên được định nghĩa, thực hiện và bảo trì bởi rất
nhiều thứ khơng được triển khai với thiết lập an tồn mặc định. Các hiệu chỉnh cũng bao
gồm cập nhật phần mềm và những thư viện được sử dụng bởi ứng dụng. Người phát triển
và nhà quản trị mạng cần phải làm việc cùng nhau để đảm bảo rằng từng lớp được hiệu
Trang 16


chỉnh một cách đúng đắn. Những công cụ quét tự động cũng có thể hữu ích trong việc phát
hiện những bản vá lỗi bị thiếu, sai sót trong cấu hình hoặc sử dụng những tài khoản mặc
định, những dịch vụ không cần thiết.
2.9. A7 - Thực thi mã script – Cross-Site Scripting (XSS)

Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

3 (dễ dàng)

3 (rộng rãi)

3 (dễ dàng)

2 (trung bình)

XSS là một lỗ hổng thường thấy trong các ứng dụng web. XSS cho phép tin tặc đưa các
kịch bản phía máy khách vào các trang web cơng cộng và trong nhiều trường hợp, tin tặc
có thể sử dụng các cơng cụ kiểm sốt truy cập của họ. Chúng thực hiện bằng cách đánh lừa
trình duyệt chấp nhận dữ liệu từ một nguồn không đáng tin cậy. Điều này thường xảy ra
khi tin tặc sử dụng mã quen thuộc (ví dụ như JavaScript) vì các nhà phát triển ứng dụng
khơng loại trừ các kí tự này [14,15].
Các ứng dụng cho phép người dùng nhập dữ liệu vào mà khơng có tồn quyền kiểm sốt
dữ liệu ra có nguy cơ bị tấn công XSS rất cao. Một cuộc tấn công XSS thành cơng có thể
gây thiệt hại nghiêm trọng cho các trang web và có khả năng kéo người dùng vào các trang
web khác (thường chứa nhiều mã độc hơn) [14,15].
2.10. A8 – Giải tuần tự hóa khơng an tồn - Insecure Deserialization
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

1 (khó)

2 (trung bình)

2 (trung bình)

3 (nghiêm trọng)

Giải tuần tự hóa khơng an tồn Insecure Deserialization là một lỗ hổng xảy ra khi dữ
liệu không tin cậy được sử dụng để lạm dụng sự logic của một ứng dụng, gây ra tấn công
từ chối dịch vụ (DoS) hoặc thậm chí thực thi mã tùy ý khi nó được giải tuần tự hóa. Tuy
nhiên, việc khai thác lỗ hổng này khá là khó khăn. Một số cơng cụ có thể phát hiện lỗ hổng
này, nhưng con người vẫn luôn luôn phải phân tích và xác nhận kết quả. Người ta hy vọng
rằng dữ liệu phổ biến cho loại lỗ hổng này sẽ tăng lên khi công cụ được phát triển để giúp
xác định và giải quyết nó.
2.11. A9 – Sử dụng các thành phần có lỗ hổng đã biết – Using Components with
Known Vulnerabilities
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

2 (trung bình)

3 (rộng rãi)

2 (trung bình)

2 (trung bình)

Trang 17


Việc sử dụng các thành phần có lỗ hổng đã biết là vơ cùng nguy hiểm vì các lỗ hổng đã
được công bố sẽ luôn kèm theo các hướng dẫn để khai thác. Nếu tổ chức của bạn vơ tình
gặp phải lỗi này, các tin tặc có thể dễ dàng tấn cơng theo các hướng dẫn có sẵn
2.12. A10 – Không đủ nhật ký giám sát – Insufficient Logging & Monitoring
Khả năng khai khác

Mức độ phổ biến

Khả năng phát hiện

Ảnh hưởng

2 (trung bình)

3 (rộng rãi)

1 (khó)

2 (trung bình)

Lỗ hổng khơng đủ nhật ký giám sát là nền tảng của gần như mọi sự cố lớn. Những kẻ
tấn công dựa vào sự thiếu giám sát và phản ứng kịp thời để đạt được mục tiêu của họ mà
không bị phát hiện. Một chiến lược để xác định xem bạn có giám sát đầy đủ hay không là
kiểm tra nhật ký sau thử nghiệm thâm nhập. Các hành động của người kiểm tra nên được
ghi lại đầy đủ để hiểu những thiệt hại mà kẻ tấn cơng có thể đã gây ra. Hầu hết các cuộc
tấn công thành công bắt đầu với thăm dò lỗ hổng. Việc cho phép các thăm dò tiếp tục như
vậy có thể tăng khả năng khai thác thành cơng lên gần 100%.
Trên đây chúng ta đã tìm hiểu về 10 lỗ hổng phổ biến nhất trong ứng dụng web. Những
lỗ hổng đều là nguy hiểm, sẽ gây ra thiệt hại lớn nếu tổ chức bị khai thác. Các thông tin về
lỗ hổng được công khai rộng rãi cho tất cả mọi người. Tin tặc thì ln nắm vững và hiểu
về nó. Nếu người quản trị khơng trang bị một kiến thức đủ tốt thì rất khó có thể chống lại
những đợt tấn công khai thác từ các tin tặc. Phần tiếp theo chúng ta cùng tiến hành khai
thác thử một số lỗ hổng để hiểu rõ hơn; đồng thời tiến hành tìm hiểu về một giải pháp có
thể ngăn chặn các tấn cơng vào lỗ hổng này. Giải pháp đó là tường lửa ứng dụng web –
Web Application Firewall (WAF).

Trang 18


CHƯƠNG 3: ĐỀ XUẤT GIẢI PHÁP TƯỜNG LỬA ỨNG DỤNG WEB
1. Tại sao cần tường lửa ứng dụng web?
Qua phân tích ở trên chúng ta thấy được rằng các ứng dụng web luôn tồn tại rất nhiều lỗ
hổng. Người quản trị thì ln nghĩ rằng hệ thống của tổ chức đang ổn, đang an toàn, đang
vận hành tốt. Tuy nhiên, chỉ khi hệ thống bị tấn công hoặc khai thác họ mới nhận ra rằng
hệ thống đã tồn tại rất nhiều lỗ hổng. Thông thường, các tường lửa mạng thường hoạt động
ở lớp 4 (tầng giao vận) nên không thể ngăn chặn được các tấn cơng khai thác.
Vì vậy, chúng ta có thể nhận thấy rằng việc xây dựng một tường lửa WAF để bảo vệ
cho các máy chủ ứng dụng web của các tổ chức, doanh nghiệp là vô cùng cần thiết. Tin tặc
luôn hiểu về các lỗ hổng và luôn biết cách làm thế nào để tiến hành khai thác. Nếu hệ thống

của bạn đang không được bảo vệ bởi một WAF, rất có khả năng trong tương lai hệ thống
của bạn sẽ là mục tiêu để các tin tặc tấn cơng. Hậu quả mà nó mang lại thì vơ cùng lớn, có
khi phải trả giá bằng cả một sự phát triển của doanh nghiệp.
Phần tiếp theo chúng ta cùng phân tích và tìm hiểu một giải pháp WAF cụ thể. Trong
phạm vi đồ án, đối tượng mà chúng ta hướng tới là một ứng dụng mã nguồn mở
ModSecurity.
2. Đề xuất giải pháp tường lửa mã nguồn mở ModSecurity
2.1. Lý do lựa chọn giải pháp mã nguồn mở
Các giải pháp mã nguồn mở luôn mang lại những lợi ích tuyệt vời cho các tổ chức. Khái
niệm mã nguồn mở khơng cịn xa lạ gì với các tổ chức, nhất là những tổ chức luôn quan
tâm đến vấn đề bản quyền và chi phí. Chúng ta cùng phân tích một số lợi ích mà phần mềm
mã nguồn mở mang lại:
• Chi phí thấp: Phần mềm mã nguồn mở thường là miễn phí, nơi có một cộng đồng
ln đóng góp và chia sẻ kiến thức. Các giải pháp chuyên dụng từ các hãng bảo mật
lớn thường sẽ tiêu tốn của tổ chức rất nhiểu tiền.
• Tính đa dạng: Các phần mềm mã nguồn mở ln có một cộng đồng cùng đóng góp
và phát triển các ý tưởng. Ngồi ra tính tùy biến dễ dàng cũng làm cho các phần
mềm mã nguồn mở trở lên vơ cùng đa dạng.
• Khả năng tùy biến và mở rộng cao: Việc các mã nguồn ln được cơng khai sẽ
giúp cho người quản trị có thể dễ dàng tùy biến cho phù hợp với tổ chức của mình.
• Tính năng hoặc bug được cập nhật liên tục: Việc có đội ngũ đóng góp đơng đảo
sẽ mang lại lợi thế cho các phần mềm mã nguồn mở khi luôn luôn được cập nhật
Trang 19


những ý tưởng mới, tính năng mới. Các lỗi được phát hiện bởi một cá nhân hoặc
một tổ chức nào đó cũng nhanh chóng được chia sẻ rộng rãi.
• Dễ dàng tiếp cận, nghiên cứu và tìm hiểu: Ưu điểm cuối cùng là việc vô cùng dễ
dàng tiếp cận và nghiên cứu. Khác với các giải pháp chuyên dụng luôn luôn rất chặt
chẽ trong việc bản quyền và phần mềm, mọi người đều có thể tiếp cận phần mềm

mã nguồn mở. Các tài liệu liên quan cũng luôn được chia sẻ rộng rãi với tất cả mọi
người.
Ở trên chúng ta đã đi vào phân tích những ưu điểm, lợi ích mà phần mềm mã nguồn mở
mang lại. Tuy nhiên, nó vẫn còn những điểm hạn chế là thao tác và sử dụng khó. Người
quản trị cần có kỹ năng chuyên mơn để có thể vận hành hệ thống tốt. Do vậy giải pháp mã
nguồn mở thường phù hợp với các doanh nghiệp vừa và nhỏ hoặc muốn tiết kiệm chi phí.
Trong phạm vi đồ án, với lợi thế là dễ dàng tiếp cận và nghiên cứu, giải pháp tường lửa mã
nguồn mở được lựa chọn. Phần tiếp theo chúng ta cùng tìm hiểu về các giải pháp tưởng lửa
mở nguồn mở.
2.2. Các giải pháp tường lửa mã nguồn mở
Có rất nhiều các tường lửa ứng dụng web mã nguồn mở trên thế giới. Các tường lửa ứng
dụng web đã góp phần không nhỏ vào việc ngăn chặn các tấn công web trên toàn thế giới.
Tiêu biểu nhất là ModSecurity, WebCastellum và Ironbee
•

ModSecurity: ModSecurity là một tường lửa ứng dụng web mã nguồn mở được
phát triển bởi nhóm Trustwave’s SpiderLabs. Các tính năng chính của ModSecurity
là lọc, lọc dựa trên các cụm từ thơng dụng, hỗ trợ URL mã hóa, ngăn chặn tấn công
null bbyte,… ModSecurity cũng là một ứng dụng hỗ trợ ghi nhật ký đầy đủ.

• WebCastellum: WebCastellum là một tường lửa ứng dụng web mã nguồn mở phát
triển bằng Java. Nó có thể bảo vệ hệ thống chống lại một số đe dọa như SQL
Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF),… Phiên
bản ổn định cuối cùng là 1.8.3, được phát hành theo Eclipse. WebCasellum có các
tính năng chính như URL mã hóa, ngăn chặn CSRF, phát hiện tấn công statefull,…
WebCastellum tiến hành giám sát các luồng yêu cầu và phản hồi, thực hiện các hành
động dựa theo các rule đã định sẵn.
• Ironbee: Ironbee là một tưởng lửa ứng dụng web mã nguồn mở phân phối theo BSD
và Apache 2.0. Ironbee là một phần mềm rất đáng tin cậy và có khả năng mở rộng
với nhiều tính năng: triển khai tùy chỉnh, linh hoạt, phân tích các luồng traffic vào

ra, giám sát theo hành vi (IP, phiên, người dùng,…), dò quét lỗ hổng,… Ironbee
Trang 20


cũng cung cấp khả năng tích hợp với các thiết bị bảo mật khác như firewall và trao
đổi dữ liệu.
Tổng quan, ta có bảng so sánh giữa 3 giải pháp firewall tiêu biểu
ModSecurity

WebCastellum

Ironbee

Lọc đơn giản

Có

Có

Có

Lọc theo regular expression

Có

Kiểm tốn (Auditing)

Có

Ngăn chặn tấn cơng null byte

Có

URL mã hóa

Có

Phát hiện tấn cơng stateful

Có
Có
Có

Có

Bảng 3.1: So sánh giữa các giải pháp firewall [3]
Qua bảng so sánh ở trên, chúng ta có thể nhận thấy rằng giải pháp ModSecurity là tốt
nhất trong các giải pháp. Ngoài ra giải pháp ModSecurity cũng dễ dàng cài đặt và triển
khai vào mơ hình mạng của tổ chức. Tính mềm dẻo, linh hoạt trong chính sách cũng là một
trong những ưu điểm để ModSecurity luôn là sự lựa chọn của các nhà quản trị mạng. Trong
phần tiếp theo chúng ta sẽ cùng tìm hiểu chi tiết về giải pháp.
2.3.

Giới thiệu ModSecurity

ModSecurity là một tường lửa ứng dụng web mã nguồn mở. Phiên bản đầu tiên được
phát hành vào tháng 11 năm 2002, nhưng cần thêm vài tháng nữa trước khi cơng cụ trở nên
hồn chỉnh. Những người quan tâm bắt đầu tìm hiểu về ModSecurity và sự phổ biến của
nó bắt đầu tăng lên. Ban đầu ModSecurity được thiết kế như một module cho Apache
HTTP Server, sau đó nó đã phát triển để cung cấp một loạt các yêu cầu của HTTP và khả

năng lọc phản ứng cùng với các tính năng bảo mật khác trên một số nền tảng khác nhau
bao gồm Apache HTTP Server, Microsoft IIS và NGINX.
2.4. Hoạt động của ModSecurity
Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 giai đoạn (phase),
tại mỗi giai đoạn ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phịng
chống các tấn cơng, khai thác.

Trang 21


Hình 3.1: Các pha trong hoạt động của ModSecurity [1]
Giai đoạn 1: Request headers
Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin. Mục đích chính của giai
đoạn này là cho phép đánh giá các yêu cầu trước khi thực hiện các xử lý tốn kém tiếp theo
trong HTTP body. Ví dụ, ModSecurity sẽ khơng phân tích cú pháp phần body yêu cầu
XML theo mặc định, nhưng bạn có thể hướng dẫn nó làm như vậy bằng cách đặt các quy
tắc thích hợp vào giai đoạn 1.
Giai đoạn 2: Request body
Đây là giai đoạn phân tích yêu cầu chính và diễn ra ngay sau khi một yêu cầu hoàn chỉnh
đã được nhận và xử lý. Các rule trong giai đoạn có tất cả các dữ liệu yêu cầu có sẵn theo ý
của chúng.
Giai đoạn 3: Response headers
Giai đoạn này tiến hành phản hồi sau khi tiêu đề phản hồi khả dụng, nhưng trước khi
đọc nội dung phản hồi. Các rule cần quyết định có nên kiểm tra giai đoạn phản hồi HTTP
body nên chạy trong giai đoạn này.
Trang 22


Giai đoạn 4: Response body
Đây là giai đoạn chính của quá trình phản hồi. Đến thời điểm này giai đoạn bắt đầu, nội

dung phản hồi sẽ được đọc, với tất cả dữ liệu có sẵn cho các rule đưa ra quyết định của
chúng.
Giai đoạn 5: Logging
Đây là giai đoạn khá là đặc biệt. Đầu tiên, đó là giai đoạn duy nhất mà bạn không thể
chặn. Vào thời điểm giai đoạn này chạy, giao dịch sẽ kết thúc, do đó, bạn có thể thực hiện
q trình ghi lại nhật ký nhưng thực tế là nó đã xảy ra. Các rule trong giai đoạn này được
chạy để kiểm soát cách ghi nhật ký được thực hiện..
3. Mơ hình triển khai và hướng dẫn cài đặt
3.1. Mơ hình triển khai
ModSecurity hỗ trợ hai mơ hình triển khai là: tích hợp vào web server (embedded) và
reverse proxy. Khơng có mơ hình nào là hồn hảo; mỗi mơ hình sẽ phù hợp với từng hệ
thống cụ thể. Có những ưu điểm và nhược điểm cho cả hai mơ hình:
Mơ hình tích hợp vào web server
ModSecurity là một tường lửa ứng dụng web có thể được triển khai như một phần của
cơ sở hạ tầng máy chủ web hiện tại của bạn với điều kiện máy chủ web của bạn là Apache,
IIS7 hoặc Nginx. Phương pháp triển khai này có những ưu, nhược điểm nhất định:
Ưu điểm:
• Khơng có thay đổi đối với hệ thống mạng hiện tại. Chúng ta chỉ mất ít thười gian
để cài đặt ModSecurity vào các máy chủ web hiện tại. Và bởi vì nó được thiết kế
hồn tồn thụ động theo mặc định, chúng ta có thể tự do triển khai nó theo từng
bước và chỉ sử dụng các tính năng cần thiết. Chúng ta cũng dễ dàng gỡ bỏ hoặc tắt
nó nếu cần thiết.
• Khơng có điểm yếu nút thắt cổ chai (single point). Khơng giống như mơ hình triển
khai proxy, ModSecurity sẽ không là nút thắt cổ chai cho hệ thống.
• Khả năng cân bằng tải và mở rộng. Bởi vì ModSecurity được tích hợp trong các
máy chủ web, nên nó sẽ tự động tận dụng các tính năng cân bằng tải và khả năng
mở rộng bổ sung. Chúng ta sẽ không cần phải suy nghĩ về cân bằng tải và mở rộng
quy mơ cho hệ thống.
• Chi phí tối thiểu. Bởi vì ModSecurity hoạt động từ bên trong q trình máy chủ
web nên khơng có phát sinh thêm chi phí cho giao tiếp mạng, chi phí thiết bị và làm

giảm q trình phân tích cú pháp và trao đổi dữ liệu.
Trang 23


• Khơng có vấn đề với nội dung được mã hóa hoặc nén (luồng HTTPS). Nhiều hệ
thống IDS gặp khó khăn trong việc phân tích lưu lượng SSL. Đây khơng phải là
vấn đề đối với ModSecurity vì nó được định vị để hoạt động khi lưu lượng truy cập
đã được giải mã và giải nén.
Nhược điểm:
• Chiếm tài nguyên của web server. Khi hoạt động, dù ít hay nhiều ModSecurity cũng
sẽ chiếm một phần tài nguyên của web server. Nếu các chính sách, quy tắc thiết lập
nhiều, khơng được tối ưu, thì tài nguyên sẽ bị chiếm nhiều hơn. Nếu hệ thống của
bạn là nhỏ, có thể bạn khơng cần phải quan tâm đến yếu tố này. Tuy nhiên nếu hệ
thống lớn, cần tính tốn tài ngun kỹ trước khi triển khai. Nếu cần, hãy bổ sung
thêm tài nguyên cho web server.
• Nếu hệ thống của bạn có nhiều hơn một web server, việc triển khai và cài đặt
ModSecurity sẽ phải thực hiện trên từng máy chủ. Việc quản lý chính sách, quy tắc
cũng khó khăn hơn. Khi cần cấu hình hoặc cập nhật chính sách, người quản trị cần
phải thực hiện trên tất cả các server

Hình 3.2: Mơ hình tích hợp vào web server (embedded)

Trang 24