NGHIÊN CỨU VỀ PHƯƠNG PHÁP PHÁT HIỆN TẤN CÔNG ỨNG DỤNG WEB DỰA TRÊN MẪU DẤU HIỆU

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ

MÔN CHUYÊN ĐỀ 2
NGHIÊN CỨU VỀ PHƯƠNG PHÁP PHÁT HIỆN TẤN CÔNG ỨNG DỤNG
WEB DỰA TRÊN MẪU DẤU HIỆU
Ngành: An toàn thông tin

Hà Nội, 2020
1


MỤC LỤC
PHẦN I: CÁC VẤN ĐỀ AN TOÀN ĐỐI VỚI MÁY CHỦ WEB.........................................................................- 4 1) GIỚI THIỆU......................................................................................................................................................... - 4 2) CÔNG CỤ TẤN CÔNG............................................................................................................................................- 4 3) PHÂN LOẠI CÁC HÌNH THỨC TẤN CÔNG............................................................................................................- 5 3.1) Tấn công Bruteforce.........................................................................................................................................- 5 3.2) Lỗi chứng thực yếu (Insufficient Authentication)..........................................................................................- 5 3.3) Dự đoán, chèn phiên (Credentical/Session Prediction)..................................................................................- 5 3.4) XSS (Cross-Site Scripting)...............................................................................................................................- 5 3.5) SQL Injection....................................................................................................................................................- 6 3.6) Liệt kê thư mục (Directory indexing)..............................................................................................................- 6 3.7) Path Traversal...................................................................................................................................................- 7 3.8) Từ chối dịch vụ (DoS)......................................................................................................................................- 7 4) CÁC GIẢI PHÁP PHÁT HIỆN VÀ NGĂN CHẶN TẤN CÔNG ỨNG DỤNG WEB......................................................- 7 4.1) Giải pháp tường lửa hệ thống ứng dụng Web (Web application firewall – WAF)........................................- 7 4.2) Giải pháp chống giả mạo giao dịch (Fraud detection)...................................................................................- 8 4.3) Giải pháp mã hóa dữ liệu.................................................................................................................................- 8 4.4) Giải pháp tường lửa đa năng UTM.................................................................................................................- 8 4.5) Giải pháp dò quét các lỗ hổng an ninh............................................................................................................- 9 PHẦN II: TƯỜNG LỬA BẢO VỆ ỨNG DỤNG WEB......................................................................................- 10 1) TƯỜNG LỬA BẢO VỆ ỨNG DỤNG WEB (WAF)................................................................................................ - 10 1.1) Kiến trúc tường lửa ứng dụng web................................................................................................................- 10 a) Vị trí WAF......................................................................................................................................................................- 10 b) Mô hình bảo mật của WAF...........................................................................................................................................- 10 c) Mô hình hoạt động.........................................................................................................................................................- 10 -

1.2) Các sản phẩm và giải pháp............................................................................................................................- 11 2) TIÊU CHUẨN OWASP TOP TEN....................................................................................................................... - 11 2.1) A1: Injection...................................................................................................................................................- 12 2.2) A2: Broken Authentication.............................................................................................................................- 12 2.3) A3: Sensitive Data Exposure..........................................................................................................................- 13 2.4) A4: XML External Entities (XXE).................................................................................................................- 13 2.5) A5: Broken Access Control............................................................................................................................- 14 2.6) A6: Security Misconfiguration.......................................................................................................................- 14 2.7) A7: Cross Site Scripting (XSS).......................................................................................................................- 14 2.8) A8: Insecure Deserialization..........................................................................................................................- 14 2.9) A9: Using Components with Know Vulnerabilities.......................................................................................- 14 2.10) A10: Insufficient Logging & Monitoring....................................................................................................- 15 3) TƯỜNG LỬA BẢO VỆ ỨNG DỤNG WEB MODSECURITY..................................................................................- 15 3.1) Chức năng.......................................................................................................................................................- 15 3.2) Quy trình xử lý trong ModSecurity................................................................................................................- 16 3.3) Cấu trúc tập luật trong ModSecurity.............................................................................................................- 18 3.3.1) Variables...................................................................................................................................................................- 18 3.3.2) Collections................................................................................................................................................................- 19 3.3.3) Operators..................................................................................................................................................................- 20 3.3.4) Actions...................................................................................................................................................................... - 22 -

3.4) Xây dựng tập luật phát hiện và chống tấn công trong ModSecurity...........................................................- 23 3.4.1) Xây dựng tập luật phát hiện và chống tấn công SQL Injection............................................................................- 23 3.4.2) Xây dựng tập luật phát hiện và chống tấn công XSS............................................................................................- 27 -

2


3.4.3) Xây dựng tập luật phát hiện và chống tấn công Local File Include.....................................................................- 28 3.4.4) Xây dựng tập luật phát hiện chống tấn công BruteForce.....................................................................................- 28 -

4) TRIỂN KHAI MODSECURITY............................................................................................................................. - 30 4.1) Triển khai ModSecurity trên môi trường Windows......................................................................................- 30 4.2) Triển khai ModSecurity cho Nginx trên Ubuntu 18.04................................................................................- 32 5) CHẠY THỬ VÀ KIỂM TRA.................................................................................................................................... - 35 5.1) Chạy thử và kiểm tra trên Windows...............................................................................................................- 35 5.1.1) Chống tấn công XSS Reflected................................................................................................................................- 35 a) Trước khi sử dụng tập luật chống XSS cho Modsec....................................................................................................- 35 b) Sau khi sử dụng tập luật chống XSS cho Modsec...................................................................................................- 36 5.1.2) Chống tấn công XSS Stored....................................................................................................................................- 37 a) Trước khi sử dụng tập luật chống XSS cho Modsec................................................................................................- 37 b) Sau khi sử dụng tập luật chống XSS cho Modsec...................................................................................................- 38 5.1.3) Chống tấn công SQL Injection................................................................................................................................- 39 a) Trước khi sử dụng tập luật chống SQL Injection cho Modsec...............................................................................- 39 b) Sau khi sử dụng tập luật chống SQL Injection cho Modsec...................................................................................- 40 -

5.2) Chạy thử và kiểm tra trên Ubuntu.................................................................................................................- 41 5.2.1) Chống tấn công XSS................................................................................................................................................- 41 a) Trước khi sử dụng tập luật chống XSS cho Modsec................................................................................................- 41 b) Sau khi sử dụng tập luật chống XSS cho Modsec...................................................................................................- 41 5.2.2) Chống tấn công SQL Injection................................................................................................................................- 42 a) Trước khi sử dụng tập luật chống SQL Injection cho Modsec...............................................................................- 42 b) Sau khi sử dụng tập luật chống SQL Injection cho Modsec...................................................................................- 43 -

3

PHẦN I: CÁC VẤN ĐỀ AN TOÀN ĐỐI VỚI MÁY CHỦ WEB
1) Giới Thiệu
Trong thời đại phát triển mạnh của công nghệ Internet như hiện nay. Các dịch vụ trên
mạng đã thâm nhập vào hầu hết các lĩnh vực trong đời sống xã hội. Các thông tin trên
Internet cũng đa dạng về nội dung và hình thức, trong đó có rất nhiều thông tin cần được bảo
mật cao hơn bởi tính kinh tế, tính chính xác và tính tin cậy của nó.
Chính vì vậy, các vấn đề thuộc về an ninh mạng như: sự tấn công, thâm nhập và đánh
cắp dữ liệu trên website và trên hệ thống máy chủ đã dấy lên sự lo ngại từ phía người quản
trị. Để ngăn chặn điều này xảy ra, người quản trị cần có những phương pháp thích hợp để
bảo vệ máy chủ cũng như máy tính của mình.
Trong quá trình xây dựng website, điều thiết yếu là phải bảo mật website trước những
hiểm họa trên internet. Việc xây dựng bảo mật Web Server có vai trò cực kì quan trọng trong
vấn đề này. Xuất phát từ những thực tế đó, chúng ta sẽ tìm hiểu về các cách tấn công phổ
biến nhất hiện nay và cách phòng chống các loại tấn công này.

2) Công Cụ Tấn Công
Metasploit Framework là một môi trường dùng để kiểm tra, tấn công và khai thác
lỗi của các service. Ban đầu Metasploit được xây dựng từ ngôn ngữ hướng đối tượng Perl
với những component được viết bằng C và Python sau đó được viết lại vằng ruby. Đây là
một công cụ mã nguồn mở phát triển nhằm sử dụng các shellcode để tấn công, khai thác khai
thác lỗi của các dịch vụ Metasploit có thể chạy trên hầu hết các hệ điều hành: Linux,
Windows, MacOS.
Các tính năng chính:
 Quét cổng để xác định các dịch vụ đang hoạt động trên server.
 Xác định các lỗ hổng dựa trên phiên bản của hệ điều hành và phiên bản các
phần mềm cài đặt trên hệ điều hành đó.
 Thử nghiệm khai thác các lỗ hổng đã được xác định.
MPack là một công cụ khai thác web. Nó được viết bằng PHP và được hỗ trợ bởi
MySQL. Khi một máy chủ web đã bị xâm nhập bằng MPack, tất cả lưu lượng sẽ được
chuyển hướng đến trang web độc hại.

Zeus công cụ này được sử dụng để biến một máy tính bị chiếm quyền thành con bot
hoặc zombie. Một con bot là một máy tính bị chiếm quyền điều khiển và bị sử dụng để thực
hiện các cuộc tấn công trên Internet. Một botnet là tập hợp của các máy tính bị chiếm quyền
điều khiển. Mạng botnet có thể bị sử dụng trong một cuộc tấn công từ chối dịch vụ hoặc gửi
đi các email rác.
4


Neosploit là một bộ công cụ chứa mã khai thác những lỗi bảo mật nguy hiểm trong
những trình duyệt web và ứng dụng phổ biến. Công cụ này có thể được sử dụng để cài đặt
chương trình, xóa chương trình, sao chép nó, v.v.

3) Phân Loại Các Hình Thức Tấn Công
3.1) Tấn công Bruteforce
Brute Force Attack là phương thức tấn công dò ra mật khẩu và tài khoản của người
quản trị cao nhất. Hình thức tấn công này dễ phòng chống nhưng lại rất dễ bị dính nếu người
quản trị chủ quan trong việc đặt mật khẩu và username. Thường thì sẽ dễ bị tấn công kiểu
này khi:
 Đặt username là admin, administrator hoặc tương tự.
 Mật khẩu không an toàn, dễ đoán ra, sử dụng phổ biến.
 Không bảo mật đường dẫn đăng nhập.
 Không thay đổi mật khẩu thường xuyên.
 Như vậy, các vấn đề liên quan đến bảo mật tài khoản đăng nhập sẽ đều giúp
cho hacker sử dụng brute force attack để tấn công.
3.2) Lỗi chứng thực yếu (Insufficient Authentication)
Lỗi chứng thực yếu xuất hiện khi một website cho phép truy cập các nội dung, tài
nguyên nhạy cảm mà không có đủ quyền. Các trang quản trị là một ví dụ dễ thấy nhất. Nếu
không có cơ chế phân quyền hợp lý thư mục cũng như tài khoản đăng nhập trang quản trị
này. Tin tặc hoàn toàn có khả năng vượt qua được cơ chế đăng nhập để chiếm quyền điều
khiển trang này.

3.3) Dự đoán, chèn phiên (Credentical/Session Prediction)
Dự đoán, chèn phiên là một phương thức chiếm phiên (hijacking ). Thông thường, khi
một tài khoản thực hiện quá trình chứng thực đối với server (tài khoản/mật khẩu). Dựa vào
các thông tin này, server sẽ tạo một giá trị session ID duy nhất để cho phép và duy trì kết
nối. nếu đoán được session ID kế tiếp thì tin tặc có khả năng chiếm phiên đăng nhập của
người dùng hợp lệ khác.
3.4) XSS (Cross-Site Scripting)
XSS là một trong những kĩ thuật tấn công phổ biến nhất hiện nay, đồng thời nó cũng
là một trong những vấn đề bảo mật quan trọng đối với các nhà phát triển web và cả những
người sử dụng web. Bất kì một website nào cho phép người sử dụng đăng nhập thông tin mà
không có sự kiểm tra chặt chẽ các đoạn mã nguy hiểm thì đều có thể tiềm ẩn các lỗi XSS.
Tin tặc 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. Trong đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client
– Site Script như JavaScript, Jscript, DHTML và cũng có thể là cả các thẻ HTML.
5


Ví dụ: Sử dụng XSS chèn mã java script trực tiếp trên URL:
was found !’);</script>
Khi wesite bị lỗi XSS trình duyệt sẽ hiện lên một thông báo
“XSS was found !”. Nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu
nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại đối với
website ở phía client mà nạn nhân trực tiếp là những người khách duyệt site đó
3.5) SQL Injection
Tấn công SQL Injection được thực thi bằng cách chèn các câu truy vấn SQL vào dữ
liệu tương tác giữa máy khách và trình ứng dụng. Quá trình khai thác lỗi SQL Injection
thành công có thể giúp tin tặc lấy được các dữ liệu nhạy cảm trong cở sở dữ liệu, thay đổi cơ
sở dữ liệu (Insert/Update/Delete), thực thi các hành động với quyền của người quản trị và
cao hơn có thể điều khiển được hệ điều hành máy chủ Ví dụ: Xét đoạn mã truy vấn SQL sau:

SELECT * FROM Users WHERE Username=’$username’ AND
Password=’$password’
Đây là một câu truy vấn thường hay được dùng trong các trình ứng dụng nhằm xác
thực người dùng. Nếu câu truy vấn trả về một giá trị nói rằng thông tin về người dùng đang
đăng nhập là đúng và được lưu trong cơ sở dữ liệu, thì người dùng được phép đăng nhập vào
hệ thống, ngược lại thì không đăng nhập được. Người dùng nhập thông tin đó vào các trường
gọi là web form. Thay vì nhập đúng tên đăng nhập và mật khẩu, thử nhập vào các ký tự đặc
biệt như:
$username = 1′ or ‘1’ = ‘1
$password = 1′ or ‘1’ = ‘1
Khi đó câu truy vấn sẽ là:
SELECT * FROM Users WHERE Username=’1′ OR ‘1’ = ‘1’ AND Password=’1′
OR ‘1’ = ‘1’
Giả sử rằng giá trị của các tham số được gửi tới máy chủ bằng phương thức GET, thì
có một câu lệnh khai thác lỗi như sau:
‘%20or%20’1’%20=%20’1&password=1’%20or%20’1’%20=%20’1
Khi đó, truy vấn sẽ trả về một giá trị (hay một loạt các giá trị) vì điều kiện trên luôn
luôn đúng (OR 1=1). Trong trường hợp này tin tặc sẽ đăng nhập được vào hệ thống mà
không cần biết tên đăng nhập và mật khẩu. Trường hợp này sẽ rất nguy hiểm nếu dòng đầu
tiên trong bảng “Users” là tài khoản của người quản trị (admin) vì tin tặc sẽ đăng nhập vào
hệ thống bằng tài khoản đầu tiên trong bảng này.

6


3.6) Liệt kê thư mục (Directory indexing)
Đây là chức năng web server cho phép liệt kê tất cả nội dung bên trong một thư mục
mà không có tập tin cơ sở (index.html/home.html/ default.html). Trong các thư mục đó có
thể chứa nội dung quan trọng: tập tin cơ sở dữ liệu dự phòng, tập tin cấu hình, tập tin lưu trữ
tạm thời, các kịch bản…

3.7) Path Traversal
Path Traversal hay còn được biết với một số tên khác như “dot-dot-slash”, “directory
traversal”,”directory clumbing” và “backtracking” là hình thức tấn công truy cập đến những
file và thư mục mà được lưu bên ngoài thư mục webroot. Hình thức tấn công này không cần
sử dụng một công cụ nào mà chỉ đơn thuần thao tác các biến với ../ (dot-dot-slash) để truy
cập đến file, thư mục, bao gồm cả source code, những file hệ thống, … Ví dụ:
GET /../../../../../some/file HTTP/1.0
GET /..%255c..%255c..%255csome/file HTTP/1.0
GET /..%u2216..%u2216some/file HTTP/1.0
3.8) Từ chối dịch vụ (DoS)
DoS là kỹ thuật tấn công nhằm không cho phép các truy cập hợp lệ truy cập tới
server. Kỹ thuật tấn công này thường xảy ra tại lớp mạng và lớp ứng dụng. Các hệ thống
đích có thể bị tấn công DoS:
 Người dùng riêng lẻ: quá trình đăng nhập lặp đi lặp lại với tài khoản hợp lệ
nhưng mật khẩu không đúng. Sau nhiều lần đăng nhập sai, hệ thống sẽ khóa tài
khoản hợp lệ này, dẫn đến người dùng hợp lệ sẽ không thể đăng nhập được.
 Máy chủ cơ sở dữ liệu: Sử dụng kỹ thuật chèn câu lệnh truy vấn SQL chỉnh
sửa cơ sở dữ liệu, vì thế hệ thống sẽ không thể phục vụ các truy cập từ client.
 Máy chủ phục vụ web: Sử dụng kỹ thuật tấn công tràn bộ đệm ( Buffer
Overflow) để gửi các gói truy vấn và làm đổ vỡ các tiến trình tại phía máy chủ
phục vụ web, dẫn đến hệ thống máy chủ webserver sẽ không có khả năng phục
vụ các truy cập hợp lý.

4) Các Giải Pháp Phát Hiện và Ngăn Chặn Tấn Công Ứng Dụng Web
4.1) Giải pháp tường lửa hệ thống ứng dụng Web (Web application firewall –
WAF)
Tường lửa ứng dụng Web là thiết bị bảo vệ chuyên biệt cho ứng dụng, có thể phân
tích, hiểu sâu được cấu trúc, thuộc tính và hoạt động của website cụ thể của mỗi tổ chức.
Nhờ vậy nó có thể phát hiện và ngăn chặn cả tấn công chưa biết và những hành vi bất
thường trên ứng dụng, tấn công tinh vi, sử dụng kỹ thuật lẩn tránh mà có thể dễ dàng vượt

qua tường lửa mức mạng và IPS. Tường lửa có khả năng kết hợp với các giải pháp đánh giá
điểm yếu để đưa ra bảo vệ điểm yếu được phát hiện ngay lập tức với bản vá ảo.
7


Giải pháp tường lửa ứng dụng Web hỗ trợ nhiều mô hình triển khai cho phép triển
khai hoàn toàn trong suốt mà không làm thay đổi tới tới mạng và ứng dụng đang hoạt động.
Giải pháp cho phép:
 Chống tấn công mức ứng dụng, nhờ khả năng học và phân tích sâu ở tầng ứng
dụng.
 Chống các tấn công tự động (sử dụng bot, script tự động truy cập, dò quét
website), giúp hạn chế chống tấn công DDoS.
 Cung cấp bản vá ảo bảo vệ các điểm yếu ứng dụng nhanh chóng trong khi
chưa thể triển khai biện pháp vá điểm yếu bằng cách sửa mã nguồn hay cài bản
vá thật.
 Bổ sung và tăng cường lớp an ninh theo chiều sâu để bảo vệ vững chắc, chống
các tấn công nhằm vào hệ thống ứng dụng Web.
 Bảo vệ nhanh chóng các điểm yếu ứng dụng trong khi các biện pháp khác như
cài bản vá, sửa mã nguồn chưa thể triển khai được.
 Ngăn chặn các tấn công đánh cắp thông tin, hay phá hoại, thay đổi thông tin
Cơ sở dữ liệu qua việc khai thác điểm yếu trên ứng dụng web.
 Ghi vết các truy cập, tấn công vào ứng dụng, giúp điều tra và xử lý sự cố.
 Tăng cường tính sẵn sàng, ổn định cho hệ thống dịch vụ kinh doanh, giúp bảo
vệ hình ảnh của tổ chức, nâng cao uy tín và sức cạnh tranh.
4.2) Giải pháp chống giả mạo giao dịch (Fraud detection)
Ngăn chặn các hành vi giả mạo người dùng, chiếm đoạt và sử dụng các tài khoản
thanh toán trên môi trường thanh toán điện tử, e-banking.
Tính năng:
 Giám sát hành vi người dùng dịch vụ thanh toán điện tử, e-banking.
 Chống đánh cắp định danh người dùng dựa trên nhiều thông tin: loại giao dịch,

số tiền giao dịch, thời gian làm việc, vị trí địa lý (theo địa chỉ IP), …
 Ngăn chặn hành vi lạm dụng trên hệ thống: truy cập trực tiếp vào các trang đặt
hàng, sử dụng các biến môi trường đáng ngờ…
 Ngăn chặn hành vi đáng ngờ trên hệ thống giao dịch trực tuyến như: số lần sử
dụng thẻ thanh toán, thanh toán nhiều lần từ cùng địa chỉ IP…

8


4.3) Giải pháp mã hóa dữ liệu
Bảo vệ các dữ liệu nhạy cảm bằng các hình thức mã hóa: mã hóa thư mục, tập tin, ổ
cứng, …
Tính năng:
 Thực thi mã hóa dữ liệu trên thiết bị đầu cuối (máy tính xách tay, smart phone,
máy tính để bàn, …)
 Mã hóa dữ liệu trên ổ đĩa local, máy chủ mạng, ở cấp độ tập tin và thư mục.
4.4) Giải pháp tường lửa đa năng UTM
Bảo vệ cổng hệ thống (gateway), ngăn chặn các rủi ro từ môi trường Internet.
Tính năng:
 Lọc web, Chống xâm nhập (IPS), Chống DDoS, Chống virus, spam.
 Lọc các cổng dịch vụ Giám sát ứng dụng và người dùng.
4.5) Giải pháp dò quét các lỗ hổng an ninh
Xác định, giám sát và đưa ra phương án xử lý các lỗ hổng an ninh trên toàn hệ thống
mạng, máy chủ, hệ điều hành, cơ sở dữ liệu và ứng dụng.
Tính năng:
 Cung cấp báo cáo toàn diện về các lỗ hổng an ninh trên hệ thống.
 Đưa ra các cảnh báo tức thời khi hệ thống xuất hiện lỗ hổng bảo mật.
 Hỗ trợ người quản trị đưa ra quyết định về các chính sách và điều chỉnh bảo
mật hệ thống chính xác, phù hợp và kịp thời.
 Tích hợp với các công cụ giám sát bảo vệ hệ thống như IDS/IPS, tường lửa

ứng dụng web… tạo ra một hệ thống phòng thủ an ninh có chiều sâu và liên
kết chặt chẽ giữa các thành phần bảo mật.

9


PHẦN II: TƯỜNG LỬA BẢO VỆ ỨNG DỤNG WEB
1) Tường Lửa Bảo Vệ Ứng Dụng Web (WAF)
Web Application Firewall – WAF là một giải pháp nhằm bảo vệ cho ứng dụng web
tránh khỏi các lỗi bảo mật, các cuộc tấn công từ mã độc và tin tặc. 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.
1.1) Kiến trúc tường lửa ứng dụng web
a) Vị trí WAF
WAF có 02 hình thức triển khai, bao gồm dạng phần cứng và giải pháp cloudbased.
Các hệ thống WAF cứng thường được đặt sau tường lửa mạng và trước máy chủ ứng dụng
web. Việc đặt WAF được thực hiện sao cho tất cả các lưu lượng đến ứng dụng web cần qua
WAF trước. Tuy nhiên, đôi khi cũng có ngoại lệ khi WAF chỉ được dùng để giám sát cổng
đang mở trên máy chủ web. Ngoài ra, các chương trình WAF còn được cài đặt trực tiếp lên
máy chủ web và thực hiện các chức năng tương tự như các thiết bị WAF là giám sát các lưu
lượng đến và ra khỏi ứng dụng web.
b) Mô hình bảo mật của WAF
Một tường lửa ứng dụng web hoạt động dựa theo 2 mô hình bảo mật: Positive và
Negative. Mô hình Positive chỉ cho phép các lưu lượng hợp lệ được định nghĩa sẵn đi qua và
chặn tất cả các lưu lượng còn lại. Mô hình Negative sẽ cho phép tất cả các lưu lượng vượt
qua và chỉ chặn được các lưu lượng mà WAF cho là nguy hại. Đôi khi cũng có các WAF
cung cấp cả 2 mô hình trên, tuy nhiên thông thường WAF chỉ cung cấp 1 trong 2 mô hình.

Với mô hình Postitive thì đòi hỏi nhiều cấu hình và tùy chỉnh. Còn mô hình Negative chủ
yếu dựa vào khả năng học hỏi và phân tích hành vi của lưu lượng mạng.
c) Mô hình hoạt động
WAF có thể hoạt động ở các mô hình riêng biệt, dưới đây là một số mô hình tham
khảo:
 Reverse Proxy: đây là chức năng được sử dụng phổ biến khi triển khai WAF.
Trong mô hình này, WAF giám sát tất cả các lưu lượng đi đến ứng dụng web, sau
đó thay vì cho các địa chỉ IP bên ngoài gửi yêu cầu trực tiếp đến máy chủ web thì
WAF đứng ra làm trung gian để gửi các yêu cầu này đến máy chủ web thay cho
trình duyệt gốc rồi gửi trả lại kết quả cho các địa chỉ IP kia. Mô hình này có nhược
điểm là tạo ra độ trễ khi kết nối từ trình duyệt đến ứng dụng web.
 Transparent Proxy: Ở mô hình này, WAF đứng giữa tường lửa mạng và máy chủ
web và hoạt động tương tự ở mô hình Reverse Proxy nhưng không đứng ra làm
10


trung gian kết nối như bên Reverse Proxy. Mô hình này không đòi hỏi phải thay
đổi điều gì trong hạ tầng mạng nhưng có thể không cung cấp được một số dịch vụ
như mô hình Reverse Proxy có thể.
 Layer 2 Brigde: Ở mô hình này, WAF đứng giữa tường lủa mạng và máy chủ
web, nhưng hoạt động giống như một thiết bị Switch ở lớp 2. Mô hình này giúp
mạng hoạt động với hiệu năng cao và mạng thay đổi không đáng kể, tuy nhiên nó
lại không thể cung cấp các dịch vụ cao cấp khác mà các mô hình WAF khác có
thể.
 Host/Server Based: Đây là các phần mềm được cài trực tiếp lên máy chủ web.
Các loại Host based không cung cấp các tính năng tương tự như các loại WAF
network base. Tuy nhiên mô hình này có thể khắc phục được vài điểm yếu mà các
mô hình network base (các thiết bị WAF cứng) có. Tuy nhiên nó cũng làm tăng
mức độ tải của máy chủ web.
1.2) Các sản phẩm và giải pháp

ModSecurity: Đây là phần mềm mã nguồn mở có thể hoạt động như một module
trong máy chủ Apache hoặc là một thành phần độc lập. ModSecurity sử dụng biểu thức
chính quy trong việc bảo vệ máy chủ web từ các cuộc tấn công được xác định trước dựa theo
các dấu hiệu hoặc các cuộc tấn công bất thường khác. Bên cạnh đó, ModSecurity cũng có
khả năng lọc các siêu ký tự do người dùng chèn vào ứng dụng web.
URLScan: Đây là một sản phẩm của Microsoft dành riêng cho các máy chủ web IIS.
URLscan không chỉ bảo vệ máy chủ IIS 6 khỏi các điểm yếu từ các phiên bản cũ hơn mà
còn cung cấp thêm các biện pháp bảo vệ khác như lọc dữ liệu mã hóa trên URL hoặc lọc các
siêu ký tự do người dùng chèn vào để chống lại các loại tấn công như XSS, SQL Injection…
CyStack WebShield: Đây là một sản phẩm của Việt Nam do công ty an ninh mạng
CyStack xây dựng và phát triển. Giải pháp cung cấp các tính năng giúp bạn bảo vệ website
của mình dễ dàng. WebShield cung cấp các tính năng để bạn có thể bảo vệ website của mình
tự động mà không cần cài đặt. Bạn chỉ cần cấu hình website đi qua CyStack Network và
CyStack Protecting sẽ làm nhiệm vụ ngăn chặn tấn công, mã độc vào website của bạn.

2) Tiêu Chuẩn OWASP TOP TEN
OWASP ( Open Web Application Security Project): Họ là một tổ chức phi lợi
nhuận trên toàn thế giới tập trung vào việc nâng cao tính bảo mật của phần mềm trên web.
Họ tạo ra một tài liệu được gọi là Top 10 nguy cơ bảo mật ứng dụng Web quan trọng nhất,
"Top 10" là một hướng dẫn công nghệ để quản lý rủi ro bảo mật trang web phổ biến. Nó
thường là một nơi để tham khảo cho các chuyên gia bảo mật và các nhà phát triển cùng
nhau.
OWASP Top 10 (2017) là:
 A1: Injection
11


 A2: Broken Authentication
 A3: Sensitive Data Exposure
 A4: XML External Entities

 A5: Broken Access Control
 A6: Security Misconfiguration
 A7: Cross-Site-Scripting(XSS)
 A8: Insecure Deserialization
 A9: Using Components with Know Vulnerabilities
 A10: Insufficient Logging & Monitoring
2.1) A1: Injection
SQL, NoSQL, OS, Command Injection and LDAP injection là những loại phổ biến
của những lỗi về Injection, nó xảy ra khi những dữ liệu không tin cậy được gửi về server và
thực thi những query hay command từ đó truy cập vào dữ liệu của ứng dụng hoặc thực thi
những câu lệnh không mong muốn.
Những ứng dụng có thể dễ bị tấn công khi: Dữ liệu của người dùng không được
validate, filter một cách đúng đắn. Ứng dụng có Dynamic queries.
Cách phòng tránh
 Nên sử dụng Object Relational Mapping Tools(ORMs) trong việc tương tác
Database.
 Có thể tích hợp những tool để scan code trong CI/CD như static source
(SAST) hay dynamic application test (DAST).
 Hoặc sử dụng API để tương tác đến Database
 Validate dữ liệu người dùng, escape special characters
 Sử dụng LIMIT để tránh bị mất toàn bộ data trong trường hợp bị Injection.
 Đối với Command Injection, cần review kỹ những chỗ có thực thi lệnh
command bởi các keywords: system (shell_exec, exec, proc_open, eval,
passthru, proc_open, expect_open, ssh2_exec, popen)
 Cần kiểm tra kỹ Permission của web application, kể cả Database user, kể cả
operating system command execution.

12

2.2) A2: Broken Authentication
Những tính năng liên quan như đăng nhập, session management nếu không
implement một cách chính xác sẽ dễ cho Attacker vượt qua bước đăng nhập hoặc chiếm
quyền sử dụng của user. Một cách mà các Attacker thường sử dụng là dùng tools để thử đăng
nhập với hằng triệu tập username và brute force password.
Những điểm yếu như:
 Ứng dụng cho phép một công cụ tự động gửi nhiều request để đăng nhập, sau
đó Attacker sẽ dùng tool để quét cạn username và password để tìm ra cặp
user/pass có trong ứng dụng.
 Ứng dụng cho phép sử dụng những password yếu hoặc vô ý chưa remove
những user/pass mặc định.
 Tính năng quên mật khẩu nhưng thiếu an toàn với những câu hỏi dạng kiến
thức.
 Ứng dụng sử dụng plain text hoặc mã hoá đơn giản để lưu password.
 Phơi bày session id trong URL.
 Không regenerate session id sau khi login thành công.
Cách phòng tránh
 Nếu có thể nên implement two-factor authentication.
 Sử dụng captcha hay chặn client gửi nhiều request nhằm dò tìm user/pass bằng
cách brute force.
 Implement weak-password checks, tăng chiều dài của password hoặc có thể
xem xét không sử dụng top 1000 password phổ biến
 Change default password của các service.
 Giới hạn và tăng thời gian chờ vài lần cố gắng đăng nhập.
2.3) A3: Sensitive Data Exposure
Những ứng dụng web hay API không bảo vệ những dữ liệu nhạy cảm một cách đúng
đắn và để rò rỉ những thông tin như tài chính, sức khoẻ của khách hàng, thông tin cá nhân,
credit card...Hoặc đôi khi việc chia sẽ những tài liệu cá nhân cho bên thứ 3 sẽ thuộc loại quy
phạm quy định pháp luật tuỳ vào quy định của từng quốc gia.
Cần bảo vệ như thế nào?

 Kiểm tra việc lưu trữ sensitive data như thế nào, có phải plain text không? Dữ
liệu backup như thế nào?
13


 Không lưu trữ sensitive data nếu không cần thiết.
 Đảm bảo mã hoá tất cả các sensitive data.
 Sử dụng những phương thức bảo mật trong khi truyền/nhận data, TLS,
HTTPS.
 Kiểm tra việc chia sẽ sensitive data cho bên thứ 3.
2.4) A4: XML External Entities (XXE)
Những cấu hình dạng XML để lộ những thông tin như URI handler, internal file
shares, port rất dễ bị Attacker lợi dụng để tấn công.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
Scenario #2: An attacker probes the server's private network by
changing the above ENTITY line to:
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
Scenario #3: An attacker attempts a denial-of-service attack by
including a potentially endless file:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

2.5) A5: Broken Access Control
2.6) A6: Security Misconfiguration
Attackers thường khai thác những lổ hổng chưa được vá hoặc truy cập tài khoản mặc
định của các service sử dụng trong ứng dụng kể cả ở tầng network, web-server, platform,
database, containers,...

Cách phòng tránh
 Nên xem xét dọn rác những tính năng, service không cần thiết.
 Kiểm tra và dọn dẹp những user mặc định.
 Theo dõi các bảng cập nhật của từng service.
2.7) A7: Cross Site Scripting (XSS)
XSS là lỗi xảy ra nhiều thứ 2 trong Top 10 OWASP, ứng dụng bị lỗi XSS có thể ở
dạng bị vỡ cấu trúc DOM của website hay load và thực thi một javascript nguy hại, từ đó
Attacker có thể lấy thông tin cá nhân, thông tin đăng nhập, session,...
Cách phòng tránh
 Cẩn thận với những tính năng mà cho phép website hiển thị những dữ liệu mà
chưa được validate hay escape từ người dùng.
14


 Ứng dụng lưu trữ những data chưa được validate từ user sau đó hiển thị cho
những user khác. Cần escaping những data không an toàn từ người dùng.
2.8) A8: Insecure Deserialization
Việc deserialization không an toàn rất dễ dẫn đến thực thi một script từ attacker. Ví dụ
như bạn lưu một deserialization ở cookie hay localstorage và dùng data đó cho việc kiểm tra
phân quyền.
2.9) A9: Using Components with Know Vulnerabilities
Việc dùng những components, libraries, frameworks không an toàn sẽ làm cho ứng
dụng của bạn dễ bị khai thác hơn. Việc tận dụng những ứng dụng đã có và cộng với một khối
lượng code-base của nó khá lớn dễ dẫn đến bạn không hiểu và mất kiểm soát hay tệ hơn là
có cả nguy cơ bảo mật bên trong những thư việc này.
Cách phòng tránh
 Nên rà soát và remove những libraries, tính năng, files không cần thiết.
 Subscribe và theo dõi những lỗi bảo mật để kịp thời upgrade những
components.
2.10) A10: Insufficient Logging & Monitoring

Việc thiếu log hay monitoring không đầy đủ sẽ cho phép Attacker "đi dạo" đến rất
nhiều nơi trong hệ thống của bạn, ngược lại, nếu có đầy đủ monitoring, logging, và việc
Attacker đã tấn công 1 hoặc vài service ban đầu sẽ được phát hiện và nhanh chóng ngăn
chặn.
Cách phòng tránh
 Audit những sự kiện như failed login, service side input validation failures.
 Bảo đảm việc ghi log theo một định dạng chung để dễ quản lý và phân loại.
 Ghi nhận những high-value transactions hay slow query lại để kiểm tra.

3) Tường Lửa Bảo Vệ Ứng Dụng Web ModSecurity
3.1) Chức năng
Mod Security đứng trước Web Server, làm nhiệm vụ như một firewall để kiểm soát
truy cập vào ra Web Server. Các thông tin đi từ bên ngoài vào và bên trong ra sẽ được kiểm
soát chặt chẽ để tránh những thông tin có thể gây hại cho Web Server hay là việc rò rỉ các
thông tin đặc biệt từ Web Server đến Client.

15


Mod Security có thể thực hiện các chức năng cụ thể sau:
Parsing
ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu trúc dữ
liệu mà ModSecurity định nghĩa sẵn. Cấu trúc này sẽ được chuyển qua cơ chế so trùng mẫu
trong tập rule để phân tích nguy cơ.
Buffering
Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt động của
ModSec. Việc này có ý nghĩa khi các request gởi đến ứng dụng web thì phải thông qua
ModSecurity trước khi đến ứng dụng xử lý và những response cũng sẽ được phân tích trước
khi trả về phía client. Cơ chế này là cách duy nhất để có thể ngăn chặn các cuộc tấn công
thời gian thực, các dữ liệu mà ModSecurity nhận được và phân tích sẽ được lưu trữ trong

RAM (bao gồm request body và response data).
Logging
ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers, request body,
response header, response body nhằm hỗ trợ người quản trị phân tích nguy cơ mà hệ thống
đang gặp phải để có thể ra quyết định kiểm soát.
Rule Engine
Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát hiện các
dạng tấn công và thực hiện phòng chống. ModSecurity cùng phát triển với dự án OWASP
phát triển các mẫu để phân tích và phòng chống các tấn công hệ thống web.
3.2) Quy trình xử lý trong ModSecurity
Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước (pha), tại
mỗi bước ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các
khai thác.

16


Phase Request Header (1)
Rule được đặt tại đây sẽ được thực hiện ngay sau khi Web Server đọc request header,
lúc này phần request body vẫn chưa được đọc. Đâ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 của bước này nhằm cho phép người viết rule tương tác với
các request trước khi thực hiện các yêu cầu trong phần HTTP body. Phần này khá quan trọng
để phân tích các khai thác dựa vào HTTP method cũng như dựa vào URL như SQL
Injection, Reflect XSS, Local file include …
Phase Request body (2)
Đây là thời điểm các thông tin chức năng chung đưa vào được phân tích và xem xét,
các rule mang tính application-oriented thường được đặt ở đây. Bước này là quá trình kiểm
tra chính trong quá trình client gởi request đến server, phần này sẽ có hiệu quả khi người
dùng cố sử dụng phương thức POST hoặc PUT để upload tập tin lên phía server. Việc kiểm
tra này bảo đảm dữ liệu đưa lên server là an toàn, tránh tình trạng upload mã độc hoặc các

dạng tấn công như Stored XSS, Ajax Injection... ModSecurity hỗ trợ ba loại mã hóa request
body :
+

Application/x-www-form-urlencoded dùng để truyền form dữ liệu.
17


+

Multipart/form-data dùng để truyền file.

+

Text/xml : dùng để phân tích dữ liệu XML.

Phase Response headers (3)
Những request đã được xử lý tại server sẽ được trả về cho ModSecurity kiểm tra trạng
thái trong phần respone header. Trước khi phần respone body được đọc thì ModSecurity sẽ
dựa vào tập rule để xác định có cần kiểm tra nội dung dữ liệu trong phần body hay không.
Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần kiểm tra nội
dung gói tin trả về.
Phase Response body (4)
Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì nội dung
trong phần body sẽ được kiểm tra so trùng với mẫu trong tập lệnh.Việc này là khá hiệu quả
để phát hiện và phòng chống xâm nhập trong trường hợp bước 1 và 2 không phát hiện được
tấn công.
Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số công nghệ
evasion thì việc phát hiện khi request là khó khăn. Khi khai thác thành công, ModSecurity sẽ
phân tích kết quả trong gói tin trả về để phát hiện nếu như câu truy vấn thành công.

Phase Logging (5)
Đây là thời điểm các hoạt động log được thực hiện. Các rules đặt ở đây sẽ định rõ
việc log sẽ như thế nào, nó sẽ kiểm tra các error message log của Web Server. Đây cũng là
thời điểm cuối cùng để chặn các connection không mong muốn, kiểm tra các response
header không thể kiểm tra ở phase response header và phase response body.
3.3) Cấu trúc tập luật trong ModSecurity
SecRule được sử dụng để tạo các rule cho ModSecurity, cú pháp như sau:
SecRule VARIABLES OPERATOR [ACTIONS]
3.3.1) Variables
REMOTE_ADDR: Địa chỉ IP của client.
REMOTE_HOST: Hostname của client (nếu tồn tại) .
REMOTE_USER: Authenticated username (nếu tồn tại) .
REMOTE_IDENT: Remote Username (lấy từ inetd, ít dùng) .
REQUEST_METHOD: Request Method (GET, HEAD, POST..) .
SCRIPT_FILENAME: Đường dẫn đầy đủ của script được thực thi.
PATH_INFO: Phần mở rộng của URI phía sau tên của một script.
Ví dụ: /archive.php/5 thì PATH_INFO là /5
18


QUERY_STRING: URI phía sau dấu ?.
Ví dụ /index.php?i=1 thì QUERY_STRING là i=1.
AUTH_TYPE: Basic hoặc Digest Authentication.
DOCUMENT_ROOT: Đường dẫn đến documentroot.
SERVER_ADMIN: Email của Server Administrator.
SERVER_NAME: Hostname của Server.
SERVER_ADDR: Địa chỉ IP của Server.
SERVER_PORT: Server port.
SERVER_PROTOCOL: Protocol, (ví dụ HTTP/1.1).
SERVER_SOFTWARE: Apache version.

TIME_YEAR: Năm hiện tại.
TIME_MON: Tháng hiện tại.
TIME_DAY: Ngày.
TIME_HOUR: Giờ.
TIME_MIN: Phút.
TIME_SEC: Giây.
TIME_WDAY: Thứ tự ngày trong tuần (ví dụ 4 - Thursday).
TIME: Thời điểm hiện tại được viết theo cấu trúc : YmdHMS.
ví dụ: 20200328144530 : 28/03/2020 14h 45' 30''.
API_VERSION
THE_REQUEST: Dòng đầu tiên của request. vd: GET / HTTP/1.1.
REQUEST_URI: Request URI.
FILENAME: Tên file được yêu cầu đến.
IS_SUBREQ
3.3.2) Collections
Một variables có thể bao gồm 1 hay nhiều phần dữ liệu. Khi variable có nhiều hơn 1
giá trị thì ta gọi nó là collection.
Một ví dụ về một Collection là REQUEST_HEADERS, trong đó chứa tất cả các
trường trong thông điệp header mà Client gởi tới Server, chẳng hạn như User-agent hoặc
Referer.
19


Để truy cập vào một trường trong collection, chúng ta ghi tên collection, tiếp theo là
dấu hai chấm và sau đó là tên của trường hoặc tuỳ chọn mà chúng ta muốn truy cập. Ví dụ:
SecRule REQUEST_HEADERS:Referer "bad-referer.com"
Một vài collection có sẵn:
ARGS: tham số n nhằm chỉ định tìm kiếm mẫu trong tất cả các tham số trong request.
ENV
FILES

FILES_NAMES
FILES_SIZES
FILES_TMPNAMES
GEO
IP
REQUEST_COOKIES
REQUEST_COOKIES_NAMES
REQUEST_HEADERS
REQUEST_HEADERS_NAMES
RESPONSE_HEADERS
RESPONSE_HEADERS_NAMES
SESSION
TX
USER
3.3.3) Operators
Sử dụng @ để chỉ ra đây là một operation
Sử dụng !@ để chỉ ra một operation negation
Toán tử @rx (regular expression) là một toán tử mặc định, được sử dụng khi không
có một toán tử nào khác được chỉ định.
Biểu Thức

Ý Nghĩa Phù Hợp

[Jj]oy Thể hiện mọi chuỗi có chứa Joy hoặc joy
[0-9] Bất kỳ số nào từ 0 đến 9
[a-zA-Z] Mọi chữ từ a đên z và từ A đến Z
20


^ Bắt đầu một chuỗi

^Host Từ Host khi tìm thấy ở đầu 1 chuỗi
$ Kết thúc một chuỗi
^Host$ Chuỗi chỉ gồm từ Host
. Một từ bất kỳ
p.t Ví dụ như pot,pet,pat,…

Toán tử

Tác Dụng

Ví Dụ

@beginsWith Khớp các chuỗi bắt đầu
với chuỗi chỉ định

SecRule REQUEST_LINE
“!@beginsWith GET”

@containts Khớp các chuỗi có chứa
chuỗi chỉ định tại bất cứ vị
trí nào

SecRule REQUEST_LINE
“@contains select”

@containsWor Khớp xâu chứa từ được chỉ SecRule ARGS “@containsWord
d định. “Từ” ở đây được
from”
hiểu là đoạn xâu được
ngăn bởi một hoặc nhiều

ký tự không phải chữ, số.
@endsWith Khớp xâu kết thúc bởi xâu
chỉ định
@streq Khớp xâu giống hoàn toàn
xâu chỉ định

SecRule ARGS “@endsWith --”
SecRule REMOTE_HOST
“@streq victim\.com”

@within Giống @contains, chỉ khác SecRule REMOTE_USER
là một so khớp xảy ra khi
“@within giang, hue, hung”
biến cần so xuất hiện bên
trong xâu được chỉ định
(sẽ khớp nếu remote user là giang, hue
hoặc hung)
@pm Khớp với một trong những
cụm từ đi sau nó

21

SecRule ARGS "@pm red green blue"
deny


@pmFromFile Nếu có quá nhiều chuỗi
SecRule ARGS “@pmFromFile
muốn đặt vào, ta có thể liệt /usr/log/alo.txt”
kê các chuỗi này vào một

file và dùng
@pmFromFile
Toán Tử

Toán Tử Đại Số
Tương Đương

Ví Dụ

@eq

=

SecRule RESPONSE_STATUS “@eq 200”

@ge

≥

SecRule RESPONSE_STATUS “@ge 400”

@gt

>

SecRule RESPONSE_STATUS “@gt 399”

@le

≤

SecRule RESPONSE_STATUS “@le 199”

@lt

<

SecRule RESPONSE_STATUS “@lt 200”

3.3.4) Actions
Khi request vi phạm một rule nào đó thì ModSecurity sẽ thực thi một hành động
(action). Khi action không được chỉ rõ trong rule thì rule đó sẽ sử dụng default action . Có 3
loại actions :
Primary Actions:
Primary actions sẽ quyết định cho phép request tiếp tục hay không. Mỗi rule chỉ có
một primary action. Có 4 primary actions :
Deny : Request sẽ bị ngắt, ModSecurity sẽ trả về HTTP status code 500 hoặc là
status code của người thiết lập trong chỉ thị status.
Pass : Cho phép request tiếp tục được xử lý ở các rules tiếp theo.
Allow : Cho phép truy cập ngay lập tức và bỏ qua các phases khác (trừ phases
logging). Nếu muốn chỉ cho qua phase hiện tại thì cần chỉ rõ allow:phase Khi đó sẽ vẫn được
kiểm tra bởi các luật tại các phases sau. Chỉ cho phép truy cập tới các request phases:
allow:request, nó sẽ cho qua phase 1,2 và vẫn kiểm tra ở phase 3 trở đi.
Redirect : Redirect một request đến một url nào đó.
Secondary Actions:
Secondary actions sẽ bổ sung cho Primary actions, một rule có thể có nhiều
Secondary actions
Status: n : khi một Request vi phạm một rule nào đó thì ModSecurity có thể trả về các
HTTP status code n thay vì status code 500 mặc định.
22

exec: thực thi một lệnh nào đó nếu một request vi phạm.
log: ghi log những request vi phạm rule.
nolog: không ghi log
pause: n : ModSecurity sẽ đợi một thời gian n ms rồi mới trả về kết quả.
Flow Actions:
Chain : kết nối 2 hay nhiều rules lại với nhau.
Skipnext : n : ModSecurity sẽ bỏ qua n rules theo sau nó.
Default Action:
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập
trong SecDefaultAction.
Ví dụ : SecDefaultAction "phase:2,deny,log,status:403"
3.4) Xây dựng tập luật phát hiện và chống tấn công trong ModSecurity
ModSecurity sau khi đã được cài đặt thành công cần được cấu hình các tập rule để có
thể hoạt động như một WAF. Tuy nhiên, việc tự viết và triển khai các rule là khá phức tạp và
tốn thời gian để tối ưu các chức năng trong rule.
Nhóm nghiên cứu Truswave SpiderLabs đã phát triển một nhóm các tập lệnh có tên là
OWASP ModSecurity CRS, bao gồm các nội dung gói tin của kiểu tấn công đã được biết
đến. Một tính năng mạnh mẽ của CRS là có thể bảo vệ những ứng dụng web phổ biến cũng
như những ứng dụng web tự phát triển riêng biệt.
Chính vì vậy trong phần này, chỉ tập trung vào phân tích và tinh chỉnh tập luật CRS
sao cho dễ hiểu và phù hợp hơn với các dạng tấn công phổ biến như SQL Injection, XSS,
Local File Include.
3.4.1) Xây dựng tập luật phát hiện và chống tấn công SQL Injection
- Các từ khóa chính thường sử dụng trong tấn công SQL Injection và các regular
expressions tương ứng :
UNION SELECT

union\s+select

UNION ALL SELECT

union\s+all\s+select

INTO OUTFILE

into\s+outfile

DROP TABLE

drop\s+table

ALTER TABLE

alter\s+table

LOAD_FILE

load_file

SELECT *

select\s+*
23


\s : được định nghĩa trong PCRE là một regular expression cho phép phát hiện mọi
khoảng trắng và cả các mã thay thế (%20)
- Ngoài ra trong SQL còn có các dấu comment:

#
/*
-- ;%00
Các dấu comment trong MySQL được hiểu nếu trong câu truy vấn gặp dấu comment
thì toàn bộ phần truy vấn đằng sau sẽ được hiểu thành comment và không được thực hiện.
Ví dụ như câu truy vấn: ' OR 1=1 -- -' ORDER BY id;
Câu này sẽ được hiểu thành: ' OR 1=1 -- -' phần ORDER BY id bị hiểu thành
comment của câu truy vấn.
Tiếp theo trong một form đăng nhập sau khi người dùng POST dữ liệu lên server thì
Server sẽ kiểm tra xem trong cơ sở dữ liệu có các bản ghi tương ứng không. Vì vậy có một
số cách mà hacker thường sử dụng:
' OR '1
' OR 1 -- " OR "" = "
" OR 1 = 1 -- '='
'LIKE'
'=0--+
Bản chất của những đoạn mã này là việc inject vào ứng dụng một câu truy vấn nhằm
biến câu truy vấn trở thành luôn đúng và có thể Bypass qua việc truy vấn các bản ghi trong
cơ sở dữ liệu của website.
*) Sử dụng tập luật OWASP ModSecurity CRS để chặn tấn công SQL Injection:
Ví dụ: Luật chặn các ký tự comment của CRS:
Xét đoạn regex:
(/\*!?|\*/|[';]--|--[\s\r\n\v\f]|(?:--[^-]*?-)|([^\-&])#.*?[\s\r\n\v\f]|;?\\x00)
Đoạn regex này với ý nghĩa bỏ qua tất cả các ký tự: ‘\*’, ‘--’, ‘-’….
-> Luật được thiết lập:
24


SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!
REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|

XML:/* "@rx (?:/\*!?|\*/|[';]--|--[\s\r\n\v\f]|--[^-]*?-|[^&-]#.*?[\s\r\n\v\f]|;?\\x00)" \
"id:942440,\
phase:2,\
block,\
capture,\
t:none,t:urlDecodeUni,\
msg:'SQL Comment Sequence Detected',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %
{MATCHED_VAR}',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-sqli',\
tag:'OWASP_CRS',\
tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
tag:'WASCTC/WASC-19',\
tag:'OWASP_TOP_10/A1',\
tag:'OWASP_AppSensor/CIE1',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/2',\
ver:'OWASP_CRS/3.2.0',\
severity:'CRITICAL',\
setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}',\
setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}'"
Trong đó:
+ Variable: REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!
REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|
ARGS|XML:/*
Trích xuất các giá trị trong HTTP request để đưa vào phần phân tích
25