MỤC LỤC
Khi chức năng quản lý request body được sử dụng, thì ModSecurity không những sẽ theo dừi nội dung gúi tin mà cũn sẽ lưu trữ nội dung trong bộ đệm (buffer) để phõn tớch trong trường hợp dữ liệu gởi đến server cần nhiều hơn một gói tin HTTP. Trong phiên bản trước 2.5, ModSecurity chỉ hỗ trợ SecRequestBodyLimit dùng để giới hạn kích thước gói tin request đến server, bao gồm gói tin với POST method bình thường (ví dụ:. nhập username, password) và các gói tin dùng POST method để upload tập tin. Hơn nữa, hầu hết các cuộc tấn công thường xuất hiện bên ngoài hệ thống, nờn việc theo dừi cỏc repone đụi khi là khụng cần thiết.Trong trường hợp bạn cần theo dừi dữ liệu phản hồi từ server, đơn giản là thiết lập thành giá trị thành On.
Trong dữ liệu mà phía server trả về phía client thường bao gồm nhiều thành phần và kiểu khác nhau như: html, css, js, jpg, xml … Trong hầu hết các trường hợp, thì các dữ liệu tĩnh (javascript, css …) không tạo ra nguy cơ bảo mật nào cho hệ thống, do vậy trong ModSecurity ta cần chỉ định rừ kiểu dữ liệu cần theo dừi trong phần SecResponseBodyMimeType. Khuyến cỏo: việc sử dụng chức năng theo dừi tập tin upload cú thể là nguyờn nhõn của việc làm tăng dung lượng lưu trữ do có nhiều tập tin trùng lặp nội dung, đồng thời việc này sẽ làm giảm hiệu suất của ModSecurity. Audit log có 3 mức độ khác nhau để chỉ định cách thức hoạt động trong ModSecurity: SecAuditEngineare On (ghi log tất cả phiên làm việc), Off (tắt audit log) và RelevantOnly (chỉ ghi log dựa vào mẫu mà người dùng chỉ định).
Rule trên hoạt động trong trường hợp khi một người dùng cố truy cập vào URI có chứa mẫu dangerous, thì Modsecurity sẽ trả về mã lỗi 406. • Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy hình ứng dụng webserver. • Error Detection and Hiding: gởi các mã thông báo lỗi giả về phía người dùng.
#START OWASP MODSECURITY CORE RULE SET Include /opt/modsecurity/etc/modsecurity_crs_10_setup.conf Include /opt/modsecurity/etc/crs/activated_rules/*.conf. Ta thực hiện kiểm tra tấn công SQL injection với URI sau trong trường hợp trước và sau khi triển khai OWASP CRS: http://www.modsec.com/?p=1%20order%20by%201,2,4.
Liên kết các rule sẽ giảm thiểu các tình huống cảnh báo không chính xác, giúp bạn đơn giản hóa việc viết rule trong trường hợp cần kiểm tra các điều kiện mang tính chất tuần tự. Trong ví dụ bên dưới, ModSecurity sẽ luôn thực hiện kiểm tra SecRule đầu tiên (kiểm tra tham số p), nếu xảy ra trường hợp có dữ liệu trùng khớp thì rule tiếp theo (kiểm tra tham số q) sẽ được kiểm tra. ModSecurity định nghĩa một ngữ cảnh được gọi là default action list (tạm dịch: danh sách các hành vi mặc định), nhằm thực hiện chèn các giá trị này vào những rule không được chỉ định action.
Giả sử, sau khi thực hiện cấu hình trong tập tin main.conf của ModSecurity, giá trị của SecDefaultAction là phase:2,log,auditlog,pass. Hành vi mà bạn thiết lập trong chỉ thị SecRule sẽ được thực hiện khi có mẫu trùng khớp với các biểu thức, nhưng bạn cũng có thể sử dụng chỉ thị SecAction để triển khai các hành vi. Chỉ thị SecAction cho phép chứa duy nhất một tham số (parameter), tham số này được dùng để liên kết với thành phần thứ ba trong chỉ thị SecRule.
Trong các phương pháp khai thác lỗ hổng ứng dụng web, hacker thường sử dụng các kỹ thuật biến đổi dữ liệu (obfuscation) để vượt qua cơ chế kiểm tra. Để chống lại phương pháp biến đổi, ModSecurity hỗ trợ chuyển đổi dữ liệu đầu vào trước khi thực hiện kiểm tra các tấn công. • Tương tự Base64, với trường hợp hacker chuyển đổi kiểu dữ liệu thành dạng Hex thì t:hexEncode nên được sử dụng để chuyển đổi sang dạng Plaintext.
Các chỉ thị sử dụng trong ModSecurity được liên kết duy nhất với một action (hoặc chỉ thị SecAction) để xử lý kết quả đã phân tích trước đó. Trong trường hợp này, bạn có thể thực hiện việc kiểm tra điều kiện của một rule và nên bỏ qua các bước tiếp theo nếu điều kiện đầu vào không thỏa tiêu chí. Sử dụng dấu ngoặc đơn () trong trường hợp dùng các biểu thức so sánh, việc này giúp ModSecurity xác định vị trí dữ liệu cần thu thập.
Tuy nhiên, metadata sẽ hỗ trợ bạn dễ dàng quản lý các cảnh báo trong quá trình phân tích log, giúp xác định nhanh chóng nguyên nhân và cách phòng tránh các khai thác vào web server.
Các chỉ thị SecEncryption tiếp theo nhằm thông báo cho ModSecurity tạo ra chuỗi giá trị băm (hash value) ngẫu nhiên dựa trên hash salt value và thành tố href trong phần thân HTML (xác định dựa trên mẫu đã được định nghĩa regular expression). Đối với những ứng dụng web thường dùng cookie để xác thực (authentication), phân quyền (authorization) thì việc đoán trước giá trị cookie sẽ cho phép hacker chiếm quyền phiên làm việc của một người dùng khác đã đăng nhập. Sau khi đã định danh được session_cookie do ứng dụng web tạo ra, ModSecurity sẽ tạo ra thêm một cookie mới gởi đến người dùng, đồng thời cookie này cũng được lưu trữ tại server để bảo đảm không có trường hợp hacker sử dụng cookie giả để login vào hệ thống.
Giả sử trường hợp hacker đưa vào một cookie không có thật, thì rule này sẽ thực hiện việc cảnh báo cho quản trị hệ thống về nguy cơ khai thác session-guesting. Việc này dẫn đến kết quả tại phía người dùng sẽ nhận 2 phần dữ liệu khác nhau trong cùng 1 trang HTML, là tiền đề cho các khai thác Cross-user defacement, Cache Poisioning, XSS, Page Hijacking. Nếu tại phía người dùng, hacker cố tình chèn ký tự Carriage Return (CR) hoặc Linefeed (LF) vào các tham số trong URL, thì dẫn đến kết quả gói tin tại phía người dùng bị tái cấu trúc theo mục đích của hacker.
Trong bảng dưới đây mô tả dạng tấn công DOM XSS bằng cách chèn đoạn HTML vào phía người dùng cuối, tuy nhiên việc tạo một gói tin chèn vào phía người dùng là khá phức tạp. Hầu hết các nguyên nhân gây lỗi là do phía mã nguồn web cho phép đọc dữ liệu từ một tập tin khác, bằng cách thay đổi giá trị đường dẫn trong chức năng đọc tập tin ta có thể vượt quyền truy cập sang các thư mục chứa dữ liệu khác. Một ví dụ điển hình là Wordpress CMS ta có thể đọc nội dung wp-config.php để tìm tài khoản đăng nhập cơ sở dữ liệu (phụ thuộc vào mã nguồn CMS mà website sử dụng).
Đối với một số webserver được cấu hình lọc một số dạng tập tin mở rộng, thì việc chèn thêm ký tự null %00 vào cuối URL sẽ cho phép ta vượt qua cơ chế kiểm tra của webserver. Việc rò rỉ thông tin người dùng như là số thẻ tín dụng (credit card number) là khá nghiêm trọng đối với các ứng dụng thanh toán điện tử, cũng như các giải pháp ngân hàng. Thông thường, việc lộ thông tin thường là kết quả của các cuộc tấn công SQL injection có mục đích vào các trang thương mại điện tử, nhằm ăn cắp thông tin định danh thanh toán của người dùng.
Sau khi câu truy vấn SQL được thực thi tại phía server, thì giá trị trả về người dùng vẫn chứa thông tin của thẻ tín dụng (bao gồm: tên chủ thẻ,loại thẻ, số thẻ, thời gian sử dụng…). • OWASP ModSecurity Core Rule Set (CRS). Trong phần minh họa khai thác bruteforce, tôi sử dụng module Intruder trong phần mềm Burp Suite. Module này cho phép người dùng tùy biến dữ liệu gói tin HTTP và sau đó thực hiện gởi nội dung đến server. Hình 12: Giao diện Burp Suite và nội dung đăng nhập Wordpress CMS. Trong phần đăng nhập như hình trên, tôi chỉ định tham số pwd sẽ là nơi thực hiện chèn các giá trị password trong quá trình bruteforce. Hình 13: Danh sách các password phổ biến. Hình 14: Trang web thông báo password không chính xác. Do trang quản trị CMS không giới hạn số lần đăng nhập, nên danh sách password gồm 3424 chuỗi sẽ lần lượt thay thế vào biến pwd. Trong trường hợp người dùng sử dụng mật khẩu yếu, thì việc tài khoản người dùng bị bẻ gãy xác thực là có thể. Tập tin đầu tiên tôi cần cấu hình là modsecurity_crs_10_setup.conf, thực hiện xóa comment trong rule 900014:. # If you are using the Brute Force Protection rule set, then uncomment the following. # lines and set the following variables:. login pages) - set to your login page. Nếu cựng thời điểm có nhiền hơn hai kết nối đăng nhập thì ModSecurity sẽ thực hiện hành động chặn kết nối tạm thời trong 5 phút, đồng thời các cảnh báo sẽ được tạo ra trong log quản trị.