Kỹ thuật lập trình an toàn nghiên cứu biểu thức chính quy trong xác nhận đầu vào trong phát hiện, ngăn chặn tấn công XSS

HỌC VIỆN KỸ THUẬT MẬT MÃ Kỹ Thuật Lập Trình An Tồn Nghiên Cứu Biểu Thức Chính Quy Trong Xác Nhận Đầu Vào Trong Phát Hiện, Ngăn Chặn Tấn Công XSS Thành viên Trần Minh Hòa Phạm Thị Thảo Hiền GVHD : Phạm Duy Trung Khoa An Tồn Thơng Tin Hồ Chí Minh, 2019 Mục lục Chương Giới thiệu Mod Sercurity 1 Mod Sercurity Khả mod sercurity 1.3 Hoạt động mod security Chương Cài đặt mod sercurity 2.1 Yêu cầu: 2.2 Các bước cài đặt 2.3 Cấu trúc Rule 2.4 Các loại log 10 Chương XSS DVWA 11 3.1 XSS 11 3.1.1 Giới thiệu XSS 11 3.1.2 Hình thức tồn XSS 12 3.2 DVWA 14 3.2.1 Giới thiệu 14 3.2.2 Cài đặt 14 Chương Kết thực nghiệm 16 4.1 Khi không bật mod sercurity 16 4.2 Khi bật modsecurity 16 Chương Giới thiệu Mod Sercurity Mod Sercurity - ModSecurity web application firewall(WAF) Ivan Ristic phát triển dành cho Apache Web Server Giống firewall thơng thường khác, lọc lưu lượng liệu vào để định chặn lại lưu lượng mà nghi ngờ độc hại dựa theo tập lệnh định nghĩa Nó cịn có nhiều tính vượt trội khác : HTTP transaction logging content injection… - Các luật tạo chỉnh sửa sử dụng định dạng văn đơn giản, làm cho việc viết rules trở nên đơn giản Một quen với cú pháp ModSecurity, nhanh chóng viết rules để block exploit ngăn chặn lỗ hổng - Có thể hình dung ModSecurity trạm trung gian HTTP request httpd (dịch vụ web server) Khi phát công, chi tiết vụ công lưu vào log file email gửi tới người quản trị viên để báo hiệu có cơng xảy hệ thống - ModSecurity cho phép bạn bảo vệ server thơng qua việc viết luật nhằm bao phủ dải viễn cảnh cơng Do đó, ModSecurity lớp bổ sung giúp bạn bảo vệ theo cách không cần vá - ModSecurity giải vấn đề tầm nhìn : giúp bạn nhìn thấy lưu lượng web Đó chìa khóa security : bạn nhìn thấy HTTP traffic, bạn phân tích thời gian thực, record cần thiết phàn ứng lại với kiện Điểm bật bạn làm tất mà khơng tác động tới ứng dụng web Thậm chí tốt hơn, cịn áp dụng với ứng dụng nào, bạn truy vào source code Khả mod sercurity Như bạn thấy, Mod Security đứng trước Web Server, làm nhiệm vụ firewall để kiểm soát truy cập vào Web Server Các thông tin từ bên ngồi vào bên kiểm sốt chặt chẽ để tránh thơng tin gây hại cho Web Server việc rò rỉ thông tin đặc biệt từ Web Server đến Client Mod Security thực chức cụ thể sau: • Request filtering : tất request gửi đến web server phân tích càn lọc (filter) trước chúng đưa đến modules khác để xử lý • Anti-evasion techniques : paths parameters chuẩn hóa trước phân tích để chống evasion techniques • Understanding of the HTTP protocol : ModSecurity web application firewall nên có khả hiểu HTTP protocol ModSecurity có khả càn lọc dựa thơng tin HTTP header hay xem xét đến parameters hay cookies requests… • POST payload analysis : việc càn lọc dựa HTTP header, ModSecurity dựa nội dung (payload) POST request • Audit logging : request ghi lại (bao gồm POST) để người quản trị theo dõi cần • HTTPS filtering : ModSecurity phân tích HTTPS • Compressed content filtering : ModSecurity phân tích sau decompress request data Có điều đáng ý ModSecurity có khả phân tích https Nhiều bạn thắc mắc ModSecurity đọc thơng tin bị mã hố với ssl(secure sockets layer) Thực theo mơ hình mơ tả ModSecurity đứng trước Web Server, thực tế ModSecurity module Web Server Tất thơng tin mã hố với ssl Web Server giải mã trước, sau chuyển tới ModSecurity để xử lý 1.3 Hoạt động mod security Quá trình xử lý request Apache ModSecurity : Trong ModSecurity, phiên phân tích thực qua bước (phase), bước ModSe ModSecurity cho phép bạn đặt rule năm thời điểm chu kỳ xử lý Apache sau : - Phase Request Header : rule đặt thực sau Apache đọc request header, lúc phần request body chưa đọc Đây bước q trình thực phân tích gói tin Mục đích bước nhằm cho phép người viết rule tương tác với request trước thực yêu cầu phần HTTP body Phần quan trọng để phân tích khai thác dựa vào HTTP method dựa vào URL SQL Injection, Reflect XSS, Local file include … - Phase Request Body : thời điểm thông tin chức chung đưa vào phân tích xem xét, rule mang tính application-oriented thường đặt Bước q trình kiểm tra trình client gởi request đến server, phần có hiệu người dùng cố sử dụng phương thức POST PUT để upload tập tin lên phía server Việc kiểm tra bảo đảm liệu đưa lên server an tồn, tránh tình trạng upload mã độc dạng công 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 liệu • Multipart/form-data dùng để truyền file • Text/xml : dùng để phân tích liệu XML - Phase Response Header : Những request xử lý server trả cho ModSecurity kiểm tra trạng thái phần respone header Trước phần respone body đọc ModSecurity dựa vào tập rule để xác định có cần kiểm tra nội dung liệu phần body hay khơng Ví dụ: mã trạng thái trả 404 (Not found) lúc khơng cần kiểm tra nội dung gói tin trả - Phase Response Body : Sau ModSecurity hoàn thành việc kiểm tra respone header nội dung phần body kiểm tra so trùng với mẫu tập lệnh Việc hiệu để phát phòng chống xâm nhập trường hợp phase request header phase request body không phát cơng Ví dụ: khai thác SQL injection, hacker cố gắng sử dụng số công nghệ evasion việc phát request khó khăn Khi khai thác thành cơng, ModSecurity phân tích kết gói tin trả để phát câu truy vấn thành công - Phase Logging : thời điểm hoạt động log thực rules đặt định rõ việc log nào, kiểm tra error message log Apache Đây thời điểm cuối để bạn chặn connection không mong muốn, kiểm tra response header mà bạn kiểm tra phase response header phase response b Chương Cài đặt mod sercurity (Cài đặt ModSecurity Ubuntu 18.04 LTS) 2.1 Yêu cầu:  Ubuntu 18.04 LTS  APACHE2  Cài đặt LAMP XAMPP Các bước cài đặt - Bước 1: Cài đặt mod security: 2.2 sudo apt-get install libapache2-mod-security2 • Khởi động lại Apache2: sudo service apache2 restart • Kiểm tra xem thử ModSecurity enable hay chưa: sudo apachectl -M | grep security Bước 2: Cấu hình Mod Security Để ModeSecurity hoạt động được, ta tiễn hành enable SecRuleEngine file configure Lưu ý: Mỗi thay đổi file configure, cần restart lại Apache2 service Khi đến bước này, ta hồn thành thiết lập xong ModSecurity đưa vào sử dụng Tuy nhiên, để tăng cường khả bảo mật, ta cần thiết lập rule cho Bước Thiết lập rule Github: https://github.com/SpiderLabs/owasp-modsecurity-crs Trước hết, ta backup lại rule mặc định ModSecurity sudo mv /usr/share/modsecurity-crs /usr/share/modsecurity-crs.bk Sau đó, tiến hành clone source CRS từ trang github về: sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git /usr/share/modsecurity-crs Đổi tên file configure rule: sudo cp /usr/share/modsecurity-crs/crs-setup.conf.example /usr/share/modsecurity-crs/crs-setup.conf Thêm file rule vào file configure ModSecurity Apache2 sudo nano /etc/apache2/mods-enabled/security2.conf IncludeOptional /usr/share/modsecurity-crs/*.conf IncludeOptional "/usr/share/modsecurity-crs/rules/*.conf Cuối không quên restart lại Apache2 service Cấu trúc Rule Cấu trúc rule modsecurity bao gồm thông tin khác , yêu cầu thiết đặt 2.3 khác nội dung - Cấu trúc bao gồm thị, biến, hàm chuyểnđổi, signature action tương ứng cho phép, không cho phép, ghi log - Yêu cầu logic phát cơng - Thiết đặt sách đưa hành động xử lý phát công - Thông tin công Cho phép xử lý tách riêng thành thành phần khác nhau, coreruler dựa mẫu xây dựng sẳn tự xây dựng thêm core rule Khái quát SecRule gồm thành phần: Variables: cho Modsecurity nơi cần tìm hay cịn gọi mục tiêu Operator: thị Modsecurity để khích hoạt lần thực thi Transformation: thị Modsecurity chuẩn hóa liệu biến Actions: Cho Modsecirity biết cần phải làm rule trùng khớp (kiểm tra với lọc) Biến: có 105 biến loại khác nhau, ví dụ như: • Biến Request - ARGS, REQUEST_HEADERS, REQUEST_COOKIES • Biến Response - RESPONSE_HEADERS, RESPONSE_BODY • Biến Server - REMOTE_ADDR, AUTH_TYPE • Biến Time - TIME, TIME_EPOCH, TIME_HOUR • Biến Collection - TX, IP, SESSION, GEO • Biến Miscellaneous - HIGHEST_SEVERITY, MATCHED_VAR Operators: có 36 thị loại khác nhau, ví dự như: • String Operators - rx, pm, beginsWith, contains, endsWith, streq, within • Numerical Operators - eq, ge, gt, le, lt • Validation Operators - validateByteRange, validateUrlEncoding, validateSchema • Miscellaneous Operators - rbl, geoLookup, inspectFile, verifyCC Transformation: có 35 hàm dịch loại khác nhau, ví dự như: • Hàm chống xê dịch - lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace • Hàm giải mã - base64Decode, hexDecode, jsDecode, urlDecodeUni • Hàm mã hóa - base64Encode, hexEncode • Hàm băm - sha1, md5 Actions: có 47 hành động loại khác nhau, ví dụ như: • Disruptive Actions - block, drop, deny, proxy • Flow Actions - chain, skip, skipAfter • Metadata Actions - phase, id, msg, severity, tag • Variable Actions - capture, setvar, initcol • Logging Actions - log, auditlog, nolog, sanitiseArg • Miscellaneous Actions - ctl, multiMatch, exec, pause, append/prepend Có phase bao gồm: Request Headers (1), Request Body (2), Response Headers (3), Response Body (4) and Logging (5) Các rule thường thực phase – Request Body tồn thơng tin trang kết nối  Cấu trúc rule gồm: SecRule VARIABLES "OPERATOR" "TRANSFORMATIONS,ACTIONS" Ví dụ: SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES "@contains () {" "id:420008,phase:2,t:none,t:lowercase,deny,status:500,log,msg:'Malware expert user-agent: Bash ENV Variable Injection Attack'" Variables: - REQUEST_LINE: tất dịng request thành cơng đến server bao gồm phương thức thông tin phiên HTTP - REQUEST_HEADERS: tất header request - REQUEST_HEADERS_NAMES: tất tên REQUEST HEADER Operator: - @contains () {: tìm tất cá biến yêu cầu chuỗi “()}” tìm thấy trả true Transformations: - t:none: khơng chuyển giá trị cảu biến trước trùng khớp - t:lowercase: chuyển REQUEST dạng chữ thường Actions: - id:420008: id gán cho rule xuất - phase:2: phase thực phase REQUEST BODY - deny: hành động từ chối truy cập - status:500: appache hearder gửi đến client - Log: rule trùng khớp error audit log - msg:'Malware expert - user-agent: Bash ENV Variable Injection Attack'": thông điệp tùy chỉnh gán cho rule xuất trùng khớ 2.4 Các loại log Trong Modsecurity có loại log chính: • 1.Error log • 2.Debug log • 3.Auditlog • Error log Đây loại nhật ký tạo gặp lỗi nỗ lực độc hại gặp phải máy chủ Vì ModSecurity hoạt động với Apache, tất nhật ký lỗi (Nhật ký lỗi Apache + Nhật ký lỗi bảo mật Mod) tạo tệp Nó có nghĩa tất nhật ký lỗi, cảnh báo, lỗi nghiêm trọng, v.v nhật ký lỗi ModSecurity tìm thấy tệp, theo mặc định nằm đường dẫn sau Chương XSS DVWA 3.1 XSS 3.1.1 Giới thiệu XSS Cross-Site Scripting hay cịn gọi tắt XSS (thay gọi tắt CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet HTML) kĩ thuật công cách chèn vào website động (ASP, PHP, CGI, JSP…) thẻ HTML hay đoạn mã script nguy hiểm gây nguy hại cho người sử dụng khác Trong đoạn mã nguy hiểm chèn vào hầu hết viết Client-Site Script javascript, Jscript, DHTML thẻ HTML XSS lỗi phổ biến, có nhiều trang web bị mắc phải lỗi này, ngày có nhiều người quan tâm đến lỗi Phương pháp không nhằm vào máy chủ hệ thống mà chủ yếu cơng máy người sử dụng Hacker lợi dụng kiểm tra lỏng lẻo lợi dụng vào hiểu biết hạn chế người dung biết đánh vào tò mò họ dẫn đến người dùng bị thông tin cách dễ dàng Thông thường hacker lợi dụng địa URL để đưa liên kết tác nhân kích hoạt đoạn chương trình viết ngơn ngữ máy khách VBScript, JavaScript… thực thi trình duyệt nạn nhân 3.1.2 Hình thức tồn XSS  Stored XSS Stored XSS hình thức cơng mà cho phép kẻ cơng chèn đoạn script nguy hiểm (thường Javascript) vào website thông qua chức (vd: viết lwofi bình, guestbook, gởi bài…), để từ thành viên khác truy cập website bị dính mã độc từ kẻ cơng này, mã độc thườn lưu lại database website nên gọi Stored Stored XSS phát sinh không lọc liệu thành viên gởi lên đắn, khiến cho mã độc lưu vào Database Website  Reflected XSS Trong hình thức này, kẻ cơng thường gắn thêm đoạn mã độc vào URL website gởi đến nạn nhân, nạn nhân truy cập URL bị dính mã độc Điều xảy ta không ý filter input từ URL website  DOM BASED XSS DOM-based XSS biến thể persistent reflected XSS Trong DOM-based XSS attack, chuỗi độc hại không thực xử lý trình duyệt nạn nhân JavaScript hợp pháp website thực thi Trong persistent reflected XSS attack, máy chủ chèn tập lệnh độc hại vào trang để gửi phản hồi cho nạn nhân Khi trình duyệt nạn nhân nhận phản hồi, nhận tập lệnh độc hại phần nội dung trang tự động thực thi với tập lệnh khác 3.2 DVWA 3.2.1.Giới thiệu Damn Vulnerable Web Application (DVWA) ứng dụng mã nguồn PHP/MySQL tập hợp sẵn lỗi logic bảo mật ứng dụng web mã nguồn PHP Lỗi logic lập trình áp dụng loại ngơn ngữ lập trình nhằm giảm thiểu khả tạo lổ hổng bảo mật từ tư lập trình chưa cẩn thận 3.2.2 Cài đặt DVWA ứng dụng mã nguồn PHP Cơ Sở Dữ Liệu MySQL, nên bạn cài đặt dịch vụ XAMPP Linux Windows để tạo môi trường thực hành nhanh chóng Hoặc bạn cài đặt hệ thống web server LAMP/LEMP CentOS/Ubuntu để thực hành Các lổ hổng DVWA: Khi bạn thực hành với DVWA, bạn có nhóm lổ hổng bảo mật sau: • Brute Force • Command Execution • Cross Site Request Forgery (CSRF) • File Inclusion • SQL Injection • Insecure File Upload • Cross Site Scripting (XSS) • Easter eggs Các mức độ bảo mật DVWA: DVWA cung cấp mức độ bảo mật tương ứng level để bạn thực hành từ dễ khó gồm : High - mức cao nhất: Level gần level dùng để so sánh mã nguồn có lổ hổng mức low medium với mã nguồn tối ưu mức an toàn bảo mật Medium - mức trung bình: Mức độ cung cấp nội dung logic code fix lổ hổng hạng mục mức low Low - mức độ thấp nhất: Với mức độ low mã nguồn PHP gân phơi bày khả khai thác lổ hổng qua tư lập trình chưa bao quát vấn đề bảo mật Đối với trang thực hành bảo mật ln có nút view source Nút sử dụng để xem nội dung source code mức bảo mật ứng mổi hạng mục, để từ bạn so sánh, đánh giá lý mã nguồn lại phơi bày lổ hổng bảo mật Chương Kết thực nghiệm Sử dụng DVWA thể minh họa kết họa kết công XSS khơng bật modsecurity có bật modsecurity 4.1 Khi không bật mod sercurity 4.2 Khi bật modsecurity - Chỉnh SecRuleEngine thành On, sau ta tiến hành restart apache lệnh: service apache2 restart - Đường dẫn chứa rule - Rule thực chặn công XSS - Kết quả: Tấn công XSS bị chặn ... Stored Stored XSS phát sinh không lọc liệu thành viên gởi lên đắn, khiến cho mã độc lưu vào Database Website  Reflected XSS Trong hình thức này, kẻ công thường gắn thêm đoạn mã độc vào URL website... sau Chương XSS DVWA 3.1 XSS 3.1.1 Giới thiệu XSS Cross-Site Scripting hay gọi tắt XSS (thay gọi tắt CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet HTML) kĩ thuật công cách chèn vào website... tác nhân kích hoạt đoạn chương trình viết ngôn ngữ máy khách VBScript, JavaScript… thực thi trình duyệt nạn nhân 3.1.2 Hình thức tồn XSS  Stored XSS Stored XSS hình thức cơng mà cho phép kẻ cơng