Tìm hiểu bài toán web an toàn và đề xuất giải pháp firewall cho các ứng dụng web

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI - Đỗ Đức Ngun TÌM HIỂU BÀI TỐN WEB AN TOÀN VÀ ĐỀ XUẤT GIẢI PHÁP FIREWALL CHO CÁC ỨNG DỤNG WEB Chuyên ngành: Mạng máy tính truyền thông liệu LUẬN VĂN THẠC SĨ KỸ THUẬT MẠNG MÁY TÍNH VÀ TRUYỀN THƠNG DỮ LIỆU NGƯỜI HƯỚNG DẪN KHOA HỌC TS Phạm Huy Hoàng Hà Nội – Năm 2018 Mục lục LỜI CAM ĐOAN LỜI CẢM ƠN DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT DANH MỤC CÁC BẢNG DANH MỤC CÁC HÌNH VẼ CHƯƠNG 1: MỞ ĐẦU Lý chọn đề tài Nhiệm vụ đặt cho đề tài Hướng tiếp cận giải Bố cục luận văn CHƯƠNG 2: ỨNG DỤNG WEB VÀ CÁC LỖ HỔNG BẢO MẬT PHỔ BIẾN TRONG ỨNG DỤNG WEB 11 Khái niệm ứng dụng web 11 Các lỗ hổng bảo mật phổ biến ứng dụng web 11 2.1 Giới thiệu Open Web Application Security Project (OWASP) 11 2.2 Lịch sử OWASP Top 10 12 2.3 A1 - Lỗi nhúng mã – Injection 15 2.4 A2 – Phá vỡ tính xác thực – Broken Authentication 15 2.5 A3 – Để lộ liệu nhạy cảm – Sensitive Data Exposure 15 2.6 A4 – Thực thể bên XML - XML External Entities (XXE) 16 2.7 A5 – Phá vỡ kiểm soát truy cập – Broken access control 16 2.8 A6 – Sai sót cấu hình an ninh – Security Misconfiguration 16 2.9 A7 - Thực thi mã script – Cross-Site Scripting (XSS) 17 2.10 A8 – Giải hóa khơng an toàn - Insecure Deserialization 17 2.11 A9 – Sử dụng thành phần có lỗ hổng biết – Using Components with Known Vulnerabilities 17 2.12 A10 – Không đủ nhật ký giám sát – Insufficient Logging & Monitoring 18 CHƯƠNG 3: ĐỀ XUẤT GIẢI PHÁP TƯỜNG LỬA ỨNG DỤNG WEB 19 Trang 1 Tại cần tường lửa ứng dụng web? 19 Đề xuất giải pháp tường lửa mã nguồn mở ModSecurity 19 2.1 Lý lựa chọn giải pháp mã nguồn mở 19 2.2 Các giải pháp tường lửa mã nguồn mở 20 2.3 Giới thiệu ModSecurity 21 2.4 Hoạt động ModSecurity 21 Mơ hình triển khai hướng dẫn cài đặt 23 3.1 Mơ hình triển khai 23 3.2 Hướng dẫn cài đặt 26 Tìm hiểu rule 27 Thử nghiệm số kịch công khai thác lỗ hổng 28 5.1 Tổng quan kịch thử nghiệm 28 5.2 Thử nghiệm khai thác lỗ hổng nhúng mã – Injection 29 5.3 Thử nghiệm khai thác lỗ hổng phá vỡ tính xác thực – Broken Authentication 34 5.4 Thử nghiệm khai thác lỗ hổng thực thi mã script XSS 40 5.5 Đánh giá mức độ an toàn số website cụ thể 43 CHƯƠNG 4: KẾT LUẬN 50 TÀI LIỆU THAM KHẢO 52 Trang LỜI CAM ĐOAN Tôi xin cam đoan đề tài nghiên cứu tơi hồn tồn tơi tự làm hướng dẫn thầy giáo TS.Phạm Huy Hồng Những kết tìm hiểu nghiên cứu trình bày luận văn hoàn toàn trung thực chưa cơng bố cơng trình Nếu xảy điều không lời cam đoan trên, tơi xin chịu hồn tồn trách nhiệm trước Viện Nhà trường Ngày 15 tháng 09 năm 2018 Học viên Đỗ Đức Nguyên Trang LỜI CẢM ƠN Em xin chân thành cảm ơn thầy giáo TS.Phạm Huy Hồng có hướng dẫn góp ý q báu giúp em hồn thành luận văn Em xin gửi lời cảm ơn đến thầy cô giáo viện Công nghệ thông tin truyền thông trường Đại học Bách Khoa Hà Nội hướng dẫn đưa lời khuyên bổ ích Cuối cùng, em xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp người thân động viên, giúp đỡ trình thực đồ án tốt nghiệp Xin chân thành cảm ơn tất cả! Trang DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT THUẬT NGỮ GIẢI THÍCH WAF Web Application Firewall: Tường lửa ứng dụng web FIREWALL Tường lửa WEBAPP Ứng dụng web HTTP (S) Hypertext Transfer Protocol (Secure): Giao thức truyền tải siêu văn (bảo mật) OWASP Open Web Application Security Project: Dự án bảo mật ứng dụng web OWASP TOP 10 Open Web Application Security Project top 10: 10 lỗ hổng phổ biến theo OWASP DATABASE Cơ sở liệu SQL Structured Query Language: ngôn ngữ truy vấn mang tính cấu trúc VULNERABILITY Lỗ hổng PROXY Máy chủ trung gian người dùng máy chủ web URL Uniform Resource Locator: Định vị Tài nguyên thống ID Identification: Định danh XML eXtensible Markup Language: Ngôn ngữ đánh dấu mở rộng BRUTE FORCE Một kiểu công bảo mật CRS Core Rule Set: Bộ quy tắc cốt lõi Trang DANH MỤC CÁC BẢNG Bảng Bảng 3.1 Mô tả So sánh giải pháp firewall Trang Trang 22 DANH MỤC CÁC HÌNH VẼ Hình Mơ tả Trang Hình 2.1 Ứng dụng web 11 Hình 2.2 Các tiêu chí đánh giá rủi ro lỗ hổng 12 Hình 3.1 Các pha hoạt động ModSecurity 23 Hình 3.2 Mơ hình tích hợp vào web server (embedded) 25 Hình 3.3 Mơ hình tích hợp reverse proxy 27 Hình 3.4 Mơ hình thử nghiệm 29 Hình 3.5 Máy chủ web OWASP Mutillidae 30 Hình 5.1 Giao diện WAF-FLE 53 Hình 5.2 Các giải pháp WAF chuyên dụng 53 Trang CHƯƠNG 1: MỞ ĐẦU Lý chọn đề tài Thực trạng an tồn thơng tin Việt Nam ngày diễn biến phức tạp nguy hiểm Các cơng mạng có quy mơ, mức độ phức tạp chuẩn bị cách kỹ lưỡng Trong đó, mục tiêu công dần chuyển dịch từ mục tiêu cá nhân, sang mục tiêu tập đoàn kinh tế lớn hay nghiêm trọng hệ thống thông tin quan trọng quốc gia Hàng loạt hệ thống website Ngân hàng lớn, doanh nghiệp lớn bị công gây thiệt hại đáng kể [19] Thực tế với tình hình nay, ứng dụng web ngày nhiều Sự thay đổi chóng mặt cơng nghệ giúp ứng dụng web cải tiến nâng cao nhiều, vấn đề bảo mật cho ứng dụng web không ngừng tăng lên Một ứng dụng web bị rò rỉ lỗ hổng, tin tặc dễ dàng chiếm quyền quản trị web, ứng dụng phần mềm công ty Nguyên nhân dẫn đến ứng dụng web bị rị rỉ thơng tin, nguy lỗ hổng, đoạn mã lệnh, mã code không phù hợp ứng dụng web Chỉ cần lỗ hổng, tin tặc xâm nhập truy cập vào sở liệu, thông tin thực hành vi sai trái đánh cắp, thay đổi, chỉnh sửa, mã hóa liệu…[11] Để đối phó với nguy rủi ro đó, có nhiều cơng cụ, giải pháp phát triển nhằm mục đích bảo vệ ứng dụng web khỏi lỗi bảo mật công, mã độc từ tin tặc.Các giải pháp gọi tường lửa ứng dụng web (Web Application Firewall – WAF) WAF thiết bị phần cứng phần mềm cài lên máy chủ có chức theo dõi thơng tin truyền qua giao thức http/https trình duyệt người dùng máy chủ web lớp Một WAF có khả thực thi sách bảo mật dựa dấu hiệu công, giao thức tiêu chuẩn lưu lượng truy cập ứng dụng web bất thường Đây điều mà tường lửa mạng khác không làm Với mong muốn phân tích tìm hiểu sâu lỗ hổng ứng dụng web phương thức hoạt động, khả ngăn chặn WAF, học viên lựa chọn đề tài “Tìm hiểu tốn Web an tồn đề xuất giải pháp Firewall cho ứng dụng Web” làm luận văn tốt nghiệp Nhiệm vụ đặt cho đề tài Nhiệm vụ đề tài tìm hiểu lỗ hổng bảo mật ứng dụng web đề xuất giải pháp WAF để bảo vệ ứng dụng web khỏi lỗ hổng bảo mật Trong đó: Trang [1] Tìm hiểu lỗ hổng bảo mật ứng dụng web là: tìm hiểu 10 lỗ hổng tiêu biểu theo tổ chức OWASP đánh giá vào năm 2017 (OWASP Top 10) [2] Giải pháp WAF đề xuất cần đạt nhiệm vụ sau: - Giải pháp ngăn chặn tin tặc khai thác lỗ hổng tiêu biểu - Giải pháp phải cho phép người quản trị cấu hình sách cách linh - hoạt Giải pháp phải có khả triển khai áp dụng vào thực tế Hướng tiếp cận giải Đầu tiên học viên cần tìm hiểu danh sách lỗ hổng bảo mật tiêu biểu theo tổ chức OWASP đánh giá Danh sách đánh giá cần đảm bảo thực đề tài Để trình tìm hiểu hiệu quả, việc cài đặt máy chủ web chứa lỗ hổng để tiến hành khai thác thử cần thiết Việc nắm vững lỗ hổng điều kiện tiên để học viên thực nhiệm vụ đề xuất giải pháp WAF Trong phạm vi nghiên cứu luận văn, giải pháp WAF mã nguồn mở lựa chọn hợp lý Tuy nhiên, giải pháp cần phải đáp ứng nhiệm vụ đặt phần Học viên cần phân tích khác lợi ích đem lại hệ thống trước sau triển khai WAF Các nội dụng thực đề tài: Tìm hiểu lỗ hổng bảo mật ứng dụng web (OWASP Top 10) Tìm hiểu, cài đặt, thử nghiệm máy chủ web chứa lỗ hổng phần mềm mã nguồn mở WAF ModSecurity - Xây dựng sách ngăn chặn khai thác lỗ hổng - Thử nghiệm giải pháp cách khai thác lỗ hổng so sánh kết trước sau triển khai WAF Bố cục luận văn Bố cục luận văn chia thành chương sau: - Chương 1: Mở đầu: Mô tả chi tiết mục tiêu, nhiệm vụ đề tài hướng tiếp cận Chương 2: Ứng dụng web lỗ hổng bảo mật ứng dụng web : Nghiên cứu sở lý thuyết ứng dụng web lỗ hổng bảo mật ứng dụng web theo đánh giá tổ chức OWASP Chương 3: Đề xuất giải pháp tường lửa ứng dụng web: Tìm hiểu đề xuất giải pháp tường lửa ứng dụng web, bao gồm nội dung: (1) Giới thiệu giải pháp, (2) Mơ hình Trang Tiến hành công, ta thấy phần lớn password có trạng thái 200, password “adminpass” có trạng thái 302 (Found) → Đã xác định password admin Trang 38 Do trang quản trị login không giới hạn số lần đăng nhập lỗi, nên danh sách password duyệt thay vào biến password Trong trường hợp người dùng sử dụng mật yếu, việc tài khoản người dùng bị bẻ gãy xác thực xảy cao b) Cấu hình rule ngăn chặn Qua phân tích nhận thấy rằng, tin tặc công thành công nhờ vào hai nguyên nhân sau Một trang quản trị login không giới hạn số lần đăng nhập hai tài khoản admin cấu hình yếu Bây cấu hình rule để kiểm sốt việc giới hạn số lần đăng nhập lỗi Ta cấu hình rule block địa IP vòng phút đăng nhập sai 10 lần vòng phút Chi tiết rule sau [17] SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134 SecRule ip:bf_block "@gt 0" "deny,status:406,log,id:5000135,msg:'Bruteforce detected'" SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136" SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1 /180,id:5000137" SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0" Khi đó, thử cơng lại máy chủ web trả lỗi 406, khơng cho tiếp tục đăng nhập từ lần sai thứ 10 Trang 39 Và ghi nhận audit log: d646861e-F-HTTP/1.1 406 Not Acceptable Content-Length: 356 Connection: close Content-Type: text/html; charset=iso-8859-1 d646861e-H-Message: Access denied with code 406 (phase 2) Operator GT matched at IP:bf_block [file "/opt/modsecurity/etc/DemoRule/Brute.conf"] [line "5"] [id "5000135"] [msg " Bruteforce detected' Action: Intercepted (phase 2) Apache-Handler: php5-script Stopwatch: 1538492555161909 1314 (- - -) Stopwatch2: 1538492555161909 1314; combined=170, p1=130, p2=25, p3=0, p4=0, p5=14, sr=80, sw=1, l=0, gc=0 Producer: ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) Server: Apache/2.2.15 (CentOS) Engine-Mode: "ENABLED" 5.4 Thử nghiệm khai thác lỗ hổng thực thi mã script XSS Menu thử nghiệm OWASP 2017 → A7 – Cross Site Scripting (XSS) → Persistent (Second Order) → Add to your blog Trang 40 a) Khai thác Menu có chức cho phép người dùng tự tạo blog để chia sẻ cho người khác Người dùng khác sử dụng tính View Blog để xem viết chia sẻ người dùng khác Tuy nhiên, thay tạo blog bình thường, tin tặc chèn vào đoạn mã với ý đồ xấu ăn cắp cookie phiên truy cập người dùng Ta thử viết blog với nội dung sau THIS IS HOT NEWS!!! alert(document.cookie) Khi tin tặc tiến hành Save Blog Entry, đoạn mã script bị ẩn đi, cịn hiển thị thơng tin blog bình thường Kịch xảy người dùng khác vô tình truy cập đến blog thực thi đoạn mã xấu mà không hay biết Trang 41 Trong thực tế, tin tặc không để pop-up thông tin kết mà đoạn mã âm thầm gửi thơng tin qua máy chủ địa email Từ người dùng bị thông tin mà không hay biết b) Cấu hình rule ngăn chặn Qua phân tích nhận thấy việc khơng kiểm soát tốt nội dung nhập vào dẫn đến tin tặc chèn thêm đoạn mã thực thi xấu Bây cấu hình rule để ngăn chặn người dùng nhập đoạn mã thực thi Chi tiết rule sau SecRule ARGS:blog_entry "" "id:'100005',phase:2,t:lowercase,deny,msg:'XSS',status:406" Khi thử khai thác lại nhận lỗi từ chối từ phía server Trang 42 Và ghi nhận audit log 48cb0b77-F-HTTP/1.1 406 Not Acceptable Content-Length: 356 Connection: close Content-Type: text/html; charset=iso-8859-1 48cb0b77-H-Message: Access denied with code 406 (phase 2) Pattern match "" at ARGS:blog_entry [file "/opt/modsecurity/etc/DemoRule/xss.conf"] [line "1"] [id "100005"] [msg "XSS"] Action: Intercepted (phase 2) Apache-Handler: php5-script Stopwatch: 1538669011990759 1565 (- - -) Stopwatch2: 1538669011990759 1565; combined=263, p1=222, p2=28, p3=0, p4=0, p5=12, sr=76, sw=1, l=0, gc=0 Producer: ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) Server: Apache/2.2.15 (CentOS) Engine-Mode: "ENABLED" 5.5 Đánh giá mức độ an toàn số website cụ thể a) Website viện đào tạo sau đại học BKHN Ở thử tiến hành khai thác lỗ hổng máy chủ web Mutillidae Việc khai thác thành công giúp hiểu lỗ hổng Phần thử tiến hành khai thác đơn giản số website cụ thể xem có tồn lỗ hổng hay không Website chọn website viện đào tạo sau đại học, trường Đại học Bách Khoa Hà Nội: http://sdh.hust.edu.vn Đây website cung cấp thơng tin thức viện đào tạo sau đại học Mỗi học viên cao học cấp tài khoản để quản lý thơng tin trình học Nhận xét nhận thấy website dùng giao thức HTTP, khơng phải HTTPS Do người dùng dễ dàng gặp nguy hiểm bị tin tặc Trang 43 công nghe lén, khai thác thông tin (Theo lỗ hổng A3 – Để lộ liệu nhạy cảm – Sensitive Data Exposure) Tiếp theo thử tiến hành khai thác SQL Injection kịch thử nghiệm Trước tiên, thử nhập tên người dùng ký tự ' mật Kết trả có thơng tin “tên đăng nhập không đúng”và không kèm theo dịng thơng báo Thử vài trường hợp khác, kết trả Các lập trình viên lập trình tốt để không hiển thị thông báo lỗi chi tiết cho người dùng Tiếp tục nhập thông tin tên người dùng ' or '1' = '1' mật Kết trả Qua kiến thức hạn hẹp mình, tác giả cơng nhận website khơng có lỗ hổng SQL injection Khai thác thử cơng brute force để phá vỡ tính xác thực website Công cụ tiếp tục dùng Burp suite User hướng đến user tác giả: CB160565 Danh sách mật sử dụng danh sách 1000 mật phổ biến (Vì khai thác để kiểm thử xem khai thác hay không nên ID tác giả lựa chọn) Kết cho thấy công thành cơng lần thử thứ 201 Từ ta rút kết luận rằng, website tồn lỗ hổng: cho phép người dùng thiết lập mật đơn giản, không giới hạn số lần đăng nhập sai người dùng Trang 44 Một số khai thác XXE XSS không phù hợp với website Với kiến thức hạn hẹp tác giả, qua thử nghiệm đưa kết luận lỗ hổng sau: • Website khơng sử dụng HTTPS • Không yêu cầu người dùng thiết lập mật phức tạp • Khơng giới hạn số lần đăng nhập sai Tuy nhiên, thông tin website không thật quan trọng, thông tin bị khai thác gây ảnh hưởng cho nhà trường học viên Do khơng đối tượng hướng đến kẻ xấu b) Website trường Đại học Xây Dựng Website website trường đại học, trường Đại học Xây Dựng: http://daotao.nuce.edu.vn/ Đây website cung cấp thơng tin thức chương trình đào tạo trường Xây Dựng Mỗi sinh viên cấp tài khoản để quản lý thơng tin trình học Trang 45 Nhận xét đầu tiên, giống trên, nhận thấy website dùng giao thức HTTP, khơng phải HTTPS Do người dùng dễ dàng gặp nguy hiểm bị tin tặc công nghe lén, khai thác thông tin (Theo lỗ hổng A3 – Để lộ liệu nhạy cảm – Sensitive Data Exposure) Tiếp theo, dễ dàng tìm hiểu thơng tin quy định thiết lập thông tin đăng nhập dưới: Do vậy, thử nghĩ liệu sinh viên nhận tài khoản mà chưa đổi mật nghĩa mật thơng tin ngày tháng năm sinh sinh viên (Các sinh viên thường lười đổi mật khẩu) Không nhiều thời gian, có thơng tin mã số sinh viên số bạn sinh viên Và bắt đầu tiến hành cơng brute force để tìm mật Và thật bất ngờ, khơng khó để tiến hành cơng thành cơng, từ chiếm quyền sinh viên Dưới số kết Trang 46 Trang 47 Một số khai thác SQL Injection, XXE XSS không thành công Với kiến thức hạn hẹp tác giả, qua thử nghiệm đưa kết luận lỗ hổng sau: • Website khơng sử dụng HTTPS • Các sách thiết lập tên đăng nhập/mật công khai rộng rãi, mang lại tiện lợi nhanh chóng có nhiều rủi ro cao • Khơng u cầu sinh viên bắt buộc phải thay đổi mật mặc định sau lần đăng nhập thành cơng • Khơng giới hạn số lần đăng nhập sai Tuy nhiên, thông tin website không thật quan trọng, thông tin bị khai thác gây ảnh hưởng cho nhà trường sinh viên Do không đối tượng hướng đến kẻ xấu Trang 48 c) Website Ngân hàng Vietcombank Website mà hướng tới website ngân hàng Vietcombank: https://vietcombank.com.vn/ Đây website ngân hàng lớn Việt Nam, cho phép người dùng thực giao dịch trao đổi tiền Nhận xét đầu tiên, website dùng giao thức bảo mật HTTPS, chứng thư số hợp lệ, dùng để xác thực xác Vietcombank mà khơng thể giả mạo Tiếp theo đến giao diện đăng nhập Dễ dàng nhận thấy, tên đăng nhập mật khẩu, hệ thống yêu cầu nhập thêm mã kiểm tra (mã kiểm tra thay đổi lần) Do việc cơng brute force để tìm mật gần Hơn nữa, thử đăng nhập sai có cảnh báo khóa tài khoản đăng nhập sai q lần Vì vậy, khơng thể sử dụng cách công thông thường để áp dụng với Vietcombank Với kiến thức hạn hẹp tác giả, tác giả khơng tìm thấy lỗ hổng website ngân hàng Vietcombank Qua đưa kết luận số yêu cầu cho tính bảo mật nâng cao website mà Vietcombank thiết lập sau: • Website sử dụng HTTPS • Thơng tin đăng nhập u cầu thêm mã kiểm tra thay đổi lần • Giới hạn số lần đăng nhập sai (5 lần) Với quan trọng hệ thống, yêu cầu đảm bảo an ninh tối đa cho khác hàng, ngân hàng trang bị hệ thống website vô bảo mật, khó để cơng khai thác Tuy nhiên, ngân hàng luôn đối tượng hướng đến kẻ xấu Vì ngân hàng cần phải cập nhật giám sát hệ thống bảo mật thường xuyên Trang 49 CHƯƠNG 4: KẾT LUẬN Qua tìm hiểu phân tích trên, nhận thấy ModSecurity giải pháp tường lửa mã nguồn mở mạnh, phù hợp cho tổ chức có nhu cầu bảo mật ứng dụng web Tổng kết lại, ModSecurity có ưu, nhược điểm sau: Ưu điểm: • Giải pháp triển khai dễ dàng • Có nhiều lựa chọn mơ hình triển khai, phù hợp với nhiều mơ hình mạng • Người quản trị dễ dàng tùy biến, linh hoạt • Có khả phịng chống cơng khai thác lỗ hổng • Chi phí thấp Nhược điểm: • Giao diện khó sử dụng cho việc cấu hình giám sát Ngày nay, ứng dụng web ngày đóng vai trị quan trọng tổ chức Điều trở nên rõ ràng ứng dụng web bị công làm ảnh hưởng nghiêm trọng đến chức hoạt động tổ chức Vì vậy, tổ chức nên trang bị hệ thống WAF để làm nhiệm vụ chuyên trách bảo vệ cho ứng dụng web Các tổ chức tham khảo giải pháp mã nguồn mở giải pháp ModSecurity đề xuất luận văn giải pháp chuyên dụng đến từ hãng bảo mật lớn giới Ngoài ra, việc nắm vững lỗ hổng, cách thức khai thác, cách thức phòng chống giúp người quản trị hiểu nguy tiềm ẩn tổ chức đưa sách cho WAF hợp lý Do hạn chế công cụ kiến thức nên nội dung luận văn chưa thể đầy đủ toàn vấn đề lỗ hổng ứng dụng web Tuy nhiên, luận văn đưa nhìn tổng quan bảo mật web, đề xuất giải pháp áp dụng cho tổ chức có nhu cầu bảo mật web Hướng phát triển Trong thời gian tới, để phát triển thêm cho luận văn, có hướng phát triển tiếp tục sau: • Trước tiên tiếp tục tìm hiểu phát triển thêm ModSecurity Trong đó, tìm hiểu triển khai phần mềm giao diện quản trị cho ModSecurity Việc sử dụng giao diện dịng lệnh gây khó khăn nhầm lẫn cho người quản trị Trang 50 Giải pháp WAF-FLE giao diện quản trị cho ModSecurity Giúp người quản trị dễ dàng vận hành, theo dõi, giám sát hệ thống Hình 5.1: Giao diện WAF-FLE [18] • Sau đó, tìm hiểu giải pháp WAF chuyên dụng đến từ hãng bảo mật lớn giới Imperva, F5, Akamai,… Với tổ chức, doanh nghiệp, ngân hàng lớn giải pháp lựa chọn giải pháp chuyên dụng Yếu tố hiệu cao, ổn định, giao diện gần gũi, dễ dàng quản trị,… điểm mạnh giải pháp Tuy nhiên, tổ chức phải đầu tư tài nhiều nhiều lần so với giải pháp mã nguồn mở Trang 51 TÀI LIỆU THAM KHẢO [1] Christian Folini, Ivan Ristić, 2010, ModSecurity Handbook: The Complete Guide to Securing Your Web Applications [2] The OWASP Foundation, 2014, OWASP Testing Guide vesion 4.0 [3] Diogo Sampaio, Jorge Bernardino, 2017, Evaluation of Firewall Open Source Software [4] Jeremy Druin, 2013, Introduction to the OWASP Mutillidae II Web Pen-Test Training Environment [5] https://www.owasp.org/index.php/Top_10-2017_Top_10 [6] https://www.owasp.org/index.php/Top_10-2017_Application_Security_Risks [7] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x) [8] https://vi.wikipedia.org/wiki/%E1%BB%A8ng_d%E1%BB%A5ng_web [9] https://en.wikipedia.org/wiki/ModSecurity [10] https://vi.wikipedia.org/wiki/SQL_injection [11] https://securitybox.vn/2552/bao-mat-cho-ung-dung-web/ [12] https://techtalk.vn/su-khac-biet-giua-web-site-va-web-application.html [13] https://securitydaily.net/web-security-tuong-lua-ung-dung-web-waf/ [14] https://vn.cystack.net/news/owasp-top-10-rui-ro-bao-mat-ung-dung-2017/ [15] https://vn.cystack.net/news/10-lo-hong-bao-mat-web/ [16] https://whitehat.vn/threads/xml-external-entity-processing.5489/ [17] https://www.liquidweb.com/kb/wordpress-modsecurity-rules/ [18] https://www.kitploit.com/2014/08/waf-fle-v064-opensource-modsecurity.html [19] https://securitybox.vn/2540/an-toan-thong-tin-tai-viet-nam-2017/ Trang 52 ... đặt cho đề tài Nhiệm vụ đề tài tìm hiểu lỗ hổng bảo mật ứng dụng web đề xuất giải pháp WAF để bảo vệ ứng dụng web khỏi lỗ hổng bảo mật Trong đó: Trang [1] Tìm hiểu lỗ hổng bảo mật ứng dụng web. .. Ứng dụng web lỗ hổng bảo mật ứng dụng web : Nghiên cứu sở lý thuyết ứng dụng web lỗ hổng bảo mật ứng dụng web theo đánh giá tổ chức OWASP Chương 3: Đề xuất giải pháp tường lửa ứng dụng web: Tìm. .. muốn phân tích tìm hiểu sâu lỗ hổng ứng dụng web phương thức hoạt động, khả ngăn chặn WAF, học viên lựa chọn đề tài ? ?Tìm hiểu tốn Web an tồn đề xuất giải pháp Firewall cho ứng dụng Web? ?? làm luận