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

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 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 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 luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

Đỗ Đức Nguyên

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

Chuyên ngành: Mạng máy tính và truyền thông dữ liệu

Mục lục

LỜI CAM ĐOAN 3

LỜI CẢM ƠN 4

DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

DANH MỤC CÁC HÌNH VẼ 7

CHƯƠNG 1: MỞ ĐẦU 8

1 Lý do chọn đề tài 8

2 Nhiệm vụ đặt ra cho đề tài 8

3 Hướng tiếp cận và giải quyết 9

4 Bố cục của luận văn 9

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

1 Khái niệm ứng dụng web 11

2 Các lỗ hổng bảo mật phổ biến trong ứng dụng web 11

2.1 Giới thiệu về Open Web Application Security Project (OWASP) 11

2.2 Lịch sử của 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ộ các dữ liệu nhạy cảm – Sensitive Data Exposure 15

2.6 A4 – Thực thể bên ngoài 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 trong 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 tuần tự hóa không an toàn - Insecure Deserialization 17

2.11 A9 – Sử dụng các 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

1 Tại sao cần tường lửa ứng dụng web? 19

2 Đề xuất giải pháp tường lửa mã nguồn mở ModSecurity 19

2.1 Lý do 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 của ModSecurity 21

3 Mô hình triển khai và 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

4 Tìm hiểu về rule 27

5 Thử nghiệm một số kịch bản tấn công khai thác lỗ hổng 28

5.1 Tổng quan kịch bản 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 của một số website cụ thể 43

CHƯƠNG 4: KẾT LUẬN 50

TÀI LIỆU THAM KHẢO 52

LỜI CAM ĐOAN

Tôi xin cam đoan đề tài nghiên cứu của tôi hoàn toàn do tôi tự làm dưới sự hướng dẫn của thầy giáo TS.Phạm Huy Hoàng Những kết quả tìm hiểu và nghiên cứu trình bày trong luận văn là hoàn toàn trung thực và chưa từng được công bố trong bất cứ công trình nào Nếu xảy ra bất cứ điều không đúng như những lời cam đoan trên, tôi xin chịu hoàn toàn trách nhiệm trước Viện và Nhà trường

Ngày 15 tháng 09 năm 2018

Học viên

Đỗ Đức Nguyên

Xin chân thành cảm ơn tất cả!

DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT

WAF Web Application Firewall: Tường lửa ứng dụng web

HTTP (S) Hypertext Transfer Protocol (Secure): Giao thức truyền tải

siêu văn bản (bảo mật) OWASP Open Web Application Security Project: Dự án về 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 nhất theo OWASP

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 giữa người dùng và máy chủ web URL Uniform Resource Locator: Định vị Tài nguyên thống nhất

DANH MỤC CÁC BẢNG

Bảng 3.1 So sánh giữa các giải pháp firewall 22

CHƯƠNG 1: MỞ ĐẦU

1 Lý do chọn đề tài

Thực trạng an toàn thông tin tại Việt Nam ngày càng diễn biến phức tạp và nguy hiểm Các cuộc tấn công mạng có quy mô, mức độ phức tạp và được chuẩn bị một cách kỹ lưỡng Trong đó, các mục tiêu tấn công đang dần chuyển dịch từ các mục tiêu cá nhân, sang các mục tiêu là các tập đoàn kinh tế lớn hay nghiêm trọng hơn là các hệ thống thông tin quan trọng của các quốc gia Hàng loạt các hệ thống website của các Ngân hàng lớn, doanh nghiệp lớn đã bị tấn công gây thiệt hại đáng kể [19]

Thực tế với tình hình hiện nay, các ứng dụng web ngày một nhiều Sự thay đổi chóng mặt của công nghệ đã giúp ứng dụng web được cải tiến nâng cao rất nhiều, và vấn đề bảo mật cho ứng dụng web không ngừng tăng lên Một khi ứng dụng web bị rò rỉ lỗ hổng, các tin tặc sẽ dễ dàng chiếm quyền quản trị web, ứng dụng và phần mềm của công ty Nguyên nhân dẫn đến các ứng dụng web bị rò rỉ thông tin, các nguy cơ về lỗ hổng, là do các đoạn

mã lệnh, mã code không phù hợp trong ứng dụng web Chỉ cần một lỗ hổng, tin tặc cũng

có thể xâm nhập và truy cập vào cơ sở dữ liệu, thông tin và thực hiện các hành vi sai trái như đánh cắp, thay đổi, chỉnh sửa, mã hóa dữ liệu…[11]

Để đối phó với các nguy cơ rủi ro đó, có rất nhiều công cụ, giải pháp được phát triển nhằm mục đích bảo vệ các ứng dụng web khỏi các lỗi bảo mật và các cuộc tấn công, mã độc từ tin tặc.Các giải pháp đó được gọi là tường lửa ứng dụng web (Web Application Firewall – WAF) 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ăng theo dõi các thông tin được truyền qua giao thức http/https giữa trình duyệt của ngườ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ính sá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ưu lượng truy cập ứng dụng web bất thường Đây là điều mà các tường lửa mạng khác không làm được Với mong muốn phân tích và tìm hiểu sâu hơn về các lỗ hổng trong ứng dụng web cũng như phương thức hoạt động, khả năng ngăn chặn của WAF, học viên đã lựa chọn đề tài

“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”

làm luận văn tốt nghiệp của mình

2 Nhiệm vụ đặt ra cho đề tài

Nhiệm vụ của đề tài này là tìm hiểu các lỗ hổng bảo mật trong ứng dụng web và đề xuất một giải pháp WAF để bảo vệ ứng dụng web khỏi các lỗ hổng bảo mật đó Trong đó:

[1] Tìm hiểu các lỗ hổng bảo mật trong ứng dụng web là: tìm hiểu về 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 được đề xuất cần đạt được các nhiệm vụ sau:

- Giải pháp có thể ngăn chặn được tin tặc khai thác các lỗ hổng tiêu biểu

- Giải pháp phải cho phép người quản trị có thể cấu hình chính sách một cách linh hoạt

- Giải pháp phải có khả năng triển khai và áp dụng vào thực tế

3 Hướng tiếp cận và giải quyết

Đầu tiên học viên cần tìm hiểu về danh sách các 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 được đảm bảo là mới nhất khi thực hiện đề tài

Để quá trình tìm hiểu được hiệu quả, việc cài đặt một máy chủ web chứa các lỗ hổng để có thể tiến hành khai thác thử là cần thiết Việc nắm vững các lỗ hổng sẽ là điều kiện tiên quyết để học viên có thể thực hiện nhiệm vụ tiếp theo là đề xuất một giải pháp WAF Trong phạm vi nghiên cứu luận văn, một giải pháp WAF mã nguồn mở là lựa chọn hợp

lý Tuy nhiên, giải pháp vẫn cần phải đáp ứng các nhiệm vụ đã đặt ra tại phần 2 Học viên cần phân tích và chỉ ra sự khác nhau cũng như lợi ích đem lại của hệ thống trước khi và sau khi triển khai WAF

Các nội dụng thực hiện trong đề tài:

- Tìm hiểu các lỗ hổng bảo mật trong ứng dụng web (OWASP Top 10)

- Tìm hiểu, cài đặt, thử nghiệm một máy chủ web chứa các lỗ hổng và một phần mềm

mã nguồn mở WAF ModSecurity

- Xây dựng bộ chính sách ngăn chặn khai thác các lỗ hổng

- Thử nghiệm giải pháp bằng cách khai thác các lỗ hổng và so sánh kết quả trước khi

và sau khi triển khai WAF

4 Bố cục của luận văn

Bố cục luận văn được chia thành 5 chương như sau:

Chương 1: Mở đầu: Mô tả chi tiết về mục tiêu, nhiệm vụ đề tài và hướng tiếp cận Chương 2: Ứng dụng web và các lỗ hổng bảo mật trong ứng dụng web : Nghiên

cứu cơ sở lý thuyết về ứng dụng web và các lỗ hổng bảo mật trong ứng dụng web theo đánh giá của 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 và đề xuất một giải

pháp tường lửa ứng dụng web, bao gồm các nội dung: (1) Giới thiệu giải pháp, (2) Mô hình

triển khai và hướng dẫn cài đặt, (3) Cấu hình chính sách, (4) Thử nghiệm một số kịch bản tấn công khai thác lỗ hổng

Chương 4: Đánh giá kết quả: Đưa ra đánh giá dựa trên kết quả thử nghiệm và đưa ra

kết quả so sánh với nhiệm vụ ban đầu đã đề ra

Chương 5: Kết luận: Đưa ra kết luận, tự nhận xét các ưu điểm và hạn chế, định hướng

phát triển và áp dụng vào thực tế

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

1 Khái niệm ứng dụng web

Trong kỹ thuật phần mềm, một ứng dụng web là một trình ứng dụng mà có thể tiếp cận qua web thông qua mạng như internet hay intranet Ứng dụng web phổ biến nhờ vào sự có mặt vào bất cứ nơi đâu của một chương trình Khả năng cập nhật và bảo trì ứng dụng web

mà không phải phân phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho

sự phổ biến của nó Ứng dụng web được dùng để hiện thực Webmail, bán hàng trực tuyến, đấu giá trực tuyến, wiki, diễn đàn thảo luận, Weblog, MMORPG, Hệ quản trị nội dung, Phần mềm quản lý nguồn nhân lực và nhiều chức năng khác [8]

Tuy nhiên tính tương tác cao của ứng dụng web cũng gây ra nhiều rủi ro về bảo mật Nếu ứng dụng web tồn tại lỗ hổng thì tin tặc có thể xâm nhập và thực hiện các hành vi xấu như giả mạo, đánh cắp thông tin, tấn công phá hoại, gián đoạn dịch vụ, … Do đó, các kĩ thuật tấn công vào một hệ thống mạng ngày nay đang dần tập trung vào những lỗ hổng trong quá trình tạo ứng dụng của những nhà phát triển Web hơn là tấn công trực tiếp vào

hệ thống mạng, hệ điều hành Phần tiếp theo chúng ta cùng đi tìm hiểu về các lỗ hổng phổ biến trong ứng dụng web

2 Các lỗ hổng bảo mật phổ biến trong ứng dụng web

2.1 Giới thiệu về Open Web Application Security Project (OWASP)

OWASP là một tổ chức bao gồm các chuyên gia bảo mật hàng đầu thế giới, chuyên cung cấp các thông tin về những ứng dụng và rủi ro đặt ra một cách trực tiếp, khách quan và thực tế nhất, đặc biệt là ứng dụng web Định kỳ, OWASP tiến hành đánh giá và công bố danh sách Top 10 các rủi ro bảo mật ứng dụng lớn nhất, được gọi là OWASP Top 10 [14] Mục tiêu chính của OWASP Top 10 là để hướng dẫn cho những người tham gia vào xây dựng hệ thống, quản trị hệ thống, bảo mật hệ thống hiểu về các lỗ hổng và hậu quả của nó

có thể gây ra Dựa vào phương pháp đánh giá rủi ro bao gồm các tiêu chí như khả năng khai thác, mức độ phổ biến, khả năng phát hiện, ảnh hưởng,…

Hình 2.2: Các tiêu chí đánh giá rủi ro lỗ hổng [6]

Tiếp theo chúng ta cùng tìm hiểu lịch sử của OWASP TOP 10

2.2 Lịch sử của OWASP Top 10

OWASP được thành lập vào năm 2001 Năm 2003, tổ chức lần đầu tiên đưa ra danh sách 10 lỗ hổng tiêu biểu Gọi là OWASP Top 10 – 2003 Danh sách bao gồm như sau:

• A1 2003 - Unvalidated Input

• A2 2003 - Missing Functional Level Access Control

• A3 2003 - Broken Authentication and Session Management

• A4 2003 - Cross Site Scripting (XSS)

• A5 2003 - Buffer Overflows

• A6 2003 - Injection

• A7 2003 - Information Leakage and Improper Error Handling

• A8 2003 - Sensitive Data Exposure

• A9 2003 - Remote Administration Flaws

• A10 2003 - Security Misconfiguration

Tuy nhiên, một năm sau đó tổ chức có tiến hành cập nhật danh sách Top 10 để phù hợp với hiện trạng của an toàn thông tin trên thế giới thời điểm đó Gọi là OWASP Top 10 –

2004 Từ năm 2004, OWASP tiến hành đánh giá và bình chọn danh sách 3 năm 1 lần (đến năm 2013) Danh sách OWASP Top 10 – 2004 bao gồm:

• A1 2004 - Unvalidated Input

• A2 2004 - Broken Access Control

• A3 2004 - Broken Authentication and Session Management

• A4 2004 - Cross Site Scripting

• A5 2004 - Buffer Overflow

• A6 2004 - Injection Flaws

• A7 2004 - Improper Error Handling

• A8 2004 - Insecure Storage

• A9 2004 - Application Denial of Service

• A10 2004 - Insecure Configuration Management

Ta nhận thấy rằng việc thay đổi giữa 2004 và 2003 là không nhiều Chủ yếu là thay đổi các tên gọi cho phù hợp Ba năm sau, OWASP tiến hành đánh giá và đưa ra danh sách Top

10 – 2007 Danh sách như sau:

• A1 2007 - Cross Site Scripting (XSS)

• A2 2007 - Injection Flaws

• A3 2007 - Malicious File Execution

• A4 2007 - Insecure Direct Object Reference

• A5 2007 - Cross Site Request Forgery (CSRF)

• A6 2007 - Information Leakage and Improper Error Handling

• A7 2007 - Broken Authentication and Session Management

• A8 2007 - Insecure Cryptographic Storage

• A9 2007 - Insecure Communications

• A10 2007 - Failure to Restrict URL Access

Đã có sự thay đổi rõ rệt so với năm 2004 Các lỗ hổng A1 2004 - Unvalidated Input, A5

2004 - Buffer Overflow, A9 2004 - Application Denial of Service, A10 2004 - Insecure Configuration Management đã được thay thế bằng các lỗ hổng mới: A3 2007 - Malicious File Execution, A5 2007 - Cross Site Request Forgery (CSRF), A9 2007 - Insecure Communications và A10 2007 - Failure to Restrict URL Access Sau đó 3 năm, OWASP tiến hành đánh giá và đưa ra danh sách Top 10 – 2010 Danh sách như sau:

• A1 2010 - Injection

• A2 2010 - Cross-Site Scripting (XSS)

• A3 2010 - Broken Authentication and Session Management

• A4 2010 - Insecure Direct Object References

• A5 2010 - Cross-Site Request Forgery (CSRF)

• A6 2010 - Security Misconfiguration

• A7 2010 - Insecure Cryptographic Storage

• A8 2010 - Failure to Restrict URL Access

• A9 2010 - Insufficient Transport Layer Protection

• A10 2010 - Unvalidated Redirects and Forwards

So với 2007, OWASP đã bỏ đi 2 lỗ hổng là A3 2007 - Malicious File Execution và A6

2007 - Information Leakage and Improper Error Handling Đồng thời bổ sung 2 lỗ hổng mới là A6 2010 - Security Misconfiguration và A10 2010 - Unvalidated Redirects and Forwards Sau đó 3 năm, OWASP tiếp tục tiến hành đánh giá và đưa ra danh sách Top 10 – 2013 Danh sách như sau:

• A6 2013 - Sensitive Data Exposure

• A7 2013 - Missing Function Level Access Control

• A8 2013 - Cross-Site Request Forgery (CSRF)

• A9 2013 - Using Known Vulnerable Components

• A10 2013 - Unvalidated Redirects and Forwards

Không có khác biệt nhiều so với năm 2010 OWASP đã tiến hành gộp A7 2010 - Insecure Cryptographic Storage với A9 2010 - Insufficient Transport Layer Protection thành A6 2013 - Sensitive Data Exposure Đồng thời tách A6 2010 - Security Misconfiguration thành A5 2013 - Security Misconfiguration và A9 2013 - Using Known Vulnerable Components Sau đó 4 năm, OWASP tiếp tục đánh giá theo chu kỳ mới và đưa

ra danh sách Top 10 – 2017 Đây cũng là danh sách mới nhất tính đến thời điểm hiện tại Chi tiết như sau:

• A1 2017 - Injection

• A2 2017 - Broken Authentication

• A3 2017 - Sensitive Data Exposure

• A4 2017 - XML External Entities (XXE)

• A5 2017 - Broken Access Control

• A10 2017 - Insufficient Logging&Monitoring

OWASP đã tiến hành gộp A4 2013 - Insecure Direct Object References và A7 2013 - Missing Function Level Access Control thành A5 2017 - Broken Access Control Sau đó

bỏ đi A8 2013 - Cross-Site Request Forgery (CSRF) và A10 2013 - Unvalidated Redirects and Forwards Đồng thời bổ sung A4 2017 - XML External Entities (XXE) và A10 2017 - Insufficient Logging&Monitoring Phần tiếp thheo, chúng ta sẽ đi tìm hiểu và phân tích chi tiết hơn về các lỗ hổng trong danh sách OWASP Top 10 – 2017

2.4 A2 – Phá vỡ tính xác thực – Broken Authentication

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

3 (dễ dàng) 2 (phổ biến) 2 (trung bình) 3 (nghiêm trọng)

Khi các chức năng của ứng dụng được thực hiện không chính xác, tin tặc có thể dễ dàng xâm nhập, ăn cắp thông tin tài khoản, mật khẩu và khai thác các lỗ hổng khác bằng cách

sử dụng các chứng chỉ đã đánh cắp Tài khoản mỗi người dùng cá nhân nên là duy nhất, không bị trùng lặp dưới bất kì hình thức nào Nếu không có bất kì sự quản lý cần thiết nào thì tin tặc có thể lẻn vào, ngụy trang thành người dùng để ăn cắp thông tin tài khoản, mật khẩu và sử dụng cho những lần truy cập sau này [14,15]

2.5 A3 – Để lộ các dữ liệu nhạy cảm – Sensitive Data Exposure

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

2 (trung bình) 3 (rộng rãi) 2 (trung bình) 3 (nghiêm trọng)

Việc tiếp xúc dữ liệu nhạy cảm xảy ra khi các kiểm soát bảo mật, giúp tin tặc có thể ăn cắp thông tin tài khoản, mật khẩu, địa chỉ hay bất cứ thông tin có giá trị nào khác Vì vậy, các ứng dụng cần đảm bảo truy cập được xác thực và dữ liệu đã được mã hóa [14,15] Sai lầm phổ biến chủ yếu là không mã hóa các dữ liệu cần được mã hóa Các tổ chức cần xác định đâu là dữ liệu quan trọng của mình và tiến hành mã hóa nó

2.6 A4 – Thực thể bên ngoài XML - XML External Entities (XXE)

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

2 (trung bình) 2 (phổ biến) 3 (dễ dàng) 3 (nghiêm trọng)

Khai báo external entity tronng XML chính là điểm mấu chốt trong kỹ thuật tấn công XXE Kỹ thuật tấn công này dựa vào việc cho phép khai báo External Entity trong phần kiểu tài liệu của dữ liệu XML Tin tặc có thể khai báo một thực thể để đọc nội dung của file bất kỳ trong hệ thống nếu trình phân tích XML (parser) được cấu hình không tốt [16]

2.7 A5 – Phá vỡ kiểm soát truy cập – Broken access control

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

2 (trung bình) 2 (phổ biến) 2 (trung bình) 3 (nghiêm trọng)

Kiểm soát truy cập nhằm mục đích kiểm soát người dùng được ủy quyền được phép hay không được phép làm gì trong một ứng dụng và để thiết lập quyền kiểm soát truy cập một cách hợp lí, ứng dụng phải đảm bảo rằng nó đang nghiêm túc thực hiện kiểm tra ủy quyền

và xác thực hợp lệ để xác định người dùng được đặc quyền, thực tế là những người dùng Internet ngẫu nhiên Việc bị khai thác thường dẫn đến việc tiết lộ thông tin trái phép, sửa đổi dữ liệu hoặc thực hiện chức năng nào đó ngoài giới hạn của người dùng [14,15]

2.8 A6 – Sai sót trong cấu hình an ninh – Security Misconfiguration

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

3 (dễ dàng) 3 (rộng rãi) 3 (dễ dàng) 2 (trung bình)

Một cơ chế an ninh tốt cần phải định nghĩa những hiệu chỉnh về an ninh và triển khai nó cho các ứng dụng, khuôn mẫu, máy chủ ứng dụng, máy chủ web, máy chủ dữ liệu và các ứng dụng nền tảng Tất cả các thiết lập nên được định nghĩa, thực hiện và bảo trì bởi rất nhiều thứ không được triển khai với thiết lập an toàn mặc định Các hiệu chỉnh cũng bao gồm cập nhật phần mềm và những thư viện được sử dụng bởi ứng dụng Người phát triển

và nhà quản trị mạng cần phải làm việc cùng nhau để đảm bảo rằng từng lớp được hiệu

chỉnh một cách đúng đắn Những công cụ quét tự động cũng có thể hữu ích trong việc phát hiện những bản vá lỗi bị thiếu, sai sót trong cấu hình hoặc sử dụng những tài khoản mặc định, những dịch vụ không cần thiết

2.9 A7 - Thực thi mã script – Cross-Site Scripting (XSS)

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

Các ứng dụng cho phép người dùng nhập dữ liệu vào mà không có toàn quyền kiểm soát

dữ liệu ra có nguy cơ bị tấn công XSS rất cao Một cuộc tấn công XSS thành công có thể gây thiệt hại nghiêm trọng cho các trang web và có khả năng kéo người dùng vào các trang web khác (thường chứa nhiều mã độc hơn) [14,15]

2.10 A8 – Giải tuần tự hóa không an toàn - Insecure Deserialization

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

1 (khó) 2 (trung bình) 2 (trung bình) 3 (nghiêm trọng)

Giải tuần tự hóa không an toàn Insecure Deserialization là một lỗ hổng xảy ra khi dữ liệu không tin cậy được sử dụng để lạm dụng sự logic của một ứng dụng, gây ra tấn công

từ chối dịch vụ (DoS) hoặc thậm chí thực thi mã tùy ý khi nó được giải tuần tự hóa Tuy nhiên, việc khai thác lỗ hổng này khá là khó khăn Một số công cụ có thể phát hiện lỗ hổng này, nhưng con người vẫn luôn luôn phải phân tích và xác nhận kết quả Người ta hy vọng rằng dữ liệu phổ biến cho loại lỗ hổng này sẽ tăng lên khi công cụ được phát triển để giúp xác định và giải quyết nó

2.11 A9 – Sử dụng các thành phần có lỗ hổng đã biết – Using Components with

Known Vulnerabilities

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

2 (trung bình) 3 (rộng rãi) 2 (trung bình) 2 (trung bình)

Việc sử dụng các thành phần có lỗ hổng đã biết là vô cùng nguy hiểm vì các lỗ hổng đã được công bố sẽ luôn kèm theo các hướng dẫn để khai thác Nếu tổ chức của bạn vô tình gặp phải lỗi này, các tin tặc có thể dễ dàng tấn công theo các hướng dẫn có sẵn

2.12 A10 – Không đủ nhật ký giám sát – Insufficient Logging & Monitoring

Khả năng khai khác Mức độ phổ biến Khả năng phát hiện Ảnh hưởng

2 (trung bình) 3 (rộng rãi) 1 (khó) 2 (trung bình)

Lỗ hổng không đủ nhật ký giám sát là nền tảng của gần như mọi sự cố lớn Những kẻ tấn công dựa vào sự thiếu giám sát và phản ứng kịp thời để đạt được mục tiêu của họ mà không bị phát hiện Một chiến lược để xác định xem bạn có giám sát đầy đủ hay không là kiểm tra nhật ký sau thử nghiệm thâm nhập Các hành động của người kiểm tra nên được ghi lại đầy đủ để hiểu những thiệt hại mà kẻ tấn công có thể đã gây ra Hầu hết các cuộc tấn công thành công bắt đầu với thăm dò lỗ hổng Việc cho phép các thăm dò tiếp tục như vậy có thể tăng khả năng khai thác thành công lên gần 100%

Trên đây chúng ta đã tìm hiểu về 10 lỗ hổng phổ biến nhất trong ứng dụng web Những

lỗ hổng đều là nguy hiểm, sẽ gây ra thiệt hại lớn nếu tổ chức bị khai thác Các thông tin về

lỗ hổng được công khai rộng rãi cho tất cả mọi người Tin tặc thì luôn nắm vững và hiểu

về nó Nếu người quản trị không trang bị một kiến thức đủ tốt thì rất khó có thể chống lại những đợt tấn công khai thác từ các tin tặc Phần tiếp theo chúng ta cùng tiến hành khai thác thử một số lỗ hổng để hiểu rõ hơn; đồng thời tiến hành tìm hiểu về một giải pháp có thể ngăn chặn các tấn công vào lỗ hổng này Giải pháp đó là tường lửa ứng dụng web – Web Application Firewall (WAF)

CHƯƠNG 3: ĐỀ XUẤT GIẢI PHÁP TƯỜNG LỬA ỨNG DỤNG WEB

1 Tại sao cần tường lửa ứng dụng web?

Qua phân tích ở trên chúng ta thấy được rằng các ứng dụng web luôn tồn tại rất nhiều lỗ hổng Người quản trị thì luôn nghĩ rằng hệ thống của tổ chức đang ổn, đang an toàn, đang vận hành tốt Tuy nhiên, chỉ khi hệ thống bị tấn công hoặc khai thác họ mới nhận ra rằng

hệ thống đã tồn tại rất nhiều lỗ hổng Thông thường, các tường lửa mạng thường hoạt động

ở lớp 4 (tầng giao vận) nên không thể ngăn chặn được các tấn công khai thác

Vì vậy, chúng ta có thể nhận thấy rằng việc xây dựng một tường lửa WAF để bảo vệ cho các máy chủ ứng dụng web của các tổ chức, doanh nghiệp là vô cùng cần thiết Tin tặc luôn hiểu về các lỗ hổng và luôn biết cách làm thế nào để tiến hành khai thác Nếu hệ thống của bạn đang không được bảo vệ bởi một WAF, rất có khả năng trong tương lai hệ thống của bạn sẽ là mục tiêu để các tin tặc tấn công Hậu quả mà nó mang lại thì vô cùng lớn, có khi phải trả giá bằng cả một sự phát triển của doanh nghiệp

Phần tiếp theo chúng ta cùng phân tích và tìm hiểu một giải pháp WAF cụ thể Trong phạm vi đồ án, đối tượng mà chúng ta hướng tới là một ứng dụng mã nguồn mở ModSecurity

2 Đề xuất giải pháp tường lửa mã nguồn mở ModSecurity

2.1 Lý do lựa chọn giải pháp mã nguồn mở

Các giải pháp mã nguồn mở luôn mang lại những lợi ích tuyệt vời cho các tổ chức Khái niệm mã nguồn mở không còn xa lạ gì với các tổ chức, nhất là những tổ chức luôn quan tâm đến vấn đề bản quyền và chi phí Chúng ta cùng phân tích một số lợi ích mà phần mềm

mã nguồn mở mang lại:

• Chi phí thấp: Phần mềm mã nguồn mở thường là miễn phí, nơi có một cộng đồng

luôn đóng góp và chia sẻ kiến thức Các giải pháp chuyên dụng từ các hãng bảo mật lớn thường sẽ tiêu tốn của tổ chức rất nhiểu tiền

• Tính đa dạng: Các phần mềm mã nguồn mở luôn có một cộng đồng cùng đóng góp

và phát triển các ý tưởng Ngoài ra tính tùy biến dễ dàng cũng làm cho các phần mềm mã nguồn mở trở lên vô cùng đa dạng

• Khả năng tùy biến và mở rộng cao: Việc các mã nguồn luôn được công khai sẽ

giúp cho người quản trị có thể dễ dàng tùy biến cho phù hợp với tổ chức của mình

• Tính năng hoặc bug được cập nhật liên tục: Việc có đội ngũ đóng góp đông đảo

sẽ mang lại lợi thế cho các phần mềm mã nguồn mở khi luôn luôn được cập nhật

những ý tưởng mới, tính năng mới Các lỗi được phát hiện bởi một cá nhân hoặc

một tổ chức nào đó cũng nhanh chóng được chia sẻ rộng rãi

• Dễ dàng tiếp cận, nghiên cứu và tìm hiểu: Ưu điểm cuối cùng là việc vô cùng dễ

dàng tiếp cận và nghiên cứu Khác với các giải pháp chuyên dụng luôn luôn rất chặt chẽ trong việc bản quyền và phần mềm, mọi người đều có thể tiếp cận phần mềm

mã nguồn mở Các tài liệu liên quan cũng luôn được chia sẻ rộng rãi với tất cả mọi

người

Ở trên chúng ta đã đi vào phân tích những ưu điểm, lợi ích mà phần mềm mã nguồn mở mang lại Tuy nhiên, nó vẫn còn những điểm hạn chế là thao tác và sử dụng khó Người quản trị cần có kỹ năng chuyên môn để có thể vận hành hệ thống tốt Do vậy giải pháp mã nguồn mở thường phù hợp với các doanh nghiệp vừa và nhỏ hoặc muốn tiết kiệm chi phí Trong phạm vi đồ án, với lợi thế là dễ dàng tiếp cận và nghiên cứu, giải pháp tường lửa mã nguồn mở được lựa chọn Phần tiếp theo chúng ta cùng tìm hiểu về các giải pháp tưởng lửa

mở nguồn mở

2.2 Các giải pháp tường lửa mã nguồn mở

Có rất nhiều các tường lửa ứng dụng web mã nguồn mở trên thế giới Các tường lửa ứng dụng web đã góp phần không nhỏ vào việc ngăn chặn các tấn công web trên toàn thế giới Tiêu biểu nhất là ModSecurity, WebCastellum và Ironbee

• ModSecurity: ModSecurity là một tường lửa ứng dụng web mã nguồn mở được

phát triển bởi nhóm Trustwave’s SpiderLabs Các tính năng chính của ModSecurity

là lọc, lọc dựa trên các cụm từ thông dụng, hỗ trợ URL mã hóa, ngăn chặn tấn công null bbyte,… ModSecurity cũng là một ứng dụng hỗ trợ ghi nhật ký đầy đủ

• WebCastellum: WebCastellum là một tường lửa ứng dụng web mã nguồn mở phát

triển bằng Java Nó có thể bảo vệ hệ thống chống lại một số đe dọa như SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF),… Phiên bản ổn định cuối cùng là 1.8.3, được phát hành theo Eclipse WebCasellum có các tính năng chính như URL mã hóa, ngăn chặn CSRF, phát hiện tấn công statefull,… WebCastellum tiến hành giám sát các luồng yêu cầu và phản hồi, thực hiện các hành động dựa theo các rule đã định sẵn

• Ironbee: Ironbee là một tưởng lửa ứng dụng web mã nguồn mở phân phối theo BSD

và Apache 2.0 Ironbee là một phần mềm rất đáng tin cậy và có khả năng mở rộng với nhiều tính năng: triển khai tùy chỉnh, linh hoạt, phân tích các luồng traffic vào

ra, giám sát theo hành vi (IP, phiên, người dùng,…), dò quét lỗ hổng,… Ironbee

cũng cung cấp khả năng tích hợp với các thiết bị bảo mật khác như firewall và trao đổi dữ liệu

Tổng quan, ta có bảng so sánh giữa 3 giải pháp firewall tiêu biểu

ModSecurity WebCastellum Ironbee

Lọc theo regular expression Có

Ngăn chặn tấn công null byte Có

Bảng 3.1: So sánh giữa các giải pháp firewall [3]

Qua bảng so sánh ở trên, chúng ta có thể nhận thấy rằng giải pháp ModSecurity là tốt nhất trong các giải pháp Ngoài ra giải pháp ModSecurity cũng dễ dàng cài đặt và triển khai vào mô hình mạng của tổ chức Tính mềm dẻo, linh hoạt trong chính sách cũng là một trong những ưu điểm để ModSecurity luôn là sự lựa chọn của các nhà quản trị mạng Trong phần tiếp theo chúng ta sẽ cùng tìm hiểu chi tiết về giải pháp

2.3 Giới thiệu ModSecurity

ModSecurity là một tường lửa ứng dụng web mã nguồn mở Phiên bản đầu tiên được phát hành vào tháng 11 năm 2002, nhưng cần thêm vài tháng nữa trước khi công cụ trở nên hoàn chỉnh Những người quan tâm bắt đầu tìm hiểu về ModSecurity và sự phổ biến của

nó bắt đầu tăng lên Ban đầu ModSecurity được thiết kế như một module cho Apache HTTP Server, sau đó nó đã phát triển để cung cấp một loạt các yêu cầu của HTTP và khả năng lọc phản ứng cùng với các tính năng bảo mật khác trên một số nền tảng khác nhau bao gồm Apache HTTP Server, Microsoft IIS và NGINX

2.4 Hoạt động của ModSecurity

Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 giai đoạn (phase), tại mỗi giai đoạn ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các tấn công, khai thác

Hình 3.1: Các pha trong hoạt động của ModSecurity [1]

Giai đoạn 1: Request headers

Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin Mục đích chính của giai đoạn này là cho phép đánh giá các yêu cầu trước khi thực hiện các xử lý tốn kém tiếp theo trong HTTP body Ví dụ, ModSecurity sẽ không phân tích cú pháp phần body yêu cầu XML theo mặc định, nhưng bạn có thể hướng dẫn nó làm như vậy bằng cách đặt các quy tắc thích hợp vào giai đoạn 1

Giai đoạn 2: Request body

Đây là giai đoạn phân tích yêu cầu chính và diễn ra ngay sau khi một yêu cầu hoàn chỉnh

đã được nhận và xử lý Các rule trong giai đoạn có tất cả các dữ liệu yêu cầu có sẵn theo ý của chúng

Giai đoạn 3: Response headers

Giai đoạn này tiến hành phản hồi sau khi tiêu đề phản hồi khả dụng, nhưng trước khi đọc nội dung phản hồi Các rule cần quyết định có nên kiểm tra giai đoạn phản hồi HTTP body nên chạy trong giai đoạn này

Giai đoạn 4: Response body

Đây là giai đoạn chính của quá trình phản hồi Đến thời điểm này giai đoạn bắt đầu, nội dung phản hồi sẽ được đọc, với tất cả dữ liệu có sẵn cho các rule đưa ra quyết định của chúng

Giai đoạn 5: Logging

Đây là giai đoạn khá là đặc biệt Đầu tiên, đó là giai đoạn duy nhất mà bạn không thể chặn Vào thời điểm giai đoạn này chạy, giao dịch sẽ kết thúc, do đó, bạn có thể thực hiện quá trình ghi lại nhật ký nhưng thực tế là nó đã xảy ra Các rule trong giai đoạn này được chạy để kiểm soát cách ghi nhật ký được thực hiện

3 Mô hình triển khai và hướng dẫn cài đặt

3.1 Mô hình triển khai

ModSecurity hỗ trợ hai mô hình triển khai là: tích hợp vào web server (embedded) và reverse proxy Không có mô hình nào là hoàn hảo; mỗi mô hình sẽ phù hợp với từng hệ thống cụ thể Có những ưu điểm và nhược điểm cho cả hai mô hình:

Mô hình tích hợp vào web server

ModSecurity là một tường lửa ứng dụng web có thể được triển khai như một phần của

cơ sở hạ tầng máy chủ web hiện tại của bạn với điều kiện máy chủ web của bạn là Apache, IIS7 hoặc Nginx Phương pháp triển khai này có những ưu, nhược điểm nhất định:

Ưu điểm:

• Không có thay đổi đối với hệ thống mạng hiện tại Chúng ta chỉ mất ít thười gian

để cài đặt ModSecurity vào các máy chủ web hiện tại Và bởi vì nó được thiết kế hoàn toàn thụ động theo mặc định, chúng ta có thể tự do triển khai nó theo từng bước và chỉ sử dụng các tính năng cần thiết Chúng ta cũng dễ dàng gỡ bỏ hoặc tắt

• Không có vấn đề với nội dung được mã hóa hoặc nén (luồng HTTPS) Nhiều hệ thống IDS gặp khó khăn trong việc phân tích lưu lượng SSL Đây không phải là vấn đề đối với ModSecurity vì nó được định vị để hoạt động khi lưu lượng truy cập

đã được giải mã và giải nén

Nhược điểm:

• Chiếm tài nguyên của web server Khi hoạt động, dù ít hay nhiều ModSecurity cũng

sẽ chiếm một phần tài nguyên của web server Nếu các chính sách, quy tắc thiết lập nhiều, không được tối ưu, thì tài nguyên sẽ bị chiếm nhiều hơn Nếu hệ thống của bạn là nhỏ, có thể bạn không cần phải quan tâm đến yếu tố này Tuy nhiên nếu hệ thống lớn, cần tính toán tài nguyên kỹ trước khi triển khai Nếu cần, hãy bổ sung thêm tài nguyên cho web server

• Nếu hệ thống của bạn có nhiều hơn một web server, việc triển khai và cài đặt ModSecurity sẽ phải thực hiện trên từng máy chủ Việc quản lý chính sách, quy tắc cũng khó khăn hơn Khi cần cấu hình hoặc cập nhật chính sách, người quản trị cần phải thực hiện trên tất cả các server

Hình 3.2: Mô hình tích hợp vào web server (embedded)

Mô hình reverse proxy

Trong mô hình triển khai ModSecurity như một reverse proxy thì chức năng WAF được phân tách độc lập với máy chủ web Phương pháp triển khai này có những ưu, nhược điểm như sau:

Ưu điểm:

• Không ảnh hưởng đến máy chủ web Việc phân tách độc lập với máy chủ web sẽ đảm bảo ModSecurity không gây ảnh hưởng, không chiếm tài nguyên của máy chủ web Người quản trị có thể chuẩn bị cài đặt, cấu hình trước, áp dụng thử nghiệm

cho một số máy chủ thử nghiệm trước khi đặt vào hệ thống

• Quản lý dễ dàng, đồng nhất Nếu hệ thống của bạn có nhiều hơn một web server, thì mô hình này là phù hợp Việc quản lý chính sách, quy tắc là dễ dàng Khi cần cấu hình hoặc cập nhật chính sách, người quản trị chỉ cần thực hiện trên máy chủ ModSecurity và khi đó tất cả máy chủ web đằng sau đều sẽ được bảo vệ

Nhược điểm:

• Có thay đổi đối với hệ thống mạng hiện tại Việc đặt thêm máy chủ ModSecurity vào trước các máy chủ web sẽ làm thay đổi mô hình hệ thống mạng hiện tại Các thiết lập mạng như IP, routing, cũng thay đổi theo Hệ thống web có thể bị downtime một thời gian khi tiến hành tích hợp Người quản trị cần lên kế hoạch chi

tiết trước khi tiến hành triển khai để không gây ảnh hưởng cho dịch vụ web

• Có điểm yếu nút thắt cổ chai (single point) Việc tất cả các luồng web trước khi đi vào các máy chủ web phải đi qua máy chủ ModSecurity sẽ tạo ra nhút thắt cổ chai trong hệ thống Nếu máy chủ ModSecurity gặp sự cố, tất cả dịch vụ web của các máy chủ sẽ phải dừng lại Do vậy cần khi thiết kế cần tính đến việc đảm bảo tính sẵn sàng cao (High Availability – HA) Nếu một máy chủ ModSeccurity gặp sự cố, máy chủ còn lại sẽ đảm nhiệm để dịch vụ web không bị gián đoạn