Bối cảnh và vấn đề nghiên cứu

Trong môi trường công nghệ thông tin hiện đại, các ứng dụng web của doanh nghiệp và cơ quan chính phủ phải đối mặt đồng thời với hai thách thức lớn: giảm thiểu nguy cơ an ninh mạng và đảm bảo tuân thủ các quy trình công nghiệp cũng như quy định pháp lý của chính phủ. Các hệ thống tường lửa mạng truyền thống (Network Firewall) hoạt động ở tầng mạng và tầng giao vận không đủ khả năng phân tích sâu nội dung gói tin ở tầng ứng dụng (Lớp 7 - Layer 7), dẫn đến việc không thể phát hiện và ngăn chặn hiệu quả các hình thức tấn công nhắm trực tiếp vào máy chủ web và logic ứng dụng.

Trước thực trạng đó, đề án "Nghiên cứu ứng dụng Mod Security để bảo vệ web server" được thực hiện nhằm giải quyết các nhiệm vụ trọng tâm sau:

  1. Nghiên cứu tổng quan về cơ chế can thiệp trực tiếp ở mức ứng dụng của giải pháp Tường lửa ứng dụng Web (Web Application Firewall - WAF) ModSecurity.
  2. Tìm hiểu và phân tích cấu trúc hoạt động, quy trình xử lý 5 pha (phase), hệ thống tập lệnh (ruleset) và các tiêu chuẩn bảo mật theo OWASP Top Ten.
  3. Cài đặt, biên dịch từ mã nguồn, chuẩn hóa cấu hình hệ thống ModSecurity tích hợp trên máy chủ web Apache chạy nền tảng Linux.
  4. Triển khai bộ quy tắc chuẩn OWASP ModSecurity Core Rule Set (CRS) và phân tích chuyên sâu các kịch bản xây dựng luật (rule) tùy biến để xử lý các dạng tấn công web thực tế.

Đối tượng và phạm vi nghiên cứu của đề án:

  • Đối tượng nghiên cứu: Module mở rộng ModSecurity (phiên bản 2.x), máy chủ web Apache HTTP Server, bộ luật OWASP Core Rule Set (CRS) và các lỗ hổng bảo mật ứng dụng web theo danh mục OWASP Top Ten 2010.
  • Phạm vi thực hiện: Nghiên cứu và thực nghiệm kỹ thuật trên hệ điều hành Linux (CentOS); thời gian thực hiện trong 14 tuần bởi nhóm 02 sinh viên dưới sự hướng dẫn của TS. Lưu Thanh Trà (khoa CNTT, phê duyệt ngày 28/02/2013).

Cơ sở lý thuyết và phương pháp

Khung lý thuyết và công nghệ nền tảng

Đề án xây dựng trên nền tảng lý thuyết an toàn ứng dụng web của Dự án Bảo mật Ứng dụng Web Mở (Open Web Application Security Project - OWASP) và tài liệu hướng dẫn kiểm thử ứng dụng web (OWASP Testing Guide v3, 2010). Các nhóm nguy cơ chính được phân tích gồm:

  • A1 - Injection: Các lỗi chèn mã độc như SQL Injection, OS Command Injection, LDAP Injection thông qua các câu truy vấn dữ liệu.
  • A2 - Cross-Site Scripting (XSS): Cho phép kẻ tấn công chèn mã HTML, JavaScript vào phiên duyệt web của người dùng khác để đánh cắp Session Cookie hoặc thay đổi giao diện (deface).
  • A3 - Broken Authentication and Session Management: Các khiếm khuyết trong quản lý xác thực và phiên làm việc.
  • A4 - Insecure Direct Object References: Tham chiếu đối tượng trực tiếp không an toàn tới tệp tin, thư mục hoặc cơ sở dữ liệu.
  • A5 - Cross-Site Request Forgery (CSRF): Lợi dụng quyền đăng nhập của người dùng để thực thi các yêu cầu trái phép.
  • A6 - Security Misconfiguration: Lỗi cấu hình môi trường máy chủ web, cơ sở dữ liệu và hệ điều hành.
  • A7 - Insecure Cryptographic Storage: Lưu trữ dữ liệu nhạy cảm (mật mã, thông tin thẻ tín dụng) không được mã hóa hoặc băm an toàn.
  • A8 - Failure to Restrict URL Access: Không kiểm soát chặt chẽ quyền truy cập vào các đường dẫn URL nhạy cảm.
  • A9 - Insufficient Transport Layer Protection: Sử dụng chứng chỉ số yếu, hết hạn hoặc không mã hóa dữ liệu truyền tải trên mạng.
  • A10 - Unvalidated Redirects and Forwards: Chuyển hướng và chuyển tiếp URL không được kiểm soát.

