TÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITY TÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITY TÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITYTÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB APPLICATION FIREWALLS) VÀ MODSECURITY
Trang 1BỘ THÔNG TIN VÀ TRUYỀN THÔNG HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
HỌC PHẦN: AN TOÀN PHẦN MỀM
ĐỀ TÀI: TÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB
APPLICATION FIREWALLS) VÀ MODSECURITY
GIẢNG VIÊN HƯỚNG DẪN: TS ĐỖ XUÂN CHỢ
HÀ NỘI, 2020
Trang 2MỤC LỤC
PHÂN CÔNG CÔNG VIỆC
Phùng Chí Công: Tổng quan về tiêu chuẩn Owasp top ten, tìm hiểu vài trò của
tường lửa
Nguyễn Thành Nam: Web Application Firewall (Tổng quan và công dụng)
Tìm hiểu về modSecurity và vai trò của rule trong modSecurity
Nguyễn Ngọc Quý: Tìm hiểu cơ chế về ModSecurity, tìm hiểu rule và vai trò
của rule, tích hợp vào modsecurity vào xampp
Nguyễn Văn Hòa: Demo Set up server ubuntu, tích hợp Modsecurity để phòng
chống SQL Injection và XSS Reflected vào apache2 của server ubuntu.Viết luật cho modsecurity
Trang 3LỜI MỞ ĐẦU
Tường lửa ứng dụng web không được phổ biến như tường lửa mạng, nhưng
nó đã được đề cập đến trong các tin tức, bài báo và hội thảo bảo mật hiện nay Các doanh nghiệp đã chấp nhận sử dụng công nghệ này bởi vì nó nâng cao an toàn web một cách đáng kể Nhưng cấu hình, triển khai và duy trì công nghệ mới này không hề đơn giản Để triển khai chúng thành công, bạn cần phải hiểu
rõ các hoạt động của ứng dụng một cách đầy đủ và cấu hình các quy tắc tường lửa một cách cẩn thận Hơn nữa, chi phí để mua được sản phẩm thương mại rất
là đắt đỏ, chúng tôi khuyến khích bắt đầu sử dụng các sản phẩm mã nguồn mở, chẳng hạn ModSecurity, do đó bạn có thể đưa ra quyết định, nếu giải pháp này
là thích hợp với ngân sách và môi trường của bạn
Trong bài giới thiệu này, Modsecurity sẽ đực sử dụng để minh họa làm thế nào bảo mật ứng dụng web sử dụng WAF Modsecurity bảo vệ các ứng dụng web từ nhiều cuộc tấn công và cho phép giám sát lưu lượng HTTP với sự can thiệp không nhiều của cơ sở hạ tầng hiện có Nó là một module mã nguồn mở của ứng dụng máy chủ web Apache và nó đã được bảo trì bởi SpiderLabs, Trustwave Từ khi nó là một sản phẩm mã nguồn mở, nó mặc nhiên là miễn phí
và nhiều người dùng sử dụng đã góp phần cải thiện và duy trì sản phẩm này
Trang 4CHƯƠNG 1: TỔNG QUAN VỀ TIÊU CHUẨN
OWASP TOP TEN
OWASP (Open Web Application Security Project) là một dự án phi lợi nhuận, tập trung vào việc cải thiện tính bảo mật của ứng dụng web Thành viên của dự án là các cá nhân, tổ chức, chuyên gia… cùng đóng góp các mã nguồn, công cụ hỗ trợ kiểm tra lỗ hổng ứng dụng web
Năm 2010, cộng đồng OWASP xuất bản tài liệu “Tài liệu hướng dẫn kiểm tra ứng dụng Web” phiên bản 3(OWASP Testing Guide v3:
http://www.owasp.org/index.php OWASP_Testing_Project) Tài liệu liệt kê và phân nhóm các lỗ hổng bảo mật đã được biết đến trong ứng dụng web Đông thời nội dung của tài liệu này mô tả các dự án mà cộng đồng này phát triển, bao gồm dự án WAF Mod Security
OWASP phân loại lỗ hổng thành 10 nhóm chính:
1.1 A1-Injection
Nhóm này bao gồm các lỗ hổng như SQL Injection, OS command Injection, LDAP Injection,… các lỗ hổng trong nhóm này cho phép hacker truy cập hoặc chèn các kí tự giả vào hệ thống qua các câu truy vấn dữ liệu
Ta có ví dụ như sau: Có một form đăng nhập
Trang 5Nếu như người dùng không đăng nhập bình thường mà thêm vào dấu “,” hoặc dấu “.” Thì đoạn code sẽ bị lỗi ngay Hoặc họ có thể sửa thành câu truy vấn luônluôn đúng như sau:
Trang 61.2 A2-Cross Site Scripting (XSS)
XSS xuất hiện khi 1 ứng dụng web cho phép người dùng nhập các dữ kiệu vào
mà không thông qua kiểm duyệt nội dung, những dữ liệu này sẽ tương tác trực tiếp những người dùng khác cùng sử dụng website Nguy cơ tạo ra là hacker có thể chèn các mã kịch bản như HTML, Javascript,… nhắm ăn cắp Session
Cookie, thay đổi giao diện hoặc chuyển hướng đến trang có mã độc khác
Chi tiết các bước được miêu tả như sau:
Trang 7Ví dụ : Một người đăng một đoạn script đơn giản như sau :
Lúc đó sau khi nhấn nút Search thì script được nhập sẽ được thực hiện:
Trang 8Như các bạn đã thấy lệnh search đã được thực thi Điều này cho thấy lỗ hổng XSS là khá rõ ràng
1.3 A3-Broken Authenitication and Session Management
Phân nhóm này liệt kê các nguy cơ về chức năng xác thực và quản lí phiên (session management) trong ứng dựng web Thông thường, các chức năng này không được triển khai tốt, cho phép hacker vượt qua cơ chế kiểm duyệt người dùng
Trang 91.4 A4-Insecure Direct Object References
Nguy cơ trong nhóm này thường được gặp trong các trường hợp các lập trình viên sử dụng tham chiếu đến đến một tập tin, thư mục hoặc các truy vấn
database trong mã nguồn Nếu các tham chiếu này không được quản lí chặt chẽ thì việc truy cập dữ liệu trái phép từ bên ngoài là rất nguy hiểm
Ví dụ : Trong file ta có thể tìm được một đoạn code như sau :
Thay vì sử dụng đối tượng current_user lấy giá trị ID người dùng từ phiên của người dùng và thường có khả năng chống giả mạo, ID người dùng được lấy từ tham số yêu cầu (id người dùng trong URL RESTful) Ngoài ra, ngay cả trong phiên, User ID phải đủ ngẫu nhiên và các phiên được lưu trữ theo cách liên tục (ActiveRcord) so với sử dụng lược đồ phiên xác thực được mã hóa Base64 / HMAC
1.5 A5-Cross Site Request Forgery (CSRF)
Một cuộc tấn công CSRF yêu cầu một người dùng đã đăng nhập Tiếp theo, hacker sẽ chèn các mã kịch bản đã được dựng sẵn vào nội dung trang web nhắmthực thi một hành động bất hợp pháp với quyền của người dùng đã đăng nhập.Một ví dụ cho thấy hacker có thể hack từ một tệp PHP như sau:
Trang 10Khi người dùng ấn vào xem nguồn họ sẽ thấy rằng một nhập ẩn danh được đặt tên là 34 Sau đó họ tạo một biểu mẫu của riêng mình gửi các Post yêu cầu với nhiều id khác nhau đến www.your-domain.com/delete/user để xóa tất cả
người dùng khỏi hệ thống của bạn Máy chủ web sẽ chấp nhận yêu cầu mặc dù không đúng miền riêng của nó
Tệ hơn nữa hình ảnh trong e-mail/trang web sẽ tự động gọi:
1.6 A6-Security Misconfiguration
Các yêu cầu về bảo mật ứng dụng web cũng bao gồm việc cấu hình và triển khai
hệ thống, ứng dụng webserver (Apache, Nginx, Tenginx,…), cơ sở dữ liệu (MySQL, Oracle,…), hệ điều hành (Linuxm Windows) Tất cả công việc thiết lập môi trường cho ứng dụng web hoạt động cấn được lên kế hoạch theo dõi, kiểm tra, cập nhật thường xuyên nhằm giảm thiểu nguy cơ hệ thống bị khai thác
Trang 111.7 A7-Insecure Cryptographic Storage
Rất nhiều ứng dụng web không quan tâm đên việc bảo vệ dữ liệu nhạy cảm như thông tin thẻ tín dụng, SSN và các thông tin xác thực Việc hacker thu thập dữ liệu nhạy cảm không được mã hóa (encrypt) hoặc băm (hash) sẽ tạo ra mối nguyhiểm lớn cho những website cho phép giao dịch thông qua thuong mại điện tử
1.8 A8- Failure to Restrict URL Access
Hầu hết các ứng dụng thông thường thực hiện kiểm soát việc truy cập thông quaURL (thông qua cơ chế Rewrite) Việc giới hạn quyền truy cập vào các tập tin, rhuw mục nhạy cảm là cần thiết trong một số tình huống, việc kiểm soát này không được quản lí đầy đủ tạo nguy cơ xâm nhập trái phép vào ứng dụng (ví dụ:thư việc fckditor thường có thể truy cập trực tiếp không cần xác thực)
1.9 A9-Insufficient Transport Layer Protection
Thông tin xác thực được truyền qua môi trường mạng truyền dẫn không bảo mật
sẽ tạo ra nguy cơ dữ liệu bị nghe len Việc này cũng tương tự nếu như ứng dụng
Trang 12sử dụng các chứng chỉ số (certificate) với các khóa yếu (weak key), thuật toán
mã hóa yếu (weak algorithms) hoặc chứng chỉ đã hết hạn sử dụng (exprired)
1.10 A10-Unvalidated Redirects and Forwards
Các ứng dụng web thường chuyển hướng người dùng đến những trang web hoặc URL khác nhau Hacker có thể lợi dụng cơ chế này để chuyển hướng người dùng đến nhứng website chứa phầm mềm độc hại hoặc trang đăng nhập giả
Dự dán OWASP ModSecurity Core Rule Set (CRS) sử dụng bản quyền ASL v2.Các tập rule trong CRS được phân loại theo tiêu chuẩn OWASP để có thể bảo
vệ máy chủ web theo từng loại tấn công Các rule này hoạt động tốt với phiên bản ModSecurity 2.5 trở lên
Trang 13CHƯƠNG 2: WEB APPLICATION FIREWALLS
2.1. Giới thiệu tổng quan về web application firewalls
Tường lửa ứng dụng web ( web application firewalls – web ) được thiết
kể để bảo vệ web application tránh khỏi các lỗi bảo mật và các cuộc tấn công từhacker WAF như là một cái khiên, như là một cái lá chắn để bảo vệ webapplication chạy trên giao thức HTTP ( giao thức không an toàn)
WAF được đặt ở phía trước của web application, nó sẽ giám sát các hoạtđộng ứng dụng và cảnh bảo hoặc block traffic nếu phát hiện ra nguy hiểm Mụcđích là để nắm bắt các cuộc tấn công vào ứng dụng web như là : SQL injection,xss,…
Trong những năm gần đây, xu hướng tấn công vào ứng dụng web đangngày càng trở nên phổ biến Các kỹ thuật tấn công được sử dụng chủ yếu là:cross-site scripting, SQL injection, và nhiều các kỹ thuật khác… tất cả các kỹthuật này đều nhắm vào lớp ứng dụng trong mô hình OSI Các lỗ hổng trongứng dụng web chủ yếu xảy ra do người lập trình không kiểm tra kỹ các tham sốhay ký tự do người dùng nhập vào để tương tác với ứng dụng web Để khắcphục các lỗi trên ứng dụng web, người lập trình cần hiểu và viết được các đoạn
mã ở mức độ bảo mật nhất, tuy nhiên việc viết đoạn mã sao cho “bảo mật” nhấtthường khó thực hiện, bởi các lẽ sau: Thứ nhất, các đơn vị lập trình thườngkhông có hoặc thiếu đội ngũ chuyên trách về việc kiểm tra và sửa lỗi bảo mật
mã nguồn ứng dụng Thứ hai, đôi khi áp lực phải hoàn thành ứng dụng webtrong thời gian nhanh khiến cho các ứng dụng web được đưa vào vận hành màkhông qua các khâu kiểm thử Thứ ba, việc dùng các công cụ kiểm tra lỗi web
tự động đôi khi cũng không tìm ra hết các lỗi khi được thực hiện bằng tay Dovậy, việc bảo mật một ứng dụng web đó là một quá trình phòng thủ theo chiềusâu bao gồm các khâu phát triển, vận hành, xây dựng cơ sở hạ tầng bảo vệ tốt và
có một đội ngủ chuyên trách vấn đề bảo mật riêng cho web
Trang 14Tường lửa ứng dụng web (Web Application Firewall – WAF) là một giảipháp nhằm bảo vệ cho ứng dụng web tránh khỏi các lỗi bảo mật nói trên WAF
là một thiết bị phần cứng hoặc phần mềm được cài lên máy chủ có chức năngtheo dõi các thông tin được truyền qua giao thức http/https giữa trình duyệt củangười dùng và máy chủ web tại lớp 7 Một WAF có khả năng thực thi các chínhsách bảo mật dựa trên các dấu hiệu tấn công, các giao thức tiêu chuẩn và các lưulượng truy cập ứng dụng web bất thường Đây là điều mà các tường lửa mạngkhác không làm được
Hình 2 1 Mô hình một hệ thống tường lửa ứng dụng Web (WAF)
Trang 152.2. Mô hình bảo mật negative và positive
WAFs so sánh dấu hiệu của 1 cuộc tấn công với chính sách an toàn của ứng dụng cho ứng dụng web đang được bảo vệ để cảnh báo hoặc ngăn chặn sự
là nguy hại Đôi khi cũng có các WAF cung cấp cả 2 mô hình trên, tuy nhiên thông thường WAF chỉ cung cấp 1 trong 2 mô hình Với mô hình Postitive thì đòi hỏi nhiều cấu hình và tùy chỉnh, còn mô hình Negative chủ yếu dựa vào khảnăng học hỏi và phân tích hành vi của lưu lượng mạng
Tóm lại :
Mô hình positive:
• Bạn cho phép lưu lượng hợp lệ đi qua, tất cả lưu lượng còn lại chị chặn
• Ưu điểm: Độ bảo mật, an toàn cao hơn Negative
• Khuyết điểm: Yêu cầu phải có sẵn danh sách hợp lệ (Whilelisting) để không nhầm lẫn trong việc chặn những người truy cập hợp pháp
Mô hình negative:
• Bạn chủ động chẵn những lưu lượng bất hợp pháp, tất cả lưu lượng còn lại cho phép đi qua
• Ưu điểm: dễ dàng triển khai, thực hiện trong hấu hết trường hợp
• Khuyết điểm: Dễ dàng bị tấn công khi người dùng bất hợp pháp không
có trong danh sách bị chặn
Trang 162.3. Mô hình triển khai
WAF có thể hoạt động ở các mô hình riêng biệt, dưới đây là một số mô hình:
Reverse Proxy: đây là chức năng được sử dụng phổ biến khi triển khai
WAF Trong mô hình này, WAF giám sát tất cả các lưu lượng đi đến ứng dụngweb, sau đó thay vì cho các địa chỉ IP bên ngoài gửi yêu cầu trực tiếp đến máychủ web thì WAF đứng ra làm trung gian để gửi các yêu cầu này đến máy chủweb thay cho trình duyệt gốc rồi gửi trả lại kết quả cho các địa chỉ IP kia Môhình này có nhược điểm là tạo ra độ trễ khi kết nối từ trình duyệt đến ứng dụngweb
Hình 2 2 Reverse Proxy
Layer 2 Brigde: Ở mô hình này, WAF đứng giữa tường lửa mạng và máychủ web, nhưng hoạt động giống như một thiết bị Switch ở lớp 2 Mô hình nàygiúp mạng hoạt động với hiệu năng cao và mạng thay đổi không đáng kể, tuynhiên nó lại không thể cung cấp các dịch vụ cao cấp khác mà các mô hình WAF
Trang 17Hình 2 3 Layer 2 Brigde
Out-of-Band: Ở mô hình này, WAF không trực tiếp đứng giữa tường lửa
mạng và mày chủ web như 2 mô hình kia nữa Nó sẽ nhận được một bản copycủa các lưu lượng đi đến ứng dụng web thông qua cổng giám sát trên thiết bịmạng Nhược điểm của mô hình này là khả năng block traffic còn rất hạn chế do
nó chỉ gửi cái gói tin TCP- reset để làm gián đoạn traffic
Hình 2 4 Out-of-Band
Server Resident: là một phần mềm được cài đặt trong máy chủ web Nó
có thể hoạt động như là một ứng dụng độc lập hoặc như là một web server in
Trang 18plug-Hình 2 5 Server Resident
Internet Hosted / Cloud : đây là một mô hình mới tuy nhiên nó càng
ngày càng trở lên phổ biến Mô hình này sử dụng công nghệ điện toán đám mây
để thực hiện các giải pháp WAF Nó hoạt động giống như tùy chọn proxy ngược– public DNS được cấu hình để trỏ tới nhà cung cấp đám mây, sau đó tạo một kết nối khác với thuộc tính web
Trang 192.4. Công dụng của WAF
2.4.1. Bảo vệ ứng dụng
Cách tốt nhất để bảo mật một ứng dụng là phát triển nó bằng cách khônngoan, đó là sử dụng vòng đời phát triển ứng dụng (SDLC) trong SDLC mộtvấn đề bảo mật càng được phát hiện sớm thì chi phí giải quyết càng rẻ hơn.Ngược lại, vấn đề bảo mật càng bị phát hiện muộn hơn thì chi phí giải quyếtcàng cao hơn - trường hợp xấu nhất là một lỗ hổng bảo mật được tìm thấy khiứng dụng đang hoạt động WAF có thể giảm thời gian và chi phí để khắc phụcnguy cơ lỗ hổng trực tiếp
Hình 2 7 Vòng đời phát triển ứng dụng (SDLC)
Trang 202.4.2. Bảo vệ ứng dụng đã lỗi thời và COTS (Protecting legacy & COTS
application)
Nói chung, các công ty có quyền truy cập vào mã nguồn của các ứng dụng đượcchính công ty đó phát triển Mặc dù việc tự phát triển ứng dụng là rất đắt đỏ, nhưng công ty có thể tự khắc phục lỗ hổng bảo mật bằng cách sửa mã nguồn Nếu ứng dụng là "chương trình đóng gói sẵn " (commercial off the shelf -
COTS) hoặc ứng dụng lỗi thời thì khả năng của công ty để giải quyết các vấn đềtrong mã nguồn có thể là từ rất ít cho đến không thể Đối với các ứng dụng lỗi thời, công ty đó có thể không còn có developers cho ứng dụng hoặc thậm chí không có developers nào biết cách viết code bằng ngôn ngữ mà ứng dụng ban đầu được phát triển Đối với một ứng dụng COTS, công ty có thể để tiết lộ vấn
đề cho bên thứ ba, nhưng dưới quyền kiểm soát của nhà cung cấp “Với việc giảm quyền truy cập vào ứng dụng web - và tùy thuộc vào tầm quan trọng và phức tạp của nó - thì những lợi ích xuất phát từ việc sử dụng WAF tăng nhanh
Sử dụng WAF thường xuyên sẽ dẫn đến hạn chế những vấn đề phát sinh cho mức độ an ninh cần thiết
2.4.3. Quản lí lỗ hổng
Việc bảo vệ là một phần không thể thiếu trong quá trình quản lý các lỗhổng Theo Nicolett, "việc bảo vệ nên được sử dụng để bảo vệ tài sản dễ bị tổnthương cho đến khi giảm thiểu hoàn thành" (2005, tr 5) Khi một lỗ hổng đượcphát hiện trong một ứng dụng, một chữ ký WAF có thể được tạo ra để chặn cáccuộc tấn công chống lại nó Cho dù ứng dụng được phát triển trong nhà hay làmột ứng dụng COTS, điều này bảo vệ nó trong khi mã dễ bị tổn thương được cốđịnh hoặc một tổ chức chờ một nhà cung cấp cung cấp bản cập nhật Điều nàyđược gọi là bản vá ảo
Trang 21Hình 2 8 Quá trình quản lý lỗ hổng bảo mật
2.4.4. Compliance sự tuân thủ
"Sự Tuân thủ" là một lý do lớn cho việc WAFs được sử dụng Tiêu chuẩnbảo mật dữ liệu thẻ thanh toán (PCI DSS) là tiêu chuẩn bảo mật thông tin chocác tổ chức xử lý thông tin chủ thẻ cho thẻ ghi nợ và thẻ tín dụng Được xácđịnh bởi Hội đồng tiêu chuẩn bảo mật PCI (SSC), tiêu chuẩn được tạo ra để tăngkiểm soát xung quanh dữ liệu của chủ thẻ nhằm giảm gian lận thẻ tín dụng dotiếp xúc với dữ liệu đó Các tổ chức chấp nhận, lưu trữ, xử lý hoặc truyền dữliệu thẻ tín dụng phải tuân thủ PCI DSS PCI DSS phiên bản 1.2 có thêm WAFnhư là một sự thay thế cho đweb application vulnerability assessments trongnăm 2008 Hiện tại ở trong phiên bản 3, PCI DSS requirement 6.6 cho biết(2013, trang 59):
Đối với các ứng dụng web công khai, giải quyết các mối đe dọa và lỗhổng mới và đảm bảo các ứng dụng này được bảo vệ khỏi các cuộc tấn công đãbiết bằng một trong các phương pháp sau: