Đề tài SQL Injection – Tấn công và cách phòng tránh

tên khó đoán để đặt cho tên bảng, tên cột chứa các thông tin nhạy cảm như password, credit card,… Mặc dù phương pháp này không trực tiếp ngăn chặn kẻ tấn công truy cập vào dữ liệu, nhưng nó gây khó khăn cho việc tìm mục tiêu của kẻ tấn công. e. Thiết lập các đối tượng giả làm mồi nhử. Chiến thuật này được đưa ra nhằm cảnh báo cho quản trị viên nguy cơ một cuộc tấn công khi một ai đó cố tình tìm cách khai thác những dữ liệu nhạy cảm như password. Phương pháp này nên phối hợp với việc đặt tên các đối tượng khó đoán ở bên trên. Để thực hiện phương pháp này, ta sinh các bảng chứa các cột có tính nhạy cảm mà dễ đoán, ví dụ như password, credit_no, nhưng dữ liệu trong các bảng này là dữ liệu giả, và mỗi khi các thông tin này được truy cập, sẽ có một thông báo gửi về cho quản trị viên. Trên Oracle database có thể triển khai một bảng kiểu virtual private database (VPD). Tham khảo tại: -security/virtual-private-database/index.html f. Tham khảo và cập nhật các khuyến nghị bảo mật khác Ngoài việc cập nhật thường xuyên các báo cáo bảo mật về database, đội ngũ phát triển ứng dụng cũng có thể sử dụng các tài nguyên được cung cấp thường xuyên bao gồm các công cụ, các hướng dẫn, báo cáo,… cho việc phát triển ứng dụng một cách an toàn. Một số nguồn được sử dụng phổ biến như sau: ™ Dự án nguồn mở về an ninh ứng dụng Web (Open Web Application Security Project – OWASP – www.owasp.org): đây là một cộng đồng mở được sáng lập nhằm đào tạo các kỹ năng an ninh ứng dụng Web. Một trong số các dự án của OWASP đã từng được đề cập và minh họa trong luận văn này đó là WebGoat và công cụ Proxy server tên là WebScarab. Một trong số các dự án đáng chú ý của OWASP là Enterprise Security API (ESAPI), cung cấp một tập hợp các API cho việc triển khai các giải pháp bảo mật, ví dụ như xử lý input, … Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 65 ™ Các hướng dẫn phòng chống SQL Injection của Oracle ( ™ SQLSecurity.com (www.sqlsecurity.com): trang này tập trung phục vụ các vấn đề bảo mật của SQL Server, nó chứa các thông tin, tài nguyên hữu ích cho việc phòng chống SQL Injection cũng như các mối nguy SQL Server khác ™ Red-Database-Security: security.com ™ Milw0rm ( : một địa chỉ lớn cập nhật các lỗ hổng và các phương thức khai thác thông tin. Chúng ta có thể tìm trên địa chỉ này những cảnh báo lỗ hổng, video, bài viết, shellcode khai thác điểm yếu được cập nhật. 3.2. Các biện pháp bảo vệ từ mức nền tảng hệ thống Các biện pháp phòng chống từ mức nền tảng hệ thống (platform-level) là những biện pháp cải tiến trong thời gian hoạt động (runtime) hoặc các thay đổi trong cấu hình sao cho có thể nâng cao mức độ an ninh tổng thể của ứng dụng. Một điều luôn cần ghi nhớ, đó là các giải pháp mức nền tảng hệ thống không thể thay thế cho việc xây dựng mã nguồn ứng dụng an toàn, chúng chỉ có tác dụng hỗ trợ. Một database cấu hình tốt không ngăn chặn được SQL Injection nhưng sẽ khiến chúng gặp khó khăn khi lợi dụng điểm yếu ứng dụng để khai thác database, một bộ lọc an ninh có thể được sử dụng tạm thời như một bản vá ảo (virtual patch) từ khi phát hiện lỗ hổng đến khi đội phát triển ứng dụng khắc phục được lỗ hổng đó. Các bộ lọc có thể được xây dựng nhanh chóng hơn và có thể phòng tránh được những lỗ hổng trong giai đoạn zero-day của cuộc tấn công. Và có thể khẳng định rằng, an ninh mức nền tảng là một thành phần quan trọng trong chiến lược an ninh tổng thể của ứng dụng. 3.2.1. Các biện pháp bảo vệ tức thời Những biện pháp bảo vệ tức thời là những biện pháp có thể áp dụng mà không cần phải thực hiện biên dịch lại mã nguồn của ứng dụng. Các biện pháp bảo vệ trong thời gian hoạt động là các công cụ hữu ích nhằm phòng tránh việc lợi dụng các điểm yếu SQL Injection đã được xác định. Việc thực hiện sửa lỗi trong mã nguồn ứng dụng luôn là một giải Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 66 pháp triệt để nhưng không phải luôn thực hiện được với khả năng và chi phí có thể. Ngoài ra, với các ứng dụng thương mại, hầu hết chúng được phát hành với bản hoàn chỉnh đã biên dịch chứ không phải ở dạng mã nguồn. Và ngay cả khi có mã nguồn thì việc thực hiện chỉnh sửa nó hầu hết đều vi phạm các điều khoản sử dụng và các chính sách bảo hành, hỗ trợ của nhà phân phối. Và do đó, việc sử dụng các biện pháp bảo vệ trong thời gian hoạt động có thể là giải pháp dạng bản-vá-ảo (virtual patch) tạm thời trước khi việc sửa lỗi trong mã nguồn ứng dụng hoàn chỉnh. Ngay cả khi thời gian, tài nguyên cần thiết cho phép việc vá lỗi trong mã nguồn, các biện pháp bảo vệ trong thời gian chạy vẫn là một lớp an ninh có giá trị cho việc phát hiện hoặc ngăn chặn những điểm yếu SQL Injection chưa biết tới. Điều này sẽ dễ nhận thấy khi mà ứng dụng chưa từng trải qua các đánh giá, thử nghiệm bảo mật, hoặc chưa từng bị các cuộc tấn công SQL Injection – những điều mà rất phổ biến trong hoạt động phát triển ứng dụng Web ở nước ta hiện nay. Rõ ràng, đây là những tiền đề cho việc khai thác các lỗi zero-day cũng như các lỗi SQL khác phát tán từ Internet. Lúc này, các phương pháp của chúng ta không chỉ mang tính đối phó bị động (reactive) mà còn cung cấp các biện pháp đối phó chủ động (proactive) cho ứng dụng. a. Các ứng dụng tường lửa Web Ứng dụng tường lửa Web (Web Application Firewall - WAF) là một ứng dụng được bố trí đóng vai trò trung gian giữa client và web server, làm nhiệm vụ điều phối các thông tin luân chuyển, cân bằng tải, … một ứng dụng WAF sẽ được bố trí như sau: Hình 3.1 – vị trí của tường lửa Web trong luồng thông tin Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 67 ™ Ưu điểm: ™ Đòi hỏi ít thay đổi tới web server và ứng dụng web ™ Là một tiêu chuẩn đối với các hệ thống thanh toán điện tử (tiêu chuẩn PCI DSS v1.1 ), tham khảo tại PCI Data Security Standard . ™ Cập nhật nhanh, đơn giản ™ Hỗ trợ phòng tránh nhiều loại hình tấn công ™ Nhược điểm: ™ Có thể gia tăng độ phức tạp của hệ thống hiện tại, nhất là khi triển khai kèm proxy ™ Chi phí đào tạo trong quá trình kiểm thử và khi nâng cấp phiên bản mới ™ Gia tăng độ phức tạp của các hoạt động gỡ lỗi, do WAF cũng trả về các lỗi, và WAF chịu trách nhiệm xử lý các tình huống của toàn bộ hệ thống. ™ Tính kinh tế có thể không đảm bảo như nhà quản lý mong muốn. ™ Một số sản phẩm tiêu biểu ™ Miễn phí: ModSecurity, AppArmor, UFW (uncomplicated firewall), … ™ Có phí: Barracuda, Cisco ACE, Citrix NetScale, … Trong phần phụ lục chúng ta sẽ đề cập khái quát về việc sử dụng ModProxy để phòng chống một số dạng tấn công SQL Injection b. Các bộ lọc ngăn chặn Hầu hết các ứng dụng tường lửa web (WAF) đều cài đặt các mẫu lọc ngăn chặn trong cấu trúc của mình. Các bộ lọc này là một chuỗi các module độc lập có thể được gắn kết với nhau để thực hiện thao tác xử lý trước và sau các xử lý chính bên trong ứng dụng (Web page, URL, script). Các bộ lọc đều không có sự ràng buộc rõ rệt nào với nhau, do đó nó cho phép triển khai thêm các mẫu lọc mới mà không hề ảnh hưởng tới những cái sẵn có. Chúng ta sẽ đề cập tới hai cách triển khai các bộ lọc ngăn chặn phổ biến nhất, đó là dưới dạng các plug-in cho Web server và dưới dạng các module cho nền tảng phát triển ứng dụng Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 68 ™ Bộ lọc dạng Plug-in cho Web server Ở dạng này, các bộ lọc được tích hợp vào Web server dưới dạng plug-in/module, đảm nhiệm việc mở rộng khả năng của Web server sang các tác vụ xử lý. Thông thường các request và response được xử lý ở Web server phải trải qua vài pha xử lý, các plug-in lọc có thể đăng kí chạy ở những pha này, thực hiện xử lý trước khi các request tới được ứng dụng Web hoặc ngay sau khi ứng dụng Web trả về các response. Những xử lý này độc lập và không ảnh hưởng tới các module khác của Web server hay không làm thay đổi logic nghiệp vụ của nó. Một ưu điểm dễ thấy khi triển khai dạng module của Web server đó là các bộ lọc này sẽ không phụ thuộc vào nền tảng của ứng dụng Web hoặc ngôn ngữ lập trình, ví dụ các bộ lọc ISAPI cho Microsoft IIS có thể xử lý và theo dõi các request trên cả ASP và ASP.NET. Do các bộ lọc tham gia xử lý tất cả các request nên vấn đề hiệu năng được đặc biệt coi trọng, các plugin đều được viết bằng C/C++ để có thể chạy nhanh hơn. Tuy nhiên khi dùng các ngôn ngữ này sẽ dễ nảy sinh các điểm yếu về tràn bộ đệm hay về định dạng xâu ký tự. ™ Dạng module hỗ trợ cho nền tảng phát triển ứng dụng Dạng module lọc này cho phép chúng ta cài đặt chúng bên trong mã nguồn ứng dụng web hoặc framework. Dạng module này khá tương đồng với dạng plug-in cho Web server ở chỗ các đoạn code ở dạng module, có thể được cài đặt kèm theo từng pha xử lý request từ client. Trong ASP.NET chúng ta có interface tên là Web.IhttpModule và trong Java chúng ta có javax.servlet.Filter để cài đặt các mẫu lọc. Các module này có thể được cài đặt độc lập, không làm thay đổi hoạt động của ứng dụng Web. Ngoài ra, chúng cũng có thể được phát triển độc lập thành các thư viện .dll và jar và có thể được khởi chạy ngay. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 69 3.2.2. Các biện pháp bảo vệ database Các biện pháp bảo vệ chính database nhằm đề phòng những trường hợp xấu, khi kẻ tấn công đã khai thác được điểm yếu, và từ đó có thể điều khiển các hoạt động của database nhằm ăn cắp dữ liệu hoặc làm bàn đạp thâm nhập vào hệ thống bên trong, đằng sau database. a. Giới hạn phạm vi ảnh hưởng của ứng dụng Các biện pháp này được chuẩn bị, đề phòng cho tình huống xấu nhất khi kẻ tấn công có thể thâm nhập được vào database: ™ Cấp quyền ưu tiên tối thiểu cho tài khoản đăng nhập vào database ™ Hủy bỏ các quyền PUBLIC: các database thường cung cấp một số chế độ mặc định cho tất cả các đăng nhập, các chế độ này có một tập mặc định các quyền, bao gồm cả việc truy cập tới một số đối tượng thuộc hệ thống. Các chế độ công khai này đôi khi cung cấp những quyền truy cập tới những stored procedure có sẵn, một số các gói, hoặc các hàm có thể sử dụng cho mục đích quản trị. Vì vậy cần hủy quyền dạng này tới mức tối đa có thể. ™ Sử dụng các Stored procedure: trường hợp này, các stored procedure có vai trò đóng gói các quyền ứng dụng cần vừa đủ để thực hiện công việc của mình. ™ Sử dụng các thuật toán mã hóa mạnh để mã hóa và lưu trữ những dữ liệu nhạy cảm. b. Giới hạn phạm vi ảnh hưởng của database Các biện pháp ở mức này được chuẩn bị, đề phòng cho tình huống kẻ tấn công chiếm được quyền điều khiển database: - Khóa các quyền truy cập tới các đối tượng có đặc quyền, ví dụ những tiện ích quản trị, tiện ích thực thi gián tiếp các lệnh phía hệ điều hành, hoặc các tiện ích sinh các kết nối tới các đối tượng, database khác. - Hạn chế các truy vấn đặc biệt (ad hoc query): câu lệnh OPENROWSET trong SQL Server là một ví dụ. Việc sử dụng câu lệnh này có thể giúp kẻ tấn công có thể cướp quyền truy vấn, và thực hiện các kết nối tới các database khác dưới chế độ xác thực lỏng lẻo hơn. - Luôn cập nhật các bản vá mới nhất của ứng dụng quản trị database (DBMS). Đây là một nguyên tắc căn bản mà chúng ta cần tuân thủ, bởi các bản vá này có thể không cập nhật nhanh nhất nhưng nó có tính đảm bảo cho các điểm yếu đã được phát hiện. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 70 3.3. Đề xuất một số giải pháp Thực tế cho thấy không một hệ thống ứng dụng Web nào được coi là an ninh tuyệt đối. Các giải pháp an ninh hệ thống chỉ có thể hướng tới việc bảo vệ hệ thống một cách tối đa, và giảm thiểu các nguy cơ tấn công xuống mức tối thiểu. Một mô hình an ninh nhiều mức là một sự lựa chọn sáng suốt cho vấn đề này. Các biện pháp an ninh chúng ta đã đề cập tới bao gồm các biện pháp quản lý luồng thông tin trao đổi giữa ứng dụng và database server như: lọc request từ client thông qua tường lửa Web, chuẩn hóa các tham số lấy được từ request, xây dựng các truy vấn tham số hóa, lọc tiếp lần cuối các http response tại tường lửa Web. Ngoài ra còn cần áp dụng các biện pháp an ninh mức nền tảng hệ thống. Chúng ta có thể hệ thống lại các giải pháp an ninh ứng dụng đã đề cập theo một mô hình sau. Hình 3.2 – mô hình đề xuất Trong mô hình trên, quá trình xử lý request từ phía người dùng trải qua 6 giai đoạn: Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 71 - Nhận request từ client (các tham số đầu vào do người dùng toàn quyền điều khiển). Giai đoạn này chúng ta không can thiệp được. - Xử lý request ở tường lửa Web: trong giai đoạn này các luật lọc ở tường lửa Web sẽ giúp chặn lại các request có URL, tham số tiềm ẩn nguy cơ tấn công. - Chuẩn hóa dữ liệu thu được từ request trong mã nguồn ứng dụng. Giai đoạn này thực hiện kiểm tra, chuẩn hóa các dữ liệu từ phía người dùng, một số thao tác cần tiến hành như kiểm tra kiểu dữ liệu, kiểm tra độ dài dữ liệu (đề phòng Buffer overflow), … - Sinh các truy vấn theo mô hình tham số hóa (parameterized query hay prepared query). Các truy vấn này sẽ được DBMS tối ưu, khi thực thi sẽ nhận các tham số đã chuẩn hóa ở giai đoạn trước vào để có câu truy vấn hoàn chỉnh - Xử lý kết quả từ database trả về, sinh các kết quả để HTML gửi về client thông qua các thông điệp phản hồi (HTTP response) - Thông điệp phản hồi (HTTP response) sẽ được qua tường lửa Web lọc các thông tin trong đó nhằm loại bỏ các request có rò rỉ dữ liệu nhạy cảm. - Các thông điệp phản hồi sau khi được kiểm tra sẽ được trả về cho client. Giai đoạn này ứng dụng không kiểm soát được. Mô hình trên nên được áp dụng cho tất cả các ứng dụng Web nhằm đảm bảo an ninh tối đa trước các cuộc tấn công SQL Injection. Trong mô hình trên, chúng ta đã thực hiện được việc kiểm soát dữ liệu đầu vào của người dùng thông qua các bước xử lý khác nhau. Việc xử lý request từ mức tường lửa sẽ giúp giảm thiểu được gánh nặng xử lý cho ứng dụng bên trong, đồng thời tiết kiệm được băng thông cho hệ thống. Các tham số chuẩn hóa sẽ giúp các truy vấn SQL (trực tiếp hoặc thông qua các Stored Procedure) được thực thi an toàn hơn. Và cuối cùng, các thông tin có thể bị rò rỉ trong thông điệp phản hồi sẽ được kiểm tra lần nữa trước khi chuyển về cho client. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 72 Phụ lục: Cấu hình ModSecurity phòng chống SQL Injection. 1. Cài đặt ModSecurity là một ứng dụng tường lửa Web xây dựng dưới dạng module cho ứng dụng Web server Apache. Mọi thông tin chi tiết về ModSecurity được đăng tại trang chủ của sản phẩm ( Chúng ta sẽ đề cập đến việc cài đặt ứng dụng này trên hệ điều hành Linux, cụ thể là trên bản phân phối Debian/Ubuntu. - Gói mã nguồn được tải về tại địa chỉ: - chúng ta thực hiện cài đặt các gói, thư viện liên quan: #apt-get install libxml2-dev liblua5.1-0 lua5.1 apache2-dev build-essential - giải nén mã nguồn: tar xzf modsecurity-apache_2.5.7.tar.gz - chuyển vào trong thư mục dành cho apache2: cd modsecurity-apache_2.5.7/apache2 - biên dịch mã nguồn # configure && make && make install sau giai đoạn biên dịch, thư viện chia sẻ của module phải nằm ở thư mục: /usr/lib/apache2/modules/ và có tên mod_security2.so - tạo file chỉ thị để Apache nạp module ModSecurity vi /etc/apache2/mods-available/mod-security2.load Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 73 thêm các dòng sau và lưu lại: LoadFile /usr/lib/libxml2.so LoadFile /usr/lib/liblua5.1.so.0 LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so - kích hoạt module để chạy cùng apache (chỉ thị unique_id cần có đối với mod-security, nó được dùng làm chuẩn kèm theo apache) a2enmod mod-security2 a2enmod unique_id - tạo file cấu hình cho ModSecurity và khai báo khu vực chứa các luật lọc: vi /etc/apache2/conf.d/mod-security2.conf thêm dòng sau vào file và lưu lại: Include /etc/modsecurity2/*.conf - tạo các thư mục riêng cho ModSecurity và các file log: mkdir /etc/modsecurity2 mkdir /etc/modsecurity2/logs touch /etc/modsecurity2/logs/modsec_audit.log touch /etc/modsecurity2/logs/modsec_debug.log - cài đặt các luật cơ bản cho ModSecurity các luật cơ bản cho ModSecurity được cung cấp sẵn tại: - sau khi tải về, giải nén và chép vào thư mục /etc/modsecurity2: cp /tmp/modsecurity-apache_2.5.7/rules/*.conf /etc/modsecurity2 - cập nhật lại vị trí lưu các log trong file cấu hình: Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 74 vi /etc/modsecurity2/modsecurity_crs_10_config.conf tìm dòng SecDebugLog logs/modsec_debug.log thay bằng SecDebugLog /etc/modsecurity2/logs/modsec_debug.log và tìm dòng SecAuditLog logs/modsec_audit.log thay bằng SecAuditLog /etc/modsecurity2/logs/modsec_audit.log Sau khi sửa xong lưu lại - kiểm tra xem các cấu hình của apache đã đúng chưa: apache2ctl configtest câu lệnh này cần phải trả về OK thì ta mới cấu hình thành công - khởi động lại apache: /etc/init.d/apache2 restart - kiểm tra xem ModSecurity đã chạy chưa: cat /var/log/apache2/error.log | grep ModSecurity cần tìm thấy dòng có nội dung: … ModSecurity for Apache/2.5.4 ( configured. 2. Cấu hình Công việc cài đặt thực hiện xong, việc chính của chúng ta phải làm đó là thiết lập và bảo trì tập cấu hình các luật (rules), các luật này mô tả các mẫu dạng blacklist/whitelist. Điểm mạnh của ModSecurity đó là ngôn ngữ được sử dụng để mô tả các luật của nó, ngôn ngữ này được tổ hợp giữa các chỉ dẫn cấu hình và một dạng ngôn ngữ lập trình đơn giản áp dụng cho các request và response HTTP. Các chỉ thị được đưa ra thường là cho phép request, ghi chép lại (logging) request đó, hoặc chặn (blocking) nó. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 75 Các cấu hình được thực hiện trên các phiên bản ModSecurity 1.x và 2.x có vài điểm khác biệt, nhiều điểm khác biệt này không thể tương thích lẫn nhau, do đó khi triển khai nâng cấp hoặc sửa đổi, bổ sung các luật, người quản trị cần xem xét kỹ phiên bản để có điều chỉnh phù hợp. Thông tin về các thay đổi giữa hai phiên bản có thể tham khảo tại địa chỉ . 2.1. Cấu hình tổng quát a. Một số thông tin cơ bản Việc khai báo và cấu hình module ModSecurity trong file cấu hình của Apache có thể theo hai cách: ™ Cách thứ nhất: mô tả cấu hình trong chính bản thân file cấu hình của apache (là file httpd.conf với apache v1.x và là apache2.conf với apache v2.x). Cách này có thể khiến file cấu hình của apache phức tạp thêm và khó quản lý hơn. ™ Cách thứ hai: xây dựng một file độc lập (thường được đặt tên là modsecurity2.conf), và định nghĩa file này là file cấu hình của module ModSecurity trong file cấu hình của apache, ví dụ trong khai báo module trong apache2.conf: include /etc/apache2/conf.d/modsecurity2.conf Sau khi khai báo module, và file cấu hình, chúng ta thực hiện tạo file cấu hình của ModSecurity. Như khai báo ở trên, file cần tạo là modsecurity2.conf đặt trong thư mục conf.d là thư mục con của thư mục apache2. Để bắt đầu sử dụng module, cần khai báo thông qua chỉ thị sau: # turn on rule engine and set default action SecRuleEngine On Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 76 SecDefaultAction "phase:2,deny,log,status:403" Cần lưu ý ở đây là định danh của module được chỉ ra trong chỉ thị IfModule cần đúng với định danh được khai báo trong lệnh LoadModule trong file cấu hình của Apache (apache2.conf), nếu không Apache sẽ bỏ qua tất cả nội dung nằm trong cặp thẻ IfModule. - SecRuleEngine On : kích hoạt engine xử lý các luật lọc. - SecDefaultAction: chỉ ra những gì sẽ xảy ra khi một luật được khớp (rule match). - Phase:2 . ModSecurity xử lý một request theo 5 pha (phase), tương ứng với các pha xử lý của Apache, ModSecurity 2.x trở đi có thể áp các luật cho cả 5 pha này. Năm pha xử lý này như sau: Số thứ tự, tên pha Thời điểm xảy ra 1. REQUEST_HEADERS Ngay sau khi Apache đọc xong header của request HTTP 2. REQUEST_BODY Sau khi nội dung request được đọc. Hầu hết các luật được đưa ra để xử lý trong pha này 3. RESPONSE_HEADERS Sau khi header của response được gửi lại cho client 4. RESPONSE_BODY Trước khi gửi nội dung response cho client, nội dung này sẽ được rà soát lại để tránh những thiếu sót về rò rỉ dữ liệu 5. LOGGING Sau khi quá trình ghi log bắt đầu. Tại thời điểm này, request sẽ không thể bị chặn lại. Như nội dung bảng trên đã trình bày, pha hữu ích nhất để quản lý các request HTTP là pha thứ hai. Khi chỉ định phase:2 cho hành động mặc định, tất cả các luật tiếp theo sẽ luôn xử lý ở pha 2 trừ khi các pha khác được chỉ định trong luật đó. Để mô tả một hành động tùy ý, bỏ qua hành động mặc định, sử dụng cấu trúc ví dụ như sau: SecRule REQUEST_HEADERS:User-Agent “WebVulnScan” “phase:1” Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 77 Với mô tả này, luật sẽ xử lý ở pha 1, sau khi nhận được request header. b. Hoàn tất cấu hình cơ bản Để hoàn tất cấu hình cơ bản cho ModSecurity, ta cần bổ sung thêm một số chỉ thị hữu ích, cần thiết khác cho nó. Xét cấu hình được khuyến cáo sau: # turn on rule engine and set default action SecRuleEngine On SecDefaultAction "phase:2,deny,log,status:403" # Configure request body access and limits SecRequestBodyAccess On # Debug log setting SecDebugLog logs/modsec_debug.log SecDebugLogLevel 0 Chỉ thị SecRequestBodyAcces On sẽ kích hoạt việc xử lý thân nội dung HTTP request. Điều này cho phép chúng ta kiểm tra những nội dung gửi lên thông qua request POST. Khi chỉ thị này được kích hoạt, ModSecurity sẽ lưu tạm lại thân request trong bộ nhớ, xử lý nó trước khi gửi lại cho Apache xử lý tiếp. Chỉ thị SecDebugLog, chúng ta cần cung cấp đường dẫn tới file log phục vụ debug, trong trường hợp này là thư mục logs nằm bên trong thư mục gốc của Apache. Ngoài ra chỉ thị SecDebugLogLevel 0 nói lên rằng không một dữ liệu nào về debug được lưu lại. Điều này có ích khi mô tả trong file cấu hình, bởi các mức độ debug log sẽ có thể thay đổi trong các luật khác. Một điều rất quan trọng mỗi khi thực hiện chỉnh sửa lên luật hoặc các luật, đó là sau mỗi thay đổi, nhất thiết phải khởi động lại Apache để nạp lại các luật. Nếu điều này không thực hiện đúng, sẽ gây ra những xung đột do mất đi sự nhất quán giữa cấu hình, luật, các log, và tai hại thường khó lường trên những mô hình lớn. c. Thực hiện minh họa với một luật đơn giản Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 78 Sau khi trình bày tóm lược về một số thao tác cài đặt và cấu hình cơ bản, chúng ta sẽ bắt đầu thử xây dựng một luật cơ bản và thử nghiệm hoạt động của chúng. Trong file cấu hình ModSecurity, thêm luật sau: # block all requests that containts “restricted” in URI SecRule REQUEST_URI “restricted” Trong thư mục DocumentRoot của Apache2 (trường hợp này là trong thư mục /var/www/), tạo một file restricted.php có nội dung bất kỳ, để kiểm tra hoạt động của bộ lọc, ta thử truy cập vào file restricted.php trên: Kết quả trên chứng tỏ luật khai báo phía trên đã hoạt động tốt. Tiếp theo chúng ta sẽ thực hiện đề cập các luật chi tiết hơn trong phần 1.2.2. d. Ngụy trang Web Server Việc ngụy trang chính bản thân Web server là một việc cần thiết nhằm gây khó khăn cho kẻ tấn công. Việc ngụy trang ở đây có thể thực hiện thông qua ModSecurity, ModSecurity có thể trả về thông tin thay vì là Apache có thể sẽ là Microsoft-IIS/5.0 hoặc một thông tin gì đó gây khó khăn cho kẻ tấn công. Để thực hiện việc này, sử dụng chỉ thị SecServerSignature, trên Apache2 cần cấu hình biến ServerToken từ Prod (mặc định) thành Full để có thể sử dụng được chỉ thị trên. Cú pháp của chỉ thị trên dạng như: SecServerSignature “Microsoft-IIS/5.0” 2.2. Cấu trúc các luật Việc định nghĩa các luật là một công việc rất thường xuyên trong việc bảo trì, nâng cấp hệ thống WAF. Chỉ thị được sử dụng thường xuyên nhất để định nghĩa các luật đó là SecRule. Để tự tạo, quản lý và bảo trì các luật phức tạp thế này không đơn giản. Trước tiên chúng ta sẽ tìm hiểu cấu trúc cú pháp của chỉ thị SecRule. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 79 SecRule Target Operator [Actions] ƒ Target: chỉ định thành phần nào đó của request hoặc response mà ta cần áp đặt luật. Target nhận giá trị là các biến, biến có thể là dạng biến thường và dạng biến tập, chúng ta sẽ đề cập đến sau. ƒ Operator: thành phần này chỉ định các phương thức, phép so sánh dữ liệu được sử dụng khi thực hiện khớp với các biến cụ thể hoặc các biến. Operator mặc định, nếu không được chỉ định, là @rx, tức là rule engine sẽ sử dụng biểu thức chính quy để khớp xâu với biến cụ thể nào đó. ƒ Action: là một danh sách (tùy chọn) các hành động sẽ được áp đặt khi một luật được khớp (rule match). Những hành động này có thể là từ chối request và chỉ định mã lỗi trả về, … Danh sách hành động này không bắt buộc, bởi nếu không được chỉ định, các hành động đã được khai báo mặc định trong chỉ thị SecDefaultAction trong cấu hình cơ bản sẽ được áp đặt lên request. 2.2.1. Biến thường và các biến tập ModSecurity sử dụng hai loại biến, loại thứ nhất là các biến chuẩn (standard variable) chỉ chứa một giá trị đơn ứng với mỗi biến, và loại thứ hai là các biến tập (collection variable) có thể chứa nhiều giá trị ứng với một biến. lấy một ví dụ về biến tập như REQUEST_HEADER, nó chứa tất cả giá trị trường header của một thông điệp HTTP. Để truy cập vào các trường trong biến tập, sử dụng cấu trúc tên_biến:tên_trường, ví dụ luật sau: SecRule REQUEST_HEADER:Referer “victim.com” Hầu hết các biến tập có thể được sử dụng độc lập mà không cần chỉ định trường cụ thể. Khi sử dụng tên biến tập độc lập tương đương với việc truy cập tới mọi trường trong tập đó. Ví dụ, querystring gửi lên trong thông điệp POST như sau: username=cuongpt&password=weakpasswd. Thì thay vì sử dụng luật: SecRule ARGS:username|ARGS:password “select” Ta có thể sử dụng SecRule ARGS “select” deny. Một số biến tập có các trường cố định (vd: GEO có country_name, city,…) nhưng một số lại có các trường không cố định, tùy thuộc vào nội dung client gửi đến. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 80 Trong các biến tập, có thể truy cập tới các trường không tồn tại hoặc trường đó không được gán giá trị mà không phát sinh lỗi. Điều này cần ghi nhớ trong trường hợp debug, có thể bỏ qua khả năng trường giá trị trong biến tập không tồn tại hoặc không được gán giá trị. 2.2.2. Lưu trữ dữ liệu giữa các request. Có ba loại biến tập trong ModSecurity có thể được sử dụng để lưu trữ lâu dài. Thông thường, các biến sẽ hết hiệu lực mỗi khi request hiện thời được xử lý hoàn tất. Tuy nhiên trong một số trường hợp, chúng ta lại cần lưu giữ chúng lại và sử dụng chúng khi thao tác với các request sau này. Ba loại biến tập có thể được sử dụng cho mục đích lưu trữ là IP, SESSION, USER. Biến tập IP được dùng để lưu thông tin về một user thông qua địa chỉ IP. Chúng ta có thể sử dụng nó cho một số mục đích như phát hiện ra user nào request nhiều lần vào một tài nguyên, hoặc số lần request của một user, giả sử để chống DOS. Trước khi sử dụng các biến trên, chúng ta cần khởi tạo chúng cách sử dụng action tên là initcol, ví dụ: SecAction initcol:ip=%{REMOTE_ADDR},nolog,pass Trong đó, REMOTE_ADD là biến lưu địa chỉ IP của client gửi request. Để lưu trữ biến, chúng ta cũng cần cấu hình một thư mục dữ liệu cho ModSecurity thông qua chỉ thị SecDataDir, ví dụ: SecDataDir /var/log/apache2/modsec_data Điều cần lưu ý đó là thư mục được chỉ định trong chỉ thị nêu trên phải cho phép người dùng Apache ghi dữ liệu lên. Sau khi cấu hình thư mục lưu trữ dữ liệu, khởi tạo biến, ta có thể thao tác với giá trị của biến, gán giá trị thông qua action tên là setvar. Trong phần giới thiệu biến tập tiếp theo ta sẽ sử dụng action setvar. 2.2.3. Biến tập giao tác (transaction collection) Biến TX là một dạng biến tập giao tác, các biến này được gán giá trị trong một vòng đời của một request/response. Chúng ta có thể sử dụng TX để tạo các biến của riêng mình nhằm lưu dữ liệu trong vòng một chu kỳ transaction. Xét một số luật sau: SecRule REQUEST_URI “select” “pass,setvar:tx.score=+1” SecRule REQUEST_URI “passwd” “pass,setvar:tx.score=+2” Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 81 SecRule TX:SCORE “@gt 3” deny Bộ luật trên mô tả như sau, thực hiện kiểm tra các URI trong request, nếu phát hiện có chứa “select” thì tăng biến SCORE lên 1, nếu phát hiện thấy có “passwd” thì tăng biến SCORE lên 2, và nếu kiểm tra thấy biến SCORE lớn hơn hoặc bằng 3 thì chặn request đó lại. Cấu trúc action setvar ở trên cho phép tạo và cập nhật một biến. Để hủy một biến, cũng sử dụng action setvar nhưng thêm dấu chấm than phía trước biến, cụ thể: setvar:!tx.score. Biến tập TX có thể chứa các trường định nghĩa sẵn (built-in) như TX:0, TX:1, … cho đến TX:9. Với trường hợp TX:0 đó là giá trị được khớp khi sử dụng toán tử @rx hoặc @pm, các biến TX:1 đến TX:9 chứa các giá trị kiểu biểu thức chính quy thu được khi ước lượng một biểu thức chính quy kèm theo action capture. 2.2.4. Thực hiện thao tác đồng thời nhiều biến Chúng ta có thể thực hiện so khớp một biểu thức chính quy với một vài biến một lúc, ví dụ cùng so khớp cả request header và request argument xem có xuất hiện “select” hay không thì cần dùng dấu | (pipe) để ngăn cách giữa các biến cần thực hiện so khớp, ví dụ: SecRule ARGS|REQUEST_HEADERS “select” deny 2.2.5. Việc sử dụng các dấu nháy Trong cấu trúc một luật, phần chuỗi action và biểu thức chính quy không nhất thiết phải luôn được bao bởi một cặp dấu nháy (như ví dụ ở trên). Nếu chuỗi action và biểu thức chính quy không chứa khoảng trắng (vd: dấu cách) bên trong thì không cần sử dụng dấu nháy để bọc chuỗi. Ngược lại, cần sử dụng dấu nháy kép để bọc một chuỗi có chứa khoảng trắng bên trong. Ví dụ: SecRule REQUEST_URI “waitfor delay” deny Một trường hợp khác xảy ra, đó là dấu nháy xuất hiện với tư cách là thành phần hợp lệ của chuỗi, ví dụ với một thông báo trong log “someone’s try to hack us”, thì cần sử dụng dấu \ (backlash) để escape dấu đó, ví dụ ta có “someone\’s try to hack us”. Ngoài dấu nháy, các ký tự đặc biệt khác thường Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 82 gặp trong xử lý biểu thức chính quy cũng cần được escape, ví dụ dấu chấm, dấu sao, dấu mở ngoặc đơn, … 2.2.6. Xây dựng chuỗi các luật Chuỗi các luật (chained rules) được sử dụng để kết hợp các luật lại sao cho một sự kiện khớp luật phải thỏa mãn điều kiện của một vài điều kiện thay vì chỉ một điều kiện đơn lẻ. Sử dụng action có tên là “chain” có thể cho phép ghép các luật lại thành một chuỗi xử lý. Một request/response khớp với chuỗi luật nếu khớp với tất cả các luật thành viên. Từ khóa chain này có tác dụng tương tự phép thao tác logic AND trong các mệnh đề điều kiện ở các ngôn ngữ lập trình khác. Ví dụ với điều kiện đặt ra như trên, ta có thể xây dựng chuỗi luật sau: SecRule REQUEST_HEADERS:User-Agent “FlashGet” “deny,chain” SecRule TIME_HOUR “@lt 16” Một điều cần chú ý, đó là chỉ có luật đầu tiên trong chuỗi mới có thể chỉ định các action có tính ngắt, ví dụ deny, nếu có luật nào khác luật đầu tiên chỉ định các action này, sẽ có lỗi xẩy ra. Ngoài deny, các metadata action khác như log, msg, id, rev, tag, severity, logdata, cũng chỉ có thể được chỉ định ở luật đầu tiên trong chuỗi. Có thể ghép nhiều luật thành chuỗi chứ không chỉ hai luật như ví dụ. Khi đó chuỗi sẽ có đặc điểm sau: ™ Luật đầu tiên mô tả đầy đủ các hành động cần thiết để xử lý request/response khớp, kèm theo action “chain” ™ Các luật tiếp theo trừ luật cuối cùng, chỉ chứa duy nhất action là “chain” ™ Luật cuối cùng trong chuỗi, không chứa action nào Các chuỗi luật phức tạp hơn chúng ta sẽ xây dựng, đề cập đến trong những nội dung mở rộng sau này. 2.2.7. Biểu thức chính quy Biểu thức chính quy là một yếu tố căn bản được sử dụng để xây dựng nên các luật trong ModSecurity. 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. Ngoài việc xây dựng trực tiếp mẫu so sánh hoàn toàn bằng biểu thức chính quy, có thể tận dụng một số toán tử hỗ trợ để giảm nhẹ công việc, ví dụ: Toán tử Tác dụng Ví dụ Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 83 @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” @containsWord Khớp xâu chứa từ được chỉ định. “Từ” ở đây được 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ố SecRule ARGS “@containsWord from” @endsWith Khớp xâu kết thúc bởi xâu chỉ định SecRule ARGS “@endsWith --” @streq Khớp xâu giống hoàn toàn xâu chỉ định SecRule REMOTE_HOST “@streq victim\.com” @within Khá giống @contains, chỉ khác là một so khớp xảy ra khi biến cần so xuất hiện bên trong xâu được chỉ định SecRule REMOTE_USER “@within cuong,nam,an” (sẽ khớp nếu remote user là cuong, nam hoặc an) Các phép khớp xâu ở trên nhạy cảm kiểu chữ với xâu được chỉ định, cụ thể, kết quả sẽ khác với các xâu chỉ định là Select và seLect. Tuy nhiên, các toán tử thì lại không phân biệt kiểu, tức là @within hay wiThin cũng vẫn hoạt động giống nhau. Ngoài việc so khớp các chuỗi ký tự, chúng ta cũng cần đề cập đến việc sử dụng các toán tử để so sánh các số: 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” Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 84 2.2.8. Một số các thao tác nâng cao với biến tập ™ Đếm số lượng đối tượng trong một biến tập Chúng ta có thể thực hiện đếm số các đối tượng trong một biến tập bằng cách đặt dấu “&” vào trước biến tập đó. Giả sử chúng ta cần chặn các request mà không gửi cookie: SecRule &REQUEST_COOKIE “@eq 0” Ngoài ra có thể sử dụng đặc tính này để chặn một loại hình qua mặt WAF, đó là phương pháp có tên gọi “HTTP parameter pollution” đã được đề cập ở chương . Phương pháp này sẽ tìm cách tách chuỗi giá trị tham số thành nhiều cụm, lúc này sẽ xuất hiện ít nhất hai tham số có cùng tên, ví dụ với URL: có thể lập một luật để cản phương pháp này, ví dụ: SecRule &ARGS:keyword “@ge 2” ™ Lọc các trường trong biến tập sử dụng biểu thức chính quy Thay vì việc phải thao tác với tất cả các trường hoặc chỉ định đích danh một trường, ta có thể sử dụng biểu thức chính quy để thao tác với một số trường có tên tương đồng nhau. Giả sử client submit một form đăng kí tài khoản, trong đó có các trường firstname, lastname, để ngăn ngừa nguy cơ SQL Injection trong đó, ta có thể xây dựng một luật dạng như : SecRule ARGS:/*name/ “select” deny Luật trên sẽ chỉ bị vi phạm nếu một query string nào đó chứa tham số có tên chứa “name” và giá trị chứa “select”, nếu không vi phạm hai điều kiện này thì query string đó hợp lệ (đối với luật trên). Cấu trúc tham chiếu đến trường trong biến tập sử dụng biểu thức chính quy có khác so với thông thường ở cặp dấu sổ chéo / (forward slash). Ta dùng cặp dấu này để thông báo cho engine luật rằng chuỗi bên trong cặp dấu đó là một biểu thức chính quy. Nếu không có cặp dấu sổ chéo ấy thì chỉ những trường nào có tên đúng “*name” mới được tham chiếu. ™ Các hàm chuyển đổi ModSecurity cung cấp một số các hàm chuyển đổi (transformation) có thể sử dụng cho các biến và biến tập. Các quá trình biến đổi dữ liệu được Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 85 thực hiện trên bản sao của dữ liệu cần thao tác, do đó các request/response ban đầu hoàn toàn không bị chỉnh sửa. Để áp dụng một hàm chuyển đổi, chúng ta cần chỉ định tiền tố t: sau đó là tên hàm cần gọi, và đặt cụm này vào trong danh sách action của luật. Giả sử muốn chuyển kiểu của tất cả các tham số trong querystring/POST sang dạng chữ thường trước khi tiến hành khớp với biểu thức chính quy thì có thể xây dựng luật như sau: SecRule REQUEST_URI “<script” “deny,t:lowercase” Luật trên sẽ chặn bất cứ URL nào chứa “<script”, không quan tâm tới xâu ký tự đó viết hoa hay thường thế nào. Có rất nhiều các hàm chuyển đổi được cung cấp sẵn (tham khảo tại: ( apache/2.5.12/modsecurity2-apache-reference.html#transformation- functions). Chúng ta liệt kê một số hàm cơ bản sau: Tên hàm Tác dụng compressWhitespace Chuyển các ký tự tab, xuống dòng, carriage return, form feed thành dấu cách, và chuyển nhiều dấu cách liên tiếp thành một dấu cách htmlEntityDecode Giải mã các thuộc tính HTML đã mã hóa, ví dụ chuyển < thành < length Chuyển một chuỗi thành giá trị độ dài của nó (kiểu số) lowercase Chuyển tất cả ký tự của chuỗi về dạng viết thường md5 Chuyển giá trị đầu vào thành mã băm md5 của nó none Xóa tất cả các hàm chuyển đổi đang thao tác trên luật hiện thời removeNull Xóa các byte null trong chuỗi removeWhitespace Xóa tất cả các khoảng trắng trong chuỗi replaceComments Thay tất cả các comment kiểu C (/* … */) bằng một ký tự dấu cách. Cụm ký tự mở khối comment /* cũng sẽ được thay bằng một dấu cách ngay cả khi thiếu ký tự */ tương ứng. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 86 replaceNulls Thay các byte null bằng một dấu cách urlDecode Giải mã chuỗi có dạng mã hóa URL urlEncode Mã hóa chuỗi dạng URL urlDecodeUni Tương tự urlDecode nhưng thao tác giải mã cả với những ký tự được mã hóa Unicode dạng %uxxx sha1 Thay giá trị đầu vào bằng mã băm sha1 của nó trimLeft Xóa mọi khoảng trắng phía bên phía đầu xâu trimRight Xóa mọi khoảng trắng phía bên phía cuối xâu trim Xóa mọi khoảng trắng phía đầu và cuối xâu 2.2.9. Các toán tử nâng cao Các nội dung trước chúng ta đã đề cập đến các toán tử thao tác dữ liệu như biểu thức chính quy, so sánh chuỗi, so sánh số. Ngoài các toán tử trên còn có một số toán tử khác khá hữu ích trong những trường hợp cụ thể. ™ Khớp các mệnh đề với toán tử @pm và @pmFromFile Chúng ta đã đề cập đến việc sử dụng biểu thức chính quy để khớp một trong các từ khác nhau với việc sử dụng toán tử | (pipe). Ví dụ khớp select hoặc update hoặc insert, ta có thể dùng biểu thức chính quy (select|insert|update). Ngoài ra, ModSecurity cũng cung cấp hai toán tử khớp theo mệnh đề (phrase matching) có thể sử dụng để thay thế cho biểu thức chính quy như trên. Hai toán tử đó là @pm và pmFromFile. Ta có hai luật sau, một sử dụng biểu thức chính quy, một sử dụng toán tử @pm, đều cho kết quả tương đương: SecRule ARGS “select|insert|update” “deny,t:lowercase” SecRule ARGS “@pm select insert update” “deny,t:lowercase” Các request gửi lên nếu chứa tham số chứa xâu “select”, ”insert”, ”update” (không phân biệt kiểu chữ hoa, thường) thì đều bị chặn. Khi chúng ta có một danh sách dài các từ cần khớp, nếu liệt kê tất cả chúng trong khai báo luật thì sẽ rất rối và bất tiện, ví dụ: “insert, xp_enumdsn, infile, openrowset, nvarchar, autonomous_transaction, print, data_type, or, outfile, inner, shutdown, tbcreator” hay thậm chí dài hơn như ở đoạn luật minh họa ban đầu. Để khắc phục điều này, ModSecurity cho Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 87 phép chúng ta khai báo các từ trên trong một file riêng và tham chiếu đến file đó với toán tử @pmFromFile. Để thực hiện việc tham chiếu file trên, ta tạo một file, ví dụ “/etc/modsecurity2/blacklist/keyword.txt”. Trong file trên ta nhập vào các từ cần khớp, mỗi từ một dòng. Khi đó luật sẽ được mô tả như sau: SecRule ARGS “@pmFromFile /etc/modsecurity2/blacklist/keyword.txt” deny Toán tử @pmFromFile sẽ đọc danh sách từ trong file keyword.txt nêu trên và thực hiện khớp tương tự như toán tử @pm. Có một điều khác biệt nhỏ giữa @pm và @pmFromFile, đó là @pmFromFile cũng khớp với một mệnh đề đơn. Tức là nếu ta thêm một cụm như “waitfor delay” vào file keyword.txt thì luật sẽ khớp tham số với cả cụm “waitfor delay” chứ không chỉ khớp với “waitfor”. Ưu điểm của việc sử dụng hai toán tử @pm và @pmFromFile: - Các luật dễ đọc, dễ viết hơn so với biểu thức chính quy - Các toán tử này chạy thuật toán Aho-Corasick với độ phức tạp tuyến tính, nhanh hơn nhiều so với việc sử dụng biểu thức chính quy, nhất là trên một mẫu thử có nhiều chuỗi. 2.2.10. Các hành động – xử lý các sự kiện khớp luật Khi một luật được khớp, chúng ta có một số tùy chọn để xử lý: cho phép, từ chối, hoặc chuyển xử lý sang cho luật tiếp theo, ngoài ra cũng có một số hành động khác có thể áp đặt như chuyển hướng (redirect) tới một địa chỉ khác hoặc tới proxy server. Chúng ta sẽ xem xét tất cả các lựa chọn này. Nhắc lại thứ tự 5 pha xử lý request của ModSecurity: - Pha 1: REQUEST_HEADERS - Pha 2: REQUEST_BODY - Pha 3: RESPONSE_HEADERS - Pha 4: RESPONSE_BODY - Pha 5: LOGGING ™ Cho phép request Hành động allow sẽ có thể Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 88 - Cho phép truy cập ngay lập tức, bỏ qua các pha xử lý còn lại (trừ phá ghi log). Trường hợp này action allow được chỉ định theo cách riêng, với cú pháp sau: SecAction allow - Cho phép truy cập trong phạm vi pha hiện tại, rule engine có thể chuyển ngay sang pha xử lý tiếp theo, tuy nhiên các luật trong pha này hoặc pha sau có thể vô hiệu hóa action allow bằng action deny. Cú pháp xử lý trong trường hợp này: allow:phase - Chỉ cho phép truy cập trong các pha request Nếu sử dụng chỉ định action: allow:request, thì tương đương với việc request sẽ được cho phép truy cập trong hai pha 1 và 2. Rule engine sẽ ngay lập tức chuyển sang pha 3 (response header). Các luật ở pha này và các pha sau có thể vô hiệu hóa action allow bằng action deny. ™ Chặc các request Để chặn một request, ta có thể chỉ cần dùng action deny, khi action này được chỉ định, nó sẽ ngay lập tức dừng tất cả các hoạt động xử lý request hiện tại, từ chối request này và trả về mã lỗi HTTP được định nghĩa ở default action. Ngoài action deny, còn có một action khác tên là block, có thể triển khai thao tác tương tự deny. Tuy nhiên có rất nhiều điểm còn dễ nhầm lẫn trong việc sử dụng block, do đó theo khuyến cáo là vẫn chưa nên triển khai các action block vào các luật trong phiên bản hiện tại của ModSecurity. ™ Không xử lý, nhưng chuyển quyền xử lý cho luật tiếp theo Khi một mẫu request khớp với luật, có dấu hiệu tình nghi, chúng ta muốn thực hiện vài thao tác trên request đó nhưng vẫn chưa muốn chặn nó lại ngay mà muốn xử lý thêm trong các luật sau đó thì chúng ta có thể sử dụng action pass để thực hiện điều này. Ví dụ ta có luật sau: SecRule ARGS|REQUEST_URI “or” “pass,log,logdata:’suspicious input’,t:lowercase” ™ Ngắt kết nối với client Trong một số trường hợp đã phát hiện âm mưu tấn công, nhất là các dạng DOS, chúng ta có thể chủ động sử dụng action drop để đóng kết nối TCP tới client. Khi một sự kiện khớp luật xảy ra kèm một action drop, ModSecurity sẽ gửi một packet TCP fin để ngắt kết nối với client. ™ Chuyển hướng request Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 89 Khi nhận thấy cần chuyển request tới một server khác để xử lý đúng theo thẩm quyền hoặc chức năng, ta có thể sử dụng action redirect để thực hiện điều này. Khi nhận được action này, rule engine sẽ dừng việc xử lý request này lại và trả về mã HTTP 302 (redirect) cho client. Ví dụ một luật như sau: SecRule REQUEST_BASENAME “search.php” “redirect:” Một điều chú ý ở đây, đó là nếu như địa chỉ được chuyển tới không phải là server hiện tại thì luôn phải có http:// trong địa chỉ cung cấp cho action redirect. Nếu không, giả sử địa chỉ trang web hiện tại là thì địa chỉ sẽ được chuyển tới sẽ là chứ không phải địa chỉ chúng ta muốn. Ngoài việc chuyển hướng request, chúng ta còn có thể định hướng request tới một proxy server được chỉ định. Trong ngữ cảnh chúng ta đang nghiên cứu, thì proxy server này đảm nhận vai trò một mồi nhử (honeypot) nhằm đánh lạc hướng kẻ tấn công. Trong Apache, để có thể hướng request tới proxy, cần cài thêm module mod_proxy. Trong Mod_Security để định hướng sang proxy server, chúng ta sử dụng action proxy, ví dụ một luật sau: SecRule ARGS|REQUEST_URI “@pm waitfor benchmark sleep” “proxy:” ™ Sử dụng chỉ thị SecAction SecAction là một chỉ thị không kèm điều kiện. Tham số duy nhất của chỉ thị này là danh sách các action cần thực thi. Chỉ thị này rất hữu ích cho việc thực thi một action nào đó một cách vô điều kiện, ngoài ra đây cũng là chỉ thị hữu ích có thể dùng khi chúng ta muốn chạy một action như initcol để khởi tạo một biến tập. Xét một chỉ thị: SecAction “pass,log,logdata:’this is a test’” Một điều quan trọng cần nhớ, đó là cần chỉ định một action pass trong chỉ thị SecAction, nếu không các default action sẽ được thêm vào trong chỉ thị này. Tai hại là ở chỗ, các default action thường là deny, và do đó nếu thiếu action pass ở chỉ thị SecAction, mọi request sẽ bị deny bởi chỉ thị này không áp dụng bất cứ điều kiện nào. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 90 2.2.11. Sử dụng ctl để điều khiển rule engine Action ctl là một action được cung cấp đầy đủ sức mạnh để điều khiển được rule engine của ModSecurity. Khi sử dụng action này, chúng ta có thể cấu hình lại được rule engine trong vòng một vòng đời transaction. Các tham số sau có thể được truyền cho action ctl để điều khiển cấu hình tương ứng của ModSecurity. Tham số Tác dụng Chỉ thị tương đương auditEngine Tắt/bật audit engine SecAuditEngine auditLogParts Định nghĩa dữ liệu nào được thêm vào audit log SecAuditLogParts debugLogLevel Thay đổi cấp độ log debug SecDebugLogLevel requestBodyAccess Tắt/bật chế độ truy cập nội dung thân request SecRequestBodyAccess requestBodyLimit Định mức giới hạn cho thân request SecRequestBodyLimit ruleRemoveById Xóa một luật hoặc một số luật liên quan SecRuleRemoveById requestBodyProcessor Cấu hình bộ xử lý thân request (không có) responseBodyAccess Tắt/bật chế độ truy cập vào thân response SecResponseBodyAccess responseBodyLimit Đặt giới hạn cho thân response SecResponseBodyLimit ruleEngine Bật tắt rule engine hoặc chuyển nó sang SecRuleEngine Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 91 chế độ Detection only Giả sử ta sử dụng action ctl để chỉ định bộ xử lý thân request phải xử lý thân truy vấn đó ở dạng XML đối với những request có nội dung thân là XML như sau: SecRule REQUEST_HEADERS:Content-Type “^text/xml$” “nolog,pass,ctl:requestBodyProcessor=XML,ctl:requestBodyAccess=On” 2.2.12. Macro expansion Macro expansion là khả năng thêm (include) dữ liệu từ các biến hoặc các biến tập trong thông điệp log, hoặc sử dụng để khởi tạo một biến khác. Việc sử dụng macro expansion được thực hiện bằng cách bao biến/biến tập trong cặp ngoặc nhọn phía trước là dấu %. Ví dụ ta gán giá trị một biến : SecAction “pass,setenv:ADDR=%{REMOTE_ADDR}” Khi tham chiếu tới dữ liệu của trường trong biến tập, phải sử dụng dấu chấm để ngăn cách tên trường và tên biến tập, ví dụ: SecRule REQUEST_URI “admin” “log,msg:%{TX.0}” Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 92 Tài liệu tham khảo [1] Chris Anley. “Advanced SQL”. NGSSoftware Insight Security Research Publication 2002 [2] Chris Anley. “(more) Advanced SQL Injection”. NGSSoftware Insight Security Research Publication 2002. [3] Luca Carettoni. “HTTP Parameter Pollution”. The OWASP Foundation. [4] Justin Clarke. “SQL Injection Attack and Defense”. Syngress Publishing, Inc 2009. [5] Bernardo Damele A.G. “SQL Injection: Not Only AND 1=1”. [6] Dmitri Evteev. “Methods to Bypass a Web Application Firewall”. Positive Technology research. [7] Dmitri Evteev. “Methods of quick exploitation of Blind SQL Injection”. Positive Technology research. SQL-Injection.pdf [8] OWASP Foundation. “Securing WebGoat Using ModSecurity”. Security_Project [9] OWASP Foundation. “OWASP WebGoat and WebScarab Project”. Khóa luận tốt nghiệp - 2010 SQL Injection – Tấn công và cách phòng tránh 93 [10] Cameron HotchKies. “Blind SQL Injection Automation Techniques”. Blackhat Briefings USA 2004. https://www.blackhat.com/presentations/bh-usa-04/bh-us-04- hotchkies/bh-us-04-hotchkies.pdf [11] Stephen Kost. “An Introduction to SQL Injection Attacks for Oracle Developers - Jan 2004”. resources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf [12] Alexander KornBrust. “Bypassing Oracle dbms_assert”. Red Database Security. [13] David Litchfield. “Bypassing Oracle DBMS_ASSERT (in certain situation) July 2008”. [14] David Litchfield. “Securing PL/SQL Application with DBMS_ASSERT Oct 2005”. NGSSoftware Insight Security Research Publication. [15] David Litchfield. “Data-mining with SQL Injection and Inference Sep 2005”. NGSSoftware Insight Security Research Publication. [16] Magnus Mischel. “ModSecurity 2.5 Securing your Apache installation and Web application”. Packt Publishing 2009. Tr 41-75.