Về mặt công nghệ WAF, đồ án phân tích ModSecurity với hai đặc tính nền tảng:

  • Tính linh động (Flexibility): Hỗ trợ phân tích luồng HTTP đa dạng, so trùng mẫu dựa trên Regular Expressions và các toán tử chuyên dụng, kết hợp với các bộ quy tắc chuẩn (CRS).
  • Tính thụ động (Passivity): ModSecurity hoạt động nghiêm ngặt dựa trên chỉ định của quản trị viên; chỉ thực hiện cảnh báo hoặc can thiệp khi có luật được thiết lập tương ứng.

Phương pháp nghiên cứu

Đề án sử dụng phối hợp các phương pháp nghiên cứu thực nghiệm và phân tích kỹ thuật:

  1. Phương pháp phân tích - tổng hợp lý thuyết: Hệ thống hóa toàn bộ cú pháp, danh mục 77 biến, 4 nhóm toán tử, 7 nhóm hành vi và quy trình phân tích gói tin của ModSecurity.
  2. Phương pháp thực nghiệm và triển khai hệ thống: Biên dịch mã nguồn ModSecurity, cài đặt các thư viện phụ trợ (APR, libxml2, PCRE, libcurl, Lua) trên Linux CentOS, liên kết với Apache HTTP Server qua module mod_security2.so và mod_unique_id.so.
  3. Phương pháp kiểm thử và phân tích an toàn:
    • Giả lập các cuộc tấn công bằng công cụ dòng lệnh (như curl) và trình duyệt để kiểm tra phản hồi của hệ thống.
    • Sử dụng công cụ BurpSuite (Module Sequencer) để thu thập mẫu dữ liệu (1.090 Session Cookie) nhằm phân tích entropy (tính ngẫu nhiên) của phiên làm việc trên ứng dụng thực tế.

Thiết kế và triển khai hệ thống

Kiến trúc chức năng và quy trình xử lý của ModSecurity

Hệ thống ModSecurity tích hợp trong máy chủ web vận hành dựa trên 4 chức năng cốt lõi:

  • Parsing: Phân tách toàn bộ dữ liệu HTTP luân chuyển qua máy chủ thành các cấu trúc định sẵn phục vụ so trùng mẫu.
  • Buffering: Lưu trữ đệm dữ liệu của Request Body và Response Body trên bộ nhớ RAM để phân tích thời gian thực trước khi gửi tới ứng dụng xử lý hoặc phản hồi về máy khách (client).
  • Logging: Ghi nhận toàn bộ nhật ký HTTP giao dịch (Headers, Body, Audit log) để hỗ trợ điều tra và kiểm soát rủi ro.
  • Rule Engine: Bộ máy xử lý quy tắc thực thi phân tích so trùng mẫu dựa trên các luật được nạp.

Quy trình xử lý một phiên giao dịch HTTP của ModSecurity diễn ra tuần tự qua 5 pha (Phase):

Pha (Phase) Tên pha Chức năng chi tiết
Phase 1 Request Header Phân tích các tiêu đề HTTP, phương thức (GET, POST, HEAD...) và URL trước khi xử lý phần thân gói tin; nhận diện sớm các dạng tấn công như SQLi, Reflected XSS, LFI trên URL.
Phase 2 Request Body Kiểm tra dữ liệu trong thân yêu cầu HTTP khi client sử dụng phương thức POST hoặc PUT; chống tải lên mã độc, Stored XSS, AJAX Injection.
Phase 3 Response Headers Đọc và kiểm tra trạng thái trong tiêu đề phản hồi từ server; quyết định có cần tiếp tục quét nội dung thân phản hồi hay không (ví dụ: mã lỗi 404 có thể bỏ qua).
Phase 4 Response Body Phân tích nội dung dữ liệu trả về client; ngăn chặn kỹ thuật vượt rào (evasion) của hacker và phòng chống nguy cơ rò rỉ dữ liệu nhạy cảm.
Phase 5 Logging Ghi nhật ký các cảnh báo, lịch sử giao dịch và vết hoạt động của phiên làm việc.

Cấu trúc triển khai và cấu hình hệ thống

Quy chuẩn thư mục được thiết lập tường minh nhằm phục vụ quản trị, phân quyền và lưu trữ dữ liệu an toàn trên máy chủ:

Thư mục Quyền sở hữu (Owner/Group) Phân quyền (Permissions) Mục đích sử dụng
/opt/modsecurity/bin root / apache rwxr-x--- Chứa các tệp thực thi nhị phân
/opt/modsecurity/etc root / root rwx------ Chứa các tệp tin cấu hình và luật
/opt/modsecurity/var/audit apache / root rwx------ Lưu trữ nhật ký kiểm toán (audit logs)
/opt/modsecurity/var/data apache / root rwx------ Lưu trữ dữ liệu phiên (persistent data)
/opt/modsecurity/var/log root / root rwx------ Chứa nhật ký hệ thống chung
/opt/modsecurity/var/tmp apache / apache rwxr-x--- Chứa dữ liệu tệp tạm thời
/opt/modsecurity/var/upload apache / root rwx------ Chứa các tệp tin tải lên bị chặn để quét

Cấu hình máy chủ web Apache nạp các tệp tin theo thứ tự phân lớp thông qua tệp /etc/httpd/conf.d/Modsecurity.conf:

  • main.conf: Tệp tin cấu hình chính (thiết lập bộ đệm, log, tham số dung lượng).
  • rules-first.conf: Các luật kiểm tra ưu tiên thực hiện đầu tiên.
  • rules.conf: Tập lệnh thực thi chính.
  • rules-last.conf: Tập lệnh xử lý cuối cùng.

Các chỉ thị cấu hình quản lý bộ đệm và giới hạn tài nguyên quan trọng gồm:

  • SecRequestBodyAccess On: Bật kiểm tra thân yêu cầu HTTP.
  • SecRequestBodyLimit 13107200: Giới hạn tối đa kích thước Request Body là 12,5 MB (13.107.200 bytes).
  • SecRequestBodyNoFilesLimit 131072: Giới hạn tối đa kích thước dữ liệu không phải tệp tải lên là 128 KB (131.072 bytes) để tối ưu bộ nhớ RAM.
  • SecRequestBodyInMemoryLimit 131072: Kích thước đệm dữ liệu tối đa trên RAM (128 KB); vượt quá ngưỡng này dữ liệu sẽ được lưu tạm vào vùng swap trên ổ đĩa.
  • SecResponseBodyAccess Off: Khuyến nghị tắt quét thân phản hồi mặc định để tiết kiệm tài nguyên CPU/RAM, chỉ bật khi cần kiểm soát rò rỉ dữ liệu.
  • SecResponseBodyMimeType text/plain text/html text/xml: Chỉ định các định dạng MIME cần quét khi bật quét Response Body.

Nội dung chính theo từng phần của đề tài

1. Triển khai OWASP ModSecurity Core Rule Set (CRS)

Đề án triển khai bộ quy tắc Core Rule Set (phiên bản 2.x do Trustwave SpiderLabs phát triển theo giấy phép ASLv2). CRS phân chia các luật thành các nhóm chuyên biệt:

  • HTTP Protection & Real-time Blacklist Lookups: Kiểm soát tính hợp lệ của giao thức HTTP và tra cứu danh sách đen IP.
  • Web-based Malware Detection: Sử dụng Google Safe Browsing API để phát hiện mã độc nhúng trong trang web.
  • Denial of Service (DoS) Protections: Ngăn chặn tấn công làm tràn ngập HTTP (HTTP Flooding) và Slow HTTP DoS.
  • Common Web Attacks Protection: Phát hiện các dạng tấn công phổ biến (SQLi, XSS, Command Injection, LFI/RFI).
  • Tracking Sensitive Data & Error Detection: Giám sát rò rỉ dữ liệu thẻ tín dụng và che giấu các thông báo lỗi nhạy cảm của hệ thống.

2. Cú pháp và ngôn ngữ xây dựng luật (Rule Language)

Cú pháp tổng quát của một luật trong ModSecurity:

SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]
  • Chỉ thị điều khiển (Directives): Gồm 9 chỉ thị chính (SecAction, SecDefaultAction, SecMarker, SecRule, SecRuleInheritance, SecRuleRemoveById, SecRuleRemoveByMsg, SecRuleScript, SecRuleUpdateActionById, SecRuleUpdateTargetById).
  • Hệ thống biến (Variables): Hỗ trợ 77 loại biến được phân loại thành biến đơn (Scalar), biến tập hợp (Collections: Request, Server, Response, Miscellaneous, Parsing flags, Time, TX - Transient transaction data).
  • Toán tử (Operators): Chia thành 4 nhóm gồm so trùng chuỗi (@rx, @pm, @contains, @beginsWith, @endsWith), toán tử số học (@eq, @ge, @gt, @le, @lt), toán tử kiểm tra (@validateByteRange, @validateDTD, @validateSchema, @validateUrlEncoding, @validateUtf8Encoding), và toán tử đặc biệt (@geoLookup, @verifyCC, @verifySSN, @ipMatch, @rbl).
  • Hàm biến đổi (Transformation Functions): Xử lý dữ liệu đầu vào chống kỹ thuật biến đổi (obfuscation) như t:lowercase, t:compressWhitespace, t:base64Decode, t:htmlEntityDecode, t:hexEncode.
  • Hành vi (Actions): 7 nhóm hành vi điều khiển bao gồm Disruptive (deny, drop, block, allow, pass, redirect), Flow (chain, skip, skipAfter), Metadata (id, phase, msg, rev, severity, tag), Variable (setvar, capture, setsid, setuid), Logging (log, auditlog, nolog), Special (ctl, t, multiMatch), và Miscellaneous (status, append, prepend, exec).

3. Phân tích các kịch bản luật ứng dụng thực tế

Đề tài phân tích và xây dựng cấu hình cho 6 kịch bản tấn công điển hình:

+---------------------------------------------------------------------------------------+
|                       6 KỊCH BẢN PHÒNG CHỐNG TẤN CÔNG THỰC TẾ                         |
+---------------------------------------------------------------------------------------+
| 1. Chống Replay Attack & Can thiệp dữ liệu: Đánh token băm ngẫu nhiên (rv_token).     |
| 2. Phòng chống Session Fixation: Phân tích entropy cookie và cấp token xác thực mới.  |
| 3. Phòng chống HTTP Response Splitting: Bắt ký tự CR/LF (%0d, %0a) trong header/URI. |
| 4. Phòng chống Path Traversal: Kiểm soát ký tự điều hướng thư mục (../, ..\).         |
| 5. Phát hiện lộ thông tin thẻ tín dụng: Quét Response Body bằng toán tử @verifyCC.    |
| 6. Phát hiện hành vi đăng nhập Brute-force: Đếm tần suất và tính điểm bất thường.     |
+---------------------------------------------------------------------------------------+
  • Trường hợp 1 - Chống Replay Attack thông qua cơ chế đánh token ngẫu nhiên (OWASP-WS-007): Sử dụng các chỉ thị SecContentInjection On, SecStreamOutBodyInspection On, SecHashEngine On, SecHashKey rand keyOnly, và SecHashParam rv_token. Khi Apache trả mã HTML về máy khách, ModSecurity tự động chèn một giá trị băm kiểm tra vào các liên kết (href). Khi client gửi yêu cầu, luật ID 1000 sẽ kiểm tra tính toàn vẹn thông qua toán tử @validateHash. Nếu token bị xóa hoặc sửa đổi, yêu cầu sẽ bị chặn ngay lập tức.
  • Trường hợp 2 - Phát hiện Session Cookie không hợp lệ và chống Session Fixation (OWASP-SM-003): Đề tài tiến hành thu thập 1.090 mẫu cookie amSessionId từ trang thử nghiệm demo.net bằng BurpSuite Sequencer, phát hiện các vị trí 0, 1, 5, 6 hoàn toàn cố định, tính ngẫu nhiên thấp và dễ bị đoán trước. Để khắc phục, luật ID 981062 ghi nhận amSessionId từ RESPONSE_HEADERS:Set-Cookie, tạo mã băm định danh và lưu vào biến session.valid=1. Luật ID 981054 tại Phase 1 sẽ đối soát REQUEST_COOKIES, nếu cookie không tồn tại trong phiên hợp lệ của server (&SESSION:VALID !@eq 1), hệ thống sẽ tăng điểm bất thường (tx.anomaly_score) và chặn yêu cầu.
  • Trường hợp 3 - Phòng chống HTTP Response Splitting (OWASP-DV-016): Khai thác việc chèn các ký tự Carriage Return (\r - %0d) và Linefeed (\n - %0a) vào các tham số URL nhằm tách tiêu đề HTTP, tạo tiền đề cho tấn công DOM XSS hoặc Cache Poisoning. ModSecurity sử dụng luật ID 950910 và 950911 để quét REQUEST_COOKIES, ARGS, XML bằng biểu thức chính quy [\n\r](?:content-(type|length)|set-cookie|location): và (?:\bhttp\/(?:0\.[01])|<(?:html|meta)\b), sau đó thực hiện chặn và ghi nhận audit log.
  • Trường hợp 4 - Phòng chống Path Traversal (OWASP-AZ-001): Sử dụng tập luật modsecurity_crs_42_tight_security.conf để kiểm soát các chuỗi ký tự phân cách đường dẫn thư mục (/, \, ..) được gửi lên qua URI hoặc tham số.
  • Trường hợp 5 - Phát hiện nguy cơ lộ thông tin thẻ tín dụng (A7 - Insecure Cryptographic Storage): Kích hoạt chức năng quét RESPONSE_BODY kết hợp toán tử chuyên dụng @verifyCC để nhận diện các chuỗi số thẻ tín dụng hợp lệ trong dữ liệu trả về, ngăn ngừa rò rỉ dữ liệu thanh toán.
  • Trường hợp 6 - Phát hiện hành vi đăng nhập vét cạn (Brute-force): Sử dụng các biến lưu trữ trạng thái (TX, SESSION) và toán tử số học (@gt, @ge) kết hợp setvar:tx.score để đếm số lần đăng nhập sai từ một địa chỉ IP trong khoảng thời gian nhất định, tự động áp dụng hành vi khóa kết nối tạm thời.

Kết quả và đóng góp

Kết quả thực nghiệm kỹ thuật

Đề tài đã hoàn thành việc xây dựng và kiểm thử thành công hệ thống ModSecurity WAF trên nền tảng CentOS/Apache:

  1. Kiểm thử tấn công SQL Injection:

    • Thử nghiệm gửi chuỗi truy vấn: http://www.com/?p=1%20order%20by%201,2,4.
    • Trước khi triển khai CRS: Máy chủ Apache trả về trang lỗi cơ sở dữ liệu chi tiết, để lộ thông tin cấu trúc dữ liệu.
    • Sau khi triển khai CRS: ModSecurity can thiệp tại Phase 2, từ chối truy cập với mã HTTP 403 Forbidden.
    • Nhật ký ghi nhận: Rule ID 959070 (tệp modsecurity_crs_41_sql_injection_attacks.conf, mức độ nghiêm trọng CRITICAL) bắt chính xác mẫu biểu thức \b(?i:having)\b... và khớp dữ liệu Matched Data: order by found within ARGS:p.

  2. Kiểm thử can thiệp URL và Replay Attack:

    • Khi người dùng cố tình xóa bỏ tham số rv_token=f3f6de81f7e3... trên URL để chèn câu lệnh SQLi .../owasp-top-10-tools-and-tactics/ and union select 1,2,3,4,5,6, hệ thống lập tức kích hoạt cảnh báo Rule ID 1000 (Request Validation Violation), ghi nhận vi phạm vào audit log và khóa kết nối.

  3. Kiểm thử tính hợp lệ của Cookie phiên:

    • Triển khai thành công các quy tắc AppSensor (Rule ID 981062 và 981054), nhận diện chính xác các cookie tùy chỉnh (amSessionId) và từ chối các cookie giả mạo do kẻ tấn công tự sinh.

Đóng góp của đề tài

  • Hệ thống hóa toàn diện cơ chế hoạt động 5 pha, bảng tra cứu cú pháp 77 biến, 4 nhóm toán tử, 7 nhóm hành vi của ModSecurity.
  • Xây dựng tài liệu hướng dẫn kỹ thuật chi tiết từ khâu biên dịch mã nguồn, phân quyền thư mục theo tiêu chuẩn bảo mật, đến tích hợp bộ luật chuẩn OWASP CRS v2.
  • Đưa ra giải pháp cấu hình thực tế cho 6 bài toán an toàn ứng dụng web cụ thể, giúp quản trị viên có thể ứng dụng trực tiếp để bảo vệ máy chủ web mà không cần can thiệp chỉnh sửa mã nguồn của ứng dụng.

Hạn chế và hướng nghiên cứu tiếp

Hạn chế

  • Tiêu hao tài nguyên hệ thống: Quá trình phân tích cú pháp biểu thức chính quy (Regular Expressions), quản lý dữ liệu đệm trên RAM và ghi nhật ký giao dịch đầy đủ (Full Transaction Logging) làm gia tăng mức độ sử dụng CPU, RAM và tài nguyên I/O đĩa cứng.
  • Xử lý tệp tải lên: Việc lưu giữ và kiểm tra các tệp tin tải lên (SecUploadDir) có thể làm tăng dung lượng lưu trữ do tệp trùng lặp và làm giảm hiệu suất xử lý chung của web server.
  • Mô hình nhúng trực tiếp: Triển khai ModSecurity dưới dạng module nhúng trực tiếp vào Apache có thể gây ảnh hưởng đến tính sẵn sàng của web server chính khi lưu lượng truy cập tăng cao đột biến.

Hướng nghiên cứu tiếp

  • Nghiên cứu chuyển đổi mô hình triển khai ModSecurity từ dạng module tích hợp sang mô hình Tường lửa ngược độc lập (Reverse Proxy) để phân tách tải xử lý, đảm bảo tính ổn định về tài nguyên cho máy chủ ứng dụng gốc.
  • Tối ưu hóa tập luật: Ưu tiên sử dụng các toán tử số học (@eq, @gt) hoặc toán tử so khớp song song (@pm) thay thế cho các biểu thức chính quy phức tạp để giảm tải tiêu thụ CPU.
  • Ứng dụng công nghệ ảo hóa để quản lý và điều phối động tài nguyên phần cứng cho WAF dựa trên lưu lượng thực tế.

Giá trị tham khảo

Tài liệu đề tài có giá trị tham khảo thiết thực cho:

  • Sinh viên các ngành Công nghệ thông tin, An toàn thông tin, Mạng máy tính: Sử dụng làm tài liệu nghiên cứu chuyên sâu về cơ chế hoạt động của WAF, quy trình xử lý giao thức HTTP và phương pháp phân tích lỗ hổng theo chuẩn OWASP.
  • Kỹ sư quản trị hệ thống và chuyên viên an ninh mạng: Tham khảo tài liệu hướng dẫn quy chuẩn về phân quyền thư mục, các chỉ thị cấu hình tối ưu bộ nhớ đệm và các mẫu luật xử lý các sự cố an ninh thực tế (SQLi, Session Fixation, HTTP Response Splitting, Replay Attack).

Câu hỏi thường gặp

1. Quy trình xử lý của ModSecurity diễn ra qua những pha (phase) nào?

ModSecurity thực thi phân tích dữ liệu qua 5 pha tuần tự: Phase 1 (Request Header), Phase 2 (Request Body), Phase 3 (Response Headers), Phase 4 (Response Body), và Phase 5 (Logging). Mỗi pha đảm nhiệm việc kiểm tra một thành phần dữ liệu cụ thể trước hoặc sau khi ứng dụng web xử lý gói tin.

2. Tại sao ModSecurity phiên bản sau 2.5 bổ sung chỉ thị SecRequestBodyNoFilesLimit bên cạnh SecRequestBodyLimit?

Trong các phiên bản trước 2.5, chỉ thị SecRequestBodyLimit áp dụng chung cho cả dữ liệu POST thông thường và dữ liệu tải tệp lên, dẫn đến việc phải duy trì một bộ đệm lớn. Nhận thấy quá trình tải tệp chủ yếu tiêu tốn I/O đĩa cứng chứ không cần nạp toàn bộ vào RAM, các nhà phát triển đã tách riêng SecRequestBodyNoFilesLimit (mặc định 128 KB) để giới hạn riêng phần dữ liệu nhập từ người dùng, giúp tiết kiệm đáng kể bộ nhớ RAM.

3. Cơ chế chống tấn công Replay Attack và can thiệp URL trong đề án hoạt động như thế nào?

ModSecurity sử dụng các chỉ thị SecContentInjection, SecStreamOutBodyInspection, và SecHashEngine để tự động tính toán giá trị băm ngẫu nhiên và gắn thêm một tham số token (rv_token) vào các liên kết HTML khi máy chủ phản hồi. Khi có yêu cầu gửi lên, toán tử @validateHash sẽ kiểm tra tính hợp lệ của token này; nếu token bị thiếu hoặc bị sửa đổi, yêu cầu sẽ bị chặn lại.

4. Nhóm tác giả đã sử dụng công cụ gì để đánh giá tính ngẫu nhiên của Session Cookie trên ứng dụng thực tế?

Nhóm tác giả đã sử dụng công cụ BurpSuite (Module Sequencer) để thu thập và phân tích 1.090 mẫu Session Cookie mang tên amSessionId từ trang demo.net. Kết quả phân tích thống kê cho thấy các vị trí 0, 1, 5, 6 trong chuỗi cookie không thay đổi, entropy thấp và có thể bị kẻ tấn công đoán trước để thực hiện tấn công Session Fixation.

Kết luận

Đề án "Nghiên cứu ứng dụng Mod Security để bảo vệ web server" do nhóm sinh viên thực hiện dưới sự hướng dẫn của TS. Lưu Thanh Trà đã hoàn thành trọn vẹn mục tiêu nghiên cứu và triển khai thực nghiệm một hệ thống Tường lửa Ứng dụng Web hoàn chỉnh. Bằng việc kết hợp ModSecurity trên máy chủ Apache với bộ quy tắc chuẩn OWASP Core Rule Set v2, đề tài đã chứng minh tính hiệu quả vượt trội trong việc phát hiện và ngăn chặn các nguy cơ tấn công tầng ứng dụng nguy hiểm như SQL Injection, HTTP Response Splitting và Session Fixation. Toàn bộ nội dung đồ án cung cấp một tài liệu kỹ thuật có giá trị thực tiễn cao, đóng góp giải pháp bảo mật vững chắc cho các hệ thống máy chủ web doanh nghiệp và cơ quan chính phủ.