Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa modsecurity và iptables

Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

MỤC LỤC
DANH MỤC CÁC HÌNH VẼ................................................................................................3
LỜI NÓI ĐẦU........................................................................................................................4
Chương 1: TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ CÁC VẤN ĐỀ AN NINH BẢO
MẬT LIÊN QUAN................................................................................................................5
1.1. Tổng quan về Website.................................................................................................5
1.2. Tổng quan về dịch vụ Web (Web Service).................................................................6
1.3. Các nguy cơ đối với ứng dụng web...........................................................................10
1.3.1. Tấn công kịch bản liên trang..................................................................................12
1.3.2. Tấn công tiêm trích lỗ hổng ..................................................................................12
1.3.3. Thực thi các tập tin độc hại ...................................................................................14
1.3.4. Tham chiếu đối tượng trực tiếp không an toàn .....................................................14
1.3.5. Tấn công giả mạo truy vấn liên trang ....................................................................15
1.3.6. Rò rỉ thông tin và xử lý lỗi không đúng ................................................................16
1.3.7. Vỡ quá trình quản lý xác thực và phiên ................................................................17
1.3.8. Mã hóa đĩa lưu trữ không an toàn .........................................................................18
1.3.9. Truyền thông không an toàn...................................................................................19
1.3.10. Lỗi khi giới hạn truy cập URL.............................................................................20
Chương 2: CÁC GIẢI PHÁP ĐẢM BẢO AN TOÀN ỨNG DỤNG WEB (WEB
APPLICATION)..................................................................................................................21
2.1. Lập trình an toàn........................................................................................................21
2.1.1. Kiểm tra hợp lệ đầu vào.........................................................................................22
2.1.2. Bảo vệ hệ thống tệp tin...........................................................................................23
2.1.3. Bảo vệ cơ sở dữ liệu...............................................................................................24
2.1.4. Bảo vệ phiên làm việc............................................................................................28
2.1.5. Bảo vệ chống lại các lỗ hổng XSS.........................................................................31
2.1.6. Bảo vệ chống lại việc gửi lên (post) không hợp lệ.................................................32
2.1.7. Bảo vệ chống lại các giả mạo truy vấn liên trang (CSRF).....................................35
2.2. Sử dụng các thiết bị và phần mềm bảo mật cho ứng dụng web................................37

2.2.1. Giải pháp sử dụng tường lửa..................................................................................37
2.2.1.1.Giải pháp với thiết bị tường lửa của CheckPoint............................................37
2.2.1.2. Giải pháp với thiết bị tường lửa ứng dụng web của Imperva..........................44
2.2.1.3. Sử dụng các phần mềm tường lửa...................................................................47
2.2.2. Sử dụng thiết bị phát hiện và phòng chống xâm nhập (IDS/IPS)..........................48
Chương 3: TRIỂN KHAI, XÂY DỰNG HỆ THỐNG BẢO VỆ MÁY CHỦ WEB CỦA
HỌC VIỆN KỸ THUẬT MẬT MÃ DỰA TRÊN MODSECURITY VÀ IPTABLES.......51
3.1. Giới thiệu mô hình hệ thống của Học viện Kỹ thuật Mật Mã...................................51
3.2. Các nguy cơ đối với hệ thống của Học viện Kỹ thuật Mật Mã.................................53
3.3. Xây dựng mô hình bảo vệ.........................................................................................54
3.4. Giới thiệu tường lửa Iptables và ModSecurity..........................................................56
3.4.1. Tường lửa Iptables..................................................................................................56
3.4.1.1. Khái niệm........................................................................................................56
3.4.1.2. Xử lí gói trong IPtables...................................................................................57
3.4.1.3. Những Modun Kernel cần thiết.......................................................................60
3.4.2. Tường lửa ModSecurity.........................................................................................61
3.4.2.1. Khái niệm........................................................................................................61
3.4.2.2. Các khả năng của ModSecurity.......................................................................61
3.4.2.3. Nguyên lý hoạt động.......................................................................................61
3.4.2.3. Quá trình xử lý................................................................................................63
3.4.2.4. File cấu hình....................................................................................................64
3.4.2.5. Ghi nhật ký (Logging).....................................................................................65
Học viện Kỹ thuật Mật Mã

1


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables
3.5. Triển khai phần mềm tường lửa ModSecurity kết hợp với Iptables để bảo vệ hệ
thống Web........................................................................................................................67

3.5.1. Cài đặt ModSecurity và Iptables trực tiếp trên máy chủ Web...............................68
3.5.2. Xây dựng tập luật đối với ModSecurity.................................................................69
3.5.3. Xây dựng tập luật đối với tường lửa Iptables.........................................................72
Chương 4: KẾT LUẬN, ĐÁNH GIÁ VÀ ĐỊNH HƯỚNG PHÁT TRIỂN.........................73
TÀI LIỆU THAM KHẢO....................................................................................................75
PHỤ LỤC.............................................................................................................................76

Học viện Kỹ thuật Mật Mã

2


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

DANH MỤC CÁC HÌNH VẼ
Hình 1.1: Mô hình hoạt động của SOAP................................................................................9
Hình 1.2: Kiến trúc dịch vụ hướng đối tượng........................................................................9
Hình 2.1: Liệt kê 1 – Tải xuống một tập tin.........................................................................24
Hình 2.2: Liệt kê 2 – Kiểm tra hợp lệ với các ký tự trong tên tập tin..................................24
Hình 2.3: Liệt kê 3 - Thi hành một lệnh SQL......................................................................26
Hình 2.4: Liệt kê 4 - Liệt kê bằng kiểm tra hợp lệ...............................................................27
Hình 2.5: Liệt kê 5 - Lưu trữ dữ liệu trong phiên.................................................................29
Hình 2.6: Liệt kê 6 - Các tập tin phiên trong thư mục /tmp.................................................29
Hình 2.7: Liệt kê 7 – Nội dung của một tập tin phiên..........................................................29
Hình 2.8: Liệt kê 8 – Ví dụ về hàm session_set_save_handler().........................................30
Hình 2.9: Liệt kê 9 – Biểu mẫu để nhập vào văn bản..........................................................31
Hình 2.10: Liệt kê 10 - showResults.php.............................................................................31
Hình 2.11: Liệt kê 11 – Mẫu văn bản đầu vào độc hại.........................................................32
Hình 2.12: Liệt kê 12 – Một biểu mẫu an toàn hơn.............................................................32
Hình 2.13: Liệt kê 13 – Một biểu mẫu để xử lý văn bản......................................................33

Hình 2.14: Liệt kê 14 - Một biểu mẫu để thu nhập dữ liệu..................................................33
Hình 2.15: Liệt kê 15 – Một biểu mẫu với dữ liệu không hợp lệ.........................................34
Hình 2.16: Liệt kê 16 – Sử dụng một thẻ bài biểu mẫu một lần.........................................35
Hình 2.17: Liệt kê 17 - Một thí dụ của CSRF......................................................................35
Hình 2.18: Liệt kê 18 – Lấy dữ liệu từ $_REQUEST..........................................................36
Hình 2.19: Liệt kê 19 - Lấy dữ liệu chỉ từ $_POST.............................................................36
Hình 2.20: Giải pháp CheckPoint UTM cho danh nghiệp vừa và nhỏ................................38
Hình 2.21: Giải pháp CheckPoint UTM cho doanh nghiệp lớn...........................................39
Hình 2.22: Giải pháp CheckPoint UTM cho ứng dụng Web Internet/Intranet....................41
Hình 2.23: Giải pháp CheckPoint UTM cho ứng dụng Web-hosting..................................43
Hình 2.24: Tính năng của hệ thống Imperva WAF..............................................................45
Hình 2.25: So sánh Imperva WAF với IPS..........................................................................47
Hình 3.1: Mô hình mạng của Học viện kỹ thuật mật mã.....................................................52
Hình 3.2: Máy chủ web tích hợp tường lửa ứng dụng.........................................................54
1 - Sử dụng một thiết bị tường lửa hệ thống để bảo vệ chung cả 2 vùng (vùng máy chủ và
vùng người sử dụng bên trong):...........................................................................................54
Để giới hạn các dịch vụ công khai ra bên ngoài internet.....................................................54
Ngăn ngừa các tấn công từ bên ngoài vào vùng máy chủ và vùng người sử dụng bên trong
..............................................................................................................................................54
Ngăn ngừa các tấn công từ vùng Internal vào vùng máy chủ..............................................54
Ghi nhật ký các luồng truy cập vào hệ thống máy chủ........................................................54
Quản lý quá trình VPN của người quản trị, người dùng từ bên ngoài internet vào bên trong
..............................................................................................................................................54
2 - Sử dụng thêm một thiết bị phát hiện và phòng chống xâm nhập (IDS/IPS) để bổ trợ cho
thiết bị tường lửa, đồng thời bảo vệ tốt hơn cho vùng máy chủ bên trong để ngăn chặn các
các hình thức tấn công như:..................................................................................................55
Các cuộc tấn công từ chối dịch vụ (DOS/DDOS) vào hệ thống máy chủ...........................55
Các cuộc tấn công vào các giao thức như HTTP, HTTPs, FTP, DNS, SMTP…................55
3 - Sử dụng một tường lửa ứng dụng web để bảo vệ hệ thống website được tốt hơn (do
những hạn chế của thiết bị IPS không thể phân tích được các yêu cầu HTTP nên không thể

ngăn chặn được các tấn công như SQL Injection, XSS, CSRF, …):...................................55
Học viện Kỹ thuật Mật Mã

3


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables
Hình 3.3: Kiến trúc Netfilter/Iptables...................................................................................57
Hình 3.4: Tổng quan về việc lọc và xử lý gói trong iptables...............................................58
Hình 3.5: Một ví dụ về đường đi của gói dữ liệu.................................................................59
Hình 3.6: Quá trình xử lý của ModSecurity.........................................................................63
Hình 3.7: Cấu hình modsecurity trong httpd.conf................................................................69

LỜI NÓI ĐẦU
Hiện nay công nghệ thông tin phát triển, rất nhiều cá nhân hay tổ chức
có nhu cầu xây dựng cho mình một website riêng với mục đích giải trí, thư
giãn, quảng bá sản phẩm, thương hiệu. Nếu như trước đây, việc xây dựng một
website riêng là một vấn đề rất khó, đòi hỏi người lập trình phải có nhiều kiến
thức sâu và rộng, tuy nhiên vấn đề bảo mật website lại chưa được quan tâm
đúng mức. Nhưng đến nay, nhiều tổ chức đã nghiên cứu và cung cấp các giải
pháp giúp cho mỗi cá nhân, tổ chức có thể xây dựng website riêng, và vấn đề
bảo mật được đặt lên hàng đầu. Dự án về kiểm thử các lỗ hổng của ứng dụng
web (Open Web Application Security Project – OWASP) đã tập hợp các nhà
kiểm thử để đi tìm ra các lỗ hổng trong ứng dụng web và đã đưa ra 10 tổn
thương nghiêm trọng đối với ứng dụng web. Đồng thời đưa ra các giải pháp
để phòng chống các tấn công như SQL Injection, XXS, Directory
Traversal…. Trên cơ sở của dự án này, các tổ chức, các công ty đã xây dựng
lên tường lửa ứng dụng web (Web Application Firewall – WAF) để bảo vệ hệ
thống máy chủ web như sản phẩm Imperva, CheckPoint hay ModSecurity.
Trong đó Imperva và Checkpoint là sản phẩm thương mại, còn ModSecurity

là một sản phầm nguồn mở. Tuy ModSecurity là một sản phầm nguồn mở, chỉ
làm nhiệm vụ ngăn chặn một số dạng tấn công nhằm vào Web và cơ sở dữ
liệu, còn những tấn công đi theo con đường khác như tận dụng lỗ hổng từ
Học viện Kỹ thuật Mật Mã

4


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

những dịch vụ khác, hay tấn công DoS, DDoS thì ModSecurity làm việc chưa
hiệu quả. Do đó trong đồ án này em sẽ nghiên cứu để kết hợp 2 tưởng lửa
nguồn mở ModSecurity và Iptables để bảo vệ cho hệ thống máy chủ web của
Học viện Kỹ thuật Mật Mã nhằm chống lại các hình thức tấn công phổ biến.
Em xin chân thành cảm ơn KS. Nguyễn Hồng Thịnh và thầy giáo
ThS.Vũ Đình Thu trong thời gian qua đã tận tình hướng dẫn em hoàn thành
đồ án tốt nghiệp này.
Sinh viên

Chương 1: TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ CÁC VẤN
ĐỀ AN NINH BẢO MẬT LIÊN QUAN
1.1. Tổng quan về Website
Website là tập hợp của rất nhiều trang web - một loại siêu văn bản (tập
tin dạng HTML hoặc XHTML) trình bày thông tin trên mạng Internet- tại một
địa chỉ nhất định để người xem có thể truy cập vào xem. Trang web đầu tiên
người xem truy cập từ tên miền thường được gọi là trang chủ (homepage),
người xem có thể xem các trang khác thông qua các siêu liên kết (hyperlinks).
Đặc điểm tiện lợi của website: thông tin dễ dàng cập nhật, thay đổi,
khách hàng có thể xem thông tin ngay tức khắc, ở bất kỳ nơi nào, tiết kiệm
chi phí in ấn, gửi bưu điện, fax, thông tin không giới hạn (muốn đăng bao

nhiêu thông tin cũng được, không giới hạn số lượng thông tin, hình ảnh...) và
không giới hạn phạm vi khu vực sử dụng (toàn thế giới có thể truy cập).
Một website thông thường được chia làm 2 phần: giao diện người dùng
(front-end) và các chương trình được lập trình để website hoạt động (backend). Giao diện người dùng là định dạng trang web được trình bày trên màn
Học viện Kỹ thuật Mật Mã

5


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

hình của máy tính của người xem (máy khách) được xem bằng các phần mềm
trình duyệt web như Internet Explorer, Firefox,... Tuy nhiên ngày nay người
xem có thể xem website từ các thiết bị điện tử khác như điện thoại di động,
PDA,...Việc trình bày một website phải đảm bảo các yếu tố về thẩm mỹ đẹp,
ấn tượng; bố cục đơn giản, dễ hiểu và dễ sử dụng, các chức năng tiện lợi cho
người xem. Đặc biệt ngày nay, website trở nên sống động với những hiệu ứng
đa dạng của hình ảnh và chữ kết hợp với âm thanh.
Phần Back-end là phần lập trình của website lưu trữ trên máy chủ
(Server). Sự khác nhau ở phần lập trình back-end của website làm phân ra 2
loại website: Website tĩnh và website động.
- Website động (Dynamic website) là website có cơ sở dữ liệu, được
cung cấp công cụ quản lý website (Admin Tool) để có thể cập nhật thông tin
thường xuyên, quản lý các thành phần trên website. Loại website này thường
được viết bằng các ngôn ngữ lập trình như PHP, Asp.net, JSP, Perl,..., quản trị
Cơ sở dữ liệu bằng SQL hoặc MySQL,...
- Website tĩnh do lập trình bằng ngôn ngữ HTML theo từng, không có
cơ sở dữ liệu và không có công cụ quản lý thông tin trên website. Ta phải biết
kỹ thuật thiết kế trang web (thông thường bằng các phần mềm như FrontPage,
Dreamwaver,...) khi muốn thiết kế hoặc cập nhật thông tin của những trang

web này.
Trước đây, chưa có một bộ tiêu chuẩn nào được định ra cho việc trình
bày trang web dẫn đến những khó khăn như sự thiếu tương thích giữa các
trình duyệt, không tương thích với các thiết bị truy cập khác không phải máy
tính. Chính vì vậy, tổ chức W3C đã xây dựng Dự án chuẩn hóa Web (Web
Standard) nhằm thiết lập một số chuẩn chung nhất cho các công nghệ, ngôn
ngữ sử dụng trong việc thiết kế Web. Dự báo trong một tương lai gần, website
sẽ trở nên thân thiện với người dùng khi có những tương tác tùy biến theo nhu
cầu của mỗi người.
1.2. Tổng quan về dịch vụ Web (Web Service)

Học viện Kỹ thuật Mật Mã

6


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Dịch vụ web là sự kết hợp các máy tính cá nhân với các thiết bị khác,
các cơ sở dữ liệu và các mạng máy tính để tạo thành một cơ cấu tính toán ảo
mà người sử dụng có thể làm việc thông qua các trình duyệt mạng.
Bản thân các dịch vụ này sẽ chạy trên các máy phục vụ trên nền
Internet chứ không phải là các máy tính cá nhân, do vậy có thể chuyển các
chức nǎng từ máy tính cá nhân lên Internet. Người sử dụng có thể làm việc
với các dịch vụ thông qua bất kỳ loại máy nào có hỗ trợ web service và có
truy cập Internet, kể cả các thiết bị cầm tay. Do đó các web service sẽ làm
Internet biến đổi thành một nơi làm việc chứ không phải là một phương tiện
để xem và tải nội dung.
Điều này cũng sẽ đưa các dữ liệu và các ứng dụng từ máy tính cá nhân
tới các máy phục vụ của một nhà cung cấp dịch vụ web. Các máy phục vụ này

cũng cần trở thành nguồn cung cấp cho người sử dụng cả về độ an toàn, độ
riêng tư và khả nǎng truy nhập.
Các máy phục vụ ứng dụng sẽ là một phần quan trọng của các web
service bởi vì thường thì các máy phục vụ này thực hiện các hoạt động ứng
dụng phức tạp dựa trên sự chuyển giao giữa người sử dụng và các chương
trình kinh doanh hay các cơ sở dữ liệu của một tổ chức nào đó.
Một giao diện lập trình ứng dụng (Application Programming Interface API) là một giao diện mà một hệ thống máy tính hay ứng dụng cung cấp để
cho phép các yêu cầu dịch vụ có thể được tạo ra từ các chương trình máy tính
khác, và/hoặc cho phép dữ liệu có thể được trao đổi qua lại giữa chúng.
Chẳng hạn, một chương trình máy tính có thể (và thường là phải) dùng các
hàm API của hệ điều hành để xin cấp phát bộ nhớ và truy xuất tập tin. Nhiều
loại hệ thống và ứng dụng hiện thực API, như các hệ thống đồ họa, cơ sở dữ
liệu, mạng, dịch vụ web, và ngay cả một số trò chơi máy tính. Đây là phần
mềm hệ thống cung cấp đầy đủ các chức năng và các tài nguyên mà các lập
trình viên có thể rút ra từ đó để tạo nên các tính năng giao tiếp người - máy
như: các trình đơn kéo xuống, tên lệnh, hộp hội thoại, lệnh bàn phím và các
cửa sổ. Một trình ứng dụng có thể sử dụng nó để yêu cầu và thi hành các dịch
vụ cấp thấp do hệ điều hành của máy tính thực hiện. Hệ giao tiếp lập trình
Học viện Kỹ thuật Mật Mã

7


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

ứng dụng giúp ích rất nhiều cho người sử dụng vì nó cho phép tiết kiệm được
nhiều thời gian tìm hiểu các chương trình mới, do đó khích lệ mọi người dùng
nhiều ứng dụng hơn.
Một số nhà quan sát ngành công nghiệp này cho rằng web service
không thực sự là một khái niệm mới và phản ánh một phần không nhỏ khái

niệm mạng máy tính vốn đã trở nên quen thuộc trong nhiều nǎm qua. Web
service chủ yếu dựa trên một lời gọi thủ tục từ xa không chặt chẽ mà có thể
thay thế các lời gọi thủ tục từ xa chặt chẽ, đòi hỏi các kết nối API phù hợp
đang phổ biến hiện nay. Dịch vụ web sử dụng XML chứ không phải C hay
C++ để gọi các quy trình.
Tuy nhiên các chuyên gia khác lại cho rằng web service là một dạng
API dựa trên phần mềm trung gian, có sử dụng XML để tạo phần giao diện
trên nền Java 2 (J2EE) hay các server ứng dụng .NET. Giống như các phần
mềm trung gian, web service sẽ kết nối server ứng dụng với các chương trình
khách hàng.
Dịch vụ Web được đặc trưng bới một giao diện lập trình ứng dụng
(API) hay một giao diện lập trình ứng dụng Web (Web API) được truy cập
thông qua HTTP (Hypertext Tranfer Protocol) và được thực thi trên một hệ
thống lưu trữ từ xa với các dịch vụ được yêu cầu. Dịch vụ Web có xu hướng
rơi vào hai trường hợp là Big Web Services và RESTful Web Services.
“Big Web Services” sử dụng các thông điệp XML (Extensible Markup
Language) dùng để biểu thị cho giao thức truy cập đối tượng đơn giản
(SOAP – Simple Object Access Protocol) và đã được phổ biến ở các doanh
nghiệp truyền thống. Trong hệ thống như vậy, có một thiết bị dùng để đọc các
miêu tả của hệ thống bởi các lời để nghị của dịch vụ được viết bởi ngôn ngữ
miêu tả dịch vụ Web (Web Services Description Language – WSDL). Sau đó
không cần một yêu cầu từ SOAP, nhưng đó là điều kiện đầu tiên ở máy khách
có thể tự động dựa trên các hệ mã Java hay .Net.

Học viện Kỹ thuật Mật Mã

8


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Hình 1.1: Mô hình hoạt động của SOAP
WEB API là một phát triển trong dịch vụ Web (một tên gọi khác là
WEB 2.0) và đã không sử dụng SOAP mà dựa trên Representational (REST)
thông qua thông tin liên lạc. Dịch vụ REST không yêu cầu XML hay SOAP.
Web APIs cho phép kết hợp nhiều dịch vụ web trong một ứng dụng mới gọi
là mashups (Web Applicaiton Hybrid - Ứng dụng web hỗn hợp).

Hình 1.2: Kiến trúc dịch vụ hướng đối tượng
Khi được sử dụng trong bối cảnh phát triển web , web API thường là
một định nghĩa tập các Hypertext Transfer Protocol (HTTP) yêu cầu cùng với
một định nghĩa về cấu trúc của tin nhắn phản ứng, thường được diễn tả trong

Học viện Kỹ thuật Mật Mã

9


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

một định dạng Extensible Markup Language (XML) hoặc JavaScript Object
Notation (JSON).
Khi chạy các dịch vụ web chính, mỗi dịch vụ con có thể được coi là tự
trị. Người sử dụng không kiểm soát được các dịch vụ này. Ngoài ra các dịch
vụ web là không đáng tin cậy; nhà cung cấp dịch vụ có thể loại bỏ, thay đổi
hoặc cập nhật dịch vụ của họ mà không đưa ra thông báo cho người dùng. Độ
tin cậy và sửa lỗi cũng không được hỗ trợ; lỗi lầm có thể xảy ra trong quá
trình thực hiện các yêu cầu. Xử lý ngoại lệ trong bối cảnh các dịch vụ web
vẫn là một vấn đề nghiên cứu mở.
Các W3C định nghĩa một “dịch vụ web” như là "một hệ thống phần

mềm được thiết kế để hỗ trợ tương thích máy với máy đang tương tác trên
một mạng. Nó có một giao diện được mô tả trong một định dạng tiến trình
máy cụ thể là Ngôn ngữ mô tả dịch vụ web (Web Services Description
Language - WSDL) Các hệ thống khác tương tác với dịch vụ web trong một
cách thức theo quy định trong mô tả của nó bằng cách sử dụng tin nhắn
SOAP, thông thường là truyền đạt bằng cách sử dụng HTTP với một XML
nhiều lần cùng liên kết với các web liên quan đến tiêu chuẩn khác."
Các W3C cũng nói, "Chúng tôi có thể xác định hai loại chính của các
dịch vụ web, REST tuân theo các dịch vụ Web, trong đó mục đích chính của
dịch vụ là thao tác quan đại diện của các nguồn tài nguyên Web XML bằng
cách sử dụng một bộ đồng phục" không quốc tịch "hoạt động, và độc đoán
Web dịch vụ, trong đó các dịch vụ có thể phơi bày một cách tùy tiện các hoạt
động ".
1.3. Các nguy cơ đối với ứng dụng web
Ngày này việc sử dụng các website là rất phổ biến, do đó có nhiều nguy
cơ dẫn đến việc hệ thống bị tấn công. Nguy cơ đầu tiên xuất phát từ phiên bản
máy chủ web và máy chủ cơ sở dữ liệu mà chúng ta đang sử dụng. Ở mỗi
phiên bản sử dụng đề có những lỗ hổng mà nhờ đó kẻ tấn công có thể thâm
nhập vào hệ thống của chúng ta. Để khắc phục nguy cơ này, người quản trị
cần phải cập nhật các bản vá từ nhà cung cấp sản phẩm. Nhưng câu hỏi đặt ra
Học viện Kỹ thuật Mật Mã

10


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

là: Liệu sau khi cập nhật các bản vá đó sẽ hệ thống của chúng ta sẽ an toàn?.
Và ta có thể dễ dàng trả lời là chưa an toàn. Vì đối với mỗi hệ thống tùy theo
nhu cầu sử dụng sẽ có một cấu hình riêng, do đó khi cập nhất các bản vá này

có thể làm cho hệ thống hoạt động không ổn đinh, và có thể không tương
thích với các phần ta cấu hình và cài đặt thêm trên hệ thống. Và với việc cập
nhật các bản vá chính thức này còn có thể phát sinh ra những lỗi mới nghiêm
trọng hơn.
Nguy cơ thứ hai xuất phát từ lập mã nguồn của WebSite. Đối với nguy
cơ này việc khắc phục cũng không hề đơn giản. Ta có thể sửa đổi mã nguồn
để hạn chế các nguy cơ, lỗ hổng phát sinh nhưng có thể dẫn đến Website hoạt
động không đúng chức năng.
Nguy cơ thứ ba xuất phát từ bên ngoài gốm có:
- Nguy cơ bị tấn công từ chối dịch vụ (DoS, DDoS) làm cho hệ thống
không còn khả năng phục vụ các yêu cầu chính đáng.
- Nguy cơ bị thay đổi nội dung trang web làm giảm uy tín và/hoặc bôi
nhọ tổ chức.
- Nguy cơ bị kẻ xấu làm sai lệch các thông tin khi thực hiện các giao
dịch điện tử trên môi trường internet.
- Nguy cơ bị đánh cắp các thông tin nhạy cảm như: thông tin tài khoản,
mật khẩu truy cập hệ thống và thông tin thẻ tín dụng,…
Nguy cơ thứ tư xuất phát từ các dịch vụ khác của hệ thống mà cũng sẽ
gây ra không an toàn cho WebSite như dịch vụ FTP, thư điện tử. Kẻ tấn công
có thể dựa vào các lỗ hổng trên dịch vụ này để tấn công vào máy chủ web của
chúng ta.
OWASP là một dự án nguồn mở đã phát triển các tài liệu và các công
cụ để giúp mọi người an toàn các ứng dụng và dịch vụ web. Các phần mềm
và tài liệu cho dự án này được phát hành dưới giấy phép GNU. Trang web

Học viện Kỹ thuật Mật Mã

11

Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

cho dự án này là www.owasp.org. Danh sách các ứng dụng lỗ hổng web đó
sau đó được lấy từ trang này.
Dự án này đưa ra 10 tổn thương bảo mật nghiêm trọng đối với ứng
dụng Web:
1.3.1. Tấn công kịch bản liên trang
Kỹ thuật này được gọi là kỹ thuật tấn công kịch bản liên trang, là một
kĩ thuật tấn công bằng các chèn vào các website động (ASP, PHP, CGI,...) các
thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho
người sử dụng khác. Khi một trang web bị nhúng mã độc, những đoạn mã này
sẽ được thực thi ở máy của người dùng gây tác hại cục bộ, hoặc có thể lấy các
thông tin như cookie lưu ở trang web đó chuyển về cho tin tặc. Các đoạn mã
này được thực thi với quyền của trang web nạn nhân, nên loại bỏ được một số
kiểm soát truy cập (như chứng thực nguồn gốc). Gần đây hình thức tấn công
này được dùng ở mức độ cao hơn là giả mạo (Phishing). Một cuộc tấn công
XSS xảy ra khi:
• Dữ liệu vào một ứng dụng Web thông qua một nguồn không tin cậy,
thường xuyên nhất một yêu cầu web.
• Dữ liệu được bao gồm trong nội dung động được gửi tới một người
sử dụng web mà không được xác nhận cho mã độc.
Các nội dung độc hại gửi đến trình duyệt web thường có dạng của một
phân đoạn của JavaScript, nhưng cũng có thể bao gồm HTML, Flash hoặc
loại nào khác của mã mà các trình duyệt có thể thực thi. Sự đa dạng của các
cuộc tấn công dựa trên XSS là gần như vô hạn, nhưng họ thường bao gồm
truyền dữ liệu cá nhân như cookies hoặc các thông tin về phiên khác cho kẻ
tấn công, chuyển hướng các nạn nhân của nội dung trang web kiểm soát của
kẻ tấn công, hoặc thực hiện các hoạt động khác độc hại trên máy tính của
người dùng theo cách thức của trang web dễ bị tổn thương.
1.3.2. Tấn công tiêm trích lỗ hổng

Học viện Kỹ thuật Mật Mã

12


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Injection Flaws là một hình thức tấn công dựa trên các lỗi có từ mã
nguồn hay từ hệ điều hành. Injection Flaws cho phép kẻ tấn công thực hiện
các mã độc hại xuyên qua một ứng dụng web để đi vào một hệ thống khác.
Những cuộc tấn công bao gồm các cuộc gọi đến hệ điều hành thông qua các
cuộc gọi hệ thống, việc sử dụng các chương trình bên ngoài thông qua các
lệnh trình bao, cũng như các cuộc gọi đến phụ trợ cơ sở dữ liệu thông qua
SQL (ví dụ, SQL injection). Toàn bộ kịch bản được viết bằng perl, python, và
các ngôn ngữ khác có thể được tiêm vào các ứng dụng web được thiết kế và
thực thi kém. Bất cứ lúc nào một ứng dụng web sử dụng một thông dịch viên
của bất kỳ loại nào có nguy cơ của một cuộc tấn công tiêm.
Nhiều ứng dụng web sử dụng các tính năng hệ điều hành và chương
trình bên ngoài để thực hiện chức năng của mình. Sendmail là chương trình
thường được họ sử dụng, nhưng nhiều chương trình khác cũng khá tốt. Khi
một ứng dụng web cho qua thông tin từ một yêu cầu HTTP thông qua như
một phần của yêu cầu bên ngoài, nó phải cẩn thận để tránh lây nhiễm. Nếu
không, những kẻ tấn công có thể bơm ký tự đặc biệt (meta), các lệnh độc hại,
hoặc bổ lệnh vào thông tin và ứng dụng web sẽ cho qua một cách mù quáng
và có thể mất quyền điều khiển, thực thi hệ thống từ bên ngoài.
SQL injection là một hình thức đặc biệt phổ biến và nguy hiểm của
Injection Flaws. Để khai thác một lỗ hổng SQL injection, những kẻ tấn công
phải tìm một tham số mà các ứng dụng web chạy qua một cơ sở dữ liệu. Bằng
cách nhúng các câu lệnh SQL độc hại vào các nội dung của tham số này, kẻ

tấn công có thể lừa các ứng dụng web thành một chuyển tiếp truy vấn đến cơ
sở dữ liệu độc hại. Những cuộc tấn công không phải là quá khó khăn và ngày
nay các công cụ dò quét lỗ hổng đang nổi lên. Hậu quả là hệ thống sẽ bị tổn
hại nghiêm trọng, như một kẻ tấn công có thể có được, tham nhũng, hoặc phá
hủy các nội dung cơ sở dữ liệu.
Cuộc tấn công kiểu này có thể rất dễ dàng để khám phá và khai thác,
nhưng chúng cũng có thể cực kỳ tối nghĩa. Hậu quả cũng có thể chạy toàn bộ
phạm vi của mức độ nghiêm trọng, từ tầm thường để hoàn tất thỏa hiệp hệ
thống hoặc tiêu hủy. Trong mọi trường hợp, việc sử dụng các cuộc gọi bên

Học viện Kỹ thuật Mật Mã

13


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

ngoài là khá phổ biến, do đó, khả năng của một ứng dụng web có lỗ hổng kiểu
này nên được coi là nghiêm trọng.
1.3.3. Thực thi các tập tin độc hại
Lỗ hổng về thực thi tập tin độc hại được tìm thấy trong nhiều ứng dụng.
Người phát triển sẽ thường xuyên sử dụng trực tiếp hoặc gắn vào tập tin chủ
một tập tin hoặc các chức năng theo dòng, hoặc không đúng file đầu vào tin
tưởng. Trên nhiều nền tảng, các khuôn khổ cho phép hệ thống tài liệu tham
khảo việc sử dụng các tham chiếu đối tượng bên ngoài, chẳng hạn như URL
hoặc tập tin. Khi dữ liệu được kiểm tra không đầy đủ, điều này có thể dẫn đến
nội dung lạ từ xa và tùy ý được bao gồm, chế biến hoặc viện dẫn bởi các máy
chủ web.
Điều này cho phép kẻ tấn công thực hiện:
- Thực thi mã độc hại từ xa

- Cài đặt các công cụ điều khiển và bắt tay thành công
- Trên Windows, hệ thống nội bộ có thể thỏa hiệp có thể thông qua việc
sử dụng các tập tin bao gói SMB của PHP.
Cuộc tấn công này đặc biệt phổ biến trên PHP, do đó người lập trình và
quản trị viên đảm bảo mã nguồn phải được thực hiện với bất kỳ dòng hoặc
file chức năng để đảm bảo rằng người sử dụng cung cấp đầu vào không ảnh
hưởng đến tên tập tin.
Tất cả các mô hình ứng dụng Web đều dễ bị tổn thương với hình thức
tấn công này nếu như họ chấp nhận tên tập tin hoặc các tập tin từ người sử
dụng. Ví dụ điển hình là công nghệ .NET cho phép các đối số URL hoặc mã
mà chấp nhận sự lựa chọn tên tập tin của người dùng bao gồm cả các tập tin
cục bộ.
1.3.4. Tham chiếu đối tượng trực tiếp không an toàn

Học viện Kỹ thuật Mật Mã

14


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Một tham chiếu đối tượng trực tiếp xảy ra khi nhà phát triển phơi bày
một tham chiếu đến một đối tượng thực hiện nội bộ, chẳng hạn như một tập
tin, thư mục, ghi cơ sở dữ liệu, hoặc quan trọng, như là một URL hoặc hình
thức tham số. Một kẻ tấn công có thể thao tác trực tiếp tham chiếu đối tượng
để truy cập các đối tượng khác mà không được, trừ khi một kiểm tra kiểm
soát truy cập được đặt ra.
Ví dụ, trong các ứng dụng Internet Banking, người ta thường sử dụng
số tài khoản như là khóa chính. Do đó, xu hướng sử dụng số tài khoản trực
tiếp trong giao diện web. Ngay cả khi các nhà phát triển đã sử dụng tham số

truy vấn SQL để tránh SQL injection, nếu không có kiểm tra thêm rằng người
dùng là chủ tài khoản và uỷ quyền để xem tài khoản, một kẻ tấn công giả mạo
với tham số số tài khoản có thể xem hoặc thay đổi tất cả tài khoản.
Loại tấn công xảy ra với trang web của Văn phòng Thuế Úc trong năm
2000, nơi mà một người sử dụng hợp pháp nhưng thù địch đơn giản chỉ thay
đổi ABN (thuế công ty id) hiện diện trong URL, và sau đó gửi qua thư điện tử
mỗi hệ thống. Đây là một bối rối lớn cho Chính phủ của 17.000 công ty với
các chi tiết của vụ tấn công của mình. Đây là loại dễ bị tổn thương là rất phổ
biến, nhưng phần lớn chưa được kiểm tra trong các ứng dụng hiện hành.
Tất cả các nền tảng Web đều có khả năng bị tấn công theo hình thức
này.
1.3.5. Tấn công giả mạo truy vấn liên trang
Cross Site Request Forgery (CSRF) là một kỹ thuật tấn công bằng cách
sử dụng quyền chứng thực của người sử dụng đối với một website khác. Các
ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử
dụng và sau đó thực thi các câu lệnh này. CSRF sẽ lừa trình duyệt của người
dùng gửi đi các câu lệnh HTTP đến các ứng dụng web. Trong trường hợp
phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ được
thực hiện với quyền chứng thực của người sử dụng.
CSRF còn được gọi là “session riding”, “XSRF”.

Học viện Kỹ thuật Mật Mã

15


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Các kiểu tấn công CSRF xuất hiện từ những năm 1990, tuy nhiên các
cuộc tấn công này xuất phát từ chính IP của người sử dụng nên log file của

các website không cho thấy các dấu hiệu của CSRF. Các cuộc tấn công theo
kỹ thuật CSRF không được báo cáo đầy đủ, đến năm 2007 mới có một vài tài
liệu mô tả chi tiết về các trường hợp tấn công CSRF.
Năm 2008 người ta phát hiện ra khoảng 18 triệu người sử dụng eBay ở
Hàn Quốc mất các thông tin cá nhân của mình. Cũng trong năm 2008, một số
khách tại ngân hành Mexico bị mất tài khoản các nhân của mình. Trong 2
trường hợp kể trên, kẻ tấn công đều sử dụng kỹ thuật tấn công CSRF. Bằng
cách này, kẻ tấn công có thể làm cho nạn nhân thực hiện hành động mà họ
không có ý định, chẳng hạn như đăng xuất, mua hàng, thay đổi thông tin tài
khoản, lấy thông tin tài khoản, hoặc chức năng nào khác được cũng cấp bởi
các trang web dễ bị tổn thương.
Đôi khi trên các website có thể lưu trữ các tấn công CSRF. Tổn thương
này được gọi là lỗi lưu trữ CSRF. Điều này có thể được thực hiện đơn giản
bằng việc lưu trữ thẻ IMG hay IFRAME trong trường chấp nhận HTML, hoặc
bởi một tấn công phức tạp hơn như XSS. Nếu cuộc tấn công có thể lưu trữ
một tấn công CSRF trong trang web, mức độ nghiêm trọng là rất lớn. Đặc
biệt, khả năng được tăng lên bởi vì nạn nhân có nhiều khả năng để xem các
trang có chứa các tấn công hơn so với một số trang ngẫu nhiên trên Internet.
Khả năng này cũng được tăng lên bởi vì người bị hại là chắc chắn sẽ được
chứng thực cho trang web họ đã vào.
1.3.6. Rò rỉ thông tin và xử lý lỗi không đúng
Ứng dụng có thể vô tình bị rò rỉ thông tin về cấu hình của họ, hoạt động
bên trong, hoặc vi phạm sự riêng tư thông qua một loạt các vấn đề ứng dụng.
Ứng dụng cũng có thể bị rò rỉ thời gian họ đi đến quá trình hoạt động nhất
định hoặc thông qua phản ứng khác nhau để đầu vào khác nhau, chẳng hạn
như hiển thị văn bản lỗi tương tự với số lỗi khác nhau. Ứng dụng web sẽ
thường bị rò rỉ thông tin về trạng thái nội bộ của họ thông qua các thông báo
lỗi chi tiết hoặc gỡ lỗi. Thông thường, thông tin này có thể được thừa hưởng
để khởi động hoặc thậm chí tự động hoá các cuộc tấn công mạnh hơn.
Học viện Kỹ thuật Mật Mã

16


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Tất cả các ứng dụng web đều dễ bị rò rỉ thông tin và xử lý lỗi không
đúng. Các ứng dụng thường xuyên tạo ra các thông báo lỗi và hiển thị chúng
cho người dùng. Rất nhiều những thông báo lỗi là khá hữu ích cho kẻ tấn
công, khi họ tiết lộ chi tiết thực hiện hoặc thông tin đó là hữu ích trong việc
khai thác một lỗ hổng. Có một số ví dụ phổ biến này:
- Xử lý lỗi chi tiết, nơi gây lỗi hiển thị thông tin quá nhiều, chẳng hạn
như stack dấu vết, không báo cáo SQL, hoặc các thông tin gỡ lỗi khác
- Chức năng tạo ra kết quả khác nhau dựa trên yếu tố đầu vào khác
nhau. Ví dụ, cung cấp cùng tên người dùng mật khẩu khác nhau nhưng đến
một chức năng đăng nhập nên sản xuất cùng một văn bản không có người sử
dụng như vậy, và mật khẩu xấu. Tuy nhiên, nhiều hệ thống sản xuất mã lỗi
khác nhau.
Dạng tấn công cơ bản của hình thức này là Directory Browsing và
Directory Traversal.
1.3.7. Vỡ quá trình quản lý xác thực và phiên
Quản lý xác thực và phiên làm việc bao gồm tất cả các khía cạnh của
việc xử lý xác thực người sử dụng và quản lý các buổi hoạt động. Xác thực là
một khía cạnh quan trọng của quá trình này, nhưng ngay cả các cơ chế xác
thực mạnh có thể được làm suy yếu bởi chức năng quản lý không hoàn thiện
ủy nhiệm, kể cả thay đổi mật khẩu, quên mật khẩu của mình, hãy nhớ mật
khẩu của tôi, cập nhật tài khoản, và các chức năng khác có liên quan. Bởi vì
tấn công "bằng cách đi bộ" có khả năng cho nhiều ứng dụng web, tất cả các
tài khoản chức năng quản lý nên yêu cầu xác thực lại thậm chí nếu người
dùng có một phiên có giá trị.

Chứng thực người dùng trên trang web thường liên quan đến việc sử
dụng một userid và mật khẩu. Phương pháp xác thực mạnh hơn là sử dụng
phần mềm thương mại hóa và phần cứng dựa trên thẻ bài hoặc mật mã sinh
trắc học, nhưng cơ chế như vậy là chi phí cho các ứng dụng web tuyệt mật.
Một mảng rộng các tài khoản và lỗ hổng quản lý phiên làm việc có thể dẫn
đến sự thỏa hiệp của người dùng hoặc hệ thống tài khoản quản trị. Các đội
Học viện Kỹ thuật Mật Mã

17


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

phát triển thường xuyên đánh giá thấp sự phức tạp của thiết kế một chương
trình xác thực và quản lý phiên làm việc đó bảo vệ đầy đủ các thông tin trong
tất cả các khía cạnh của trang Web. Ứng dụng Web thiết lập các phiên để theo
dõi các dòng yêu cầu từ mỗi người dùng. HTTP không cung cấp khả năng
này, do đó, các ứng dụng web phải tạo cho chính bản thân mình. Thường
xuyên, môi trường ứng dụng web cung cấp các phiên, nhưng nhiều nhà phát
triển thích để tạo ra thẻ bài riêng của họ. Trong cả hai trường hợp, nếu các thẻ
phiên không đúng cách bảo vệ, kẻ tấn công có thể cướp một phiên hoạt động,
và giả định danh tính của người dùng. Tạo một chương trình để tạo ra thẻ
phiên mạnh mẽ và bảo vệ họ trong suốt vòng đời của họ đã chứng minh khó
nắm bắt với nhiều người phát triển. Trừ khi tất cả các thông tin xác thực định
danh phiên và được bảo vệ với SSL ở tất cả các lần và được bảo vệ khỏi bị
bộc lộ khác từ sai sót, chẳng hạn như trang web qua một kịch bản kẻ tấn công
có thể chiếm quyền điều khiển phiên làm việc của người sử dụng và giả danh
tính của họ.
Với tất cả các máy chủ web, máy chủ ứng dụng, và ứng dụng web đều
dễ bị ảnh hưởng từ vấn đề quản lý xác thực và phiên.

1.3.8. Mã hóa đĩa lưu trữ không an toàn
Bảo vệ dữ liệu nhạy cảm với mật mã học đã trở thành một phần quan
trọng của ứng dụng web nhiều nhất. Việc không mã hóa dữ liệu nhạy cảm là
rất phổ biến. Các ứng dụng mã hóa thường xuyên được thiết kế mật mã kém
hoặc bằng cách sử dụng mật mã hóa không phù hợp hoặc có những lỗi khi sử
dụng mật mã hóa mạnh mẽ. Những sai sót trên có thể làm lộ dữ liệu.
Tất cả các mô hình ứng dụng web đều dễ không an toàn trong mã hóa
dữ liệu lưu trữ. Ngăn chặn lỗi mật mã cần có quy hoạch cẩn thận. Các vấn đề
thường gặp nhất là:
- Không phải mã hóa dữ liệu nhạy cảm.
- Sử dụng nhà phát triển thuật toán.
- Không an toàn khi sử dụng các thuật toán mạnh mẽ.
Học viện Kỹ thuật Mật Mã

18


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

- Tiếp tục sử dụng các thuật toán đã được chứng mình yếu (MD5,
SHA-1, RC3, RC4, …).
- Sử dụng các khóa cứng, và được lưu trữ trong vùng không được bảo
vệ.
1.3.9. Truyền thông không an toàn
Các ứng dụng web thường xuyên không mã hóa lưu lượng mạng khi nó
là cần thiết để bảo vệ các thông tin nhạy cảm. Mã hóa (thường là SSL) phải
được sử dụng cho tất cả các kết nối thực, đặc biệt là các trang web được truy
cập từ internet. Nếu không, ứng dụng web sẽ phơi ra các chứng thực hoặc các
phiên thông báo. Ngoài ra, mã hóa nên được sử dụng bất cứ khi nào có dữ
liệu nhạy cảm, chẳng hạn như thẻ tín dụng hoặc thông tin y tế được truyền đi.

Các ứng dụng mà rơi hoặc có thể được đưa ra khỏi chế độ mã hóa có thể được
làm dụng bởi những kẻ tấn công. Các tiêu chuẩn PCI đòi hỏi tất cả các thông
tin thẻ tín dụng đang được truyền mạng internet phải được mã hóa.
Nếu không mã hóa thông tin liên lạc nhạy cảm có nghĩa là một kẻ tấn
công có thể lắng nghe lưu lượng truy cập từ mạng, sẽ có thể truy cập vào các
cuộc đàm thoại, bao gồm bất kỳ thông tin quan trọng hay thông tin nhạy cảm
truyền đi. Hãy xem xét rằng các mạng khác nhau sẽ được nhiều hơn hoặc ít dễ
bị đánh hơi. Tuy nhiên, điều quan trọng là nhận ra rằng cuối cùng sẽ được lưu
trữ một thỏa hiệp trên mạng gần như mọi lúc, và kẻ tấn công sẽ nhanh chóng
cài đặt một trình lắng nghe để nắm bắt các thông tin của hệ thống khác.
Sử dụng SSL cho thông tin liên lạc với người dùng cuối là rất quan
trọng, vì họ rất có khả năng được sử dụng mạng không an toàn đến các ứng
dụng truy cập. Bởi vì bao gồm các thông tin xác thực HTTP hoặc thẻ phiên
với mọi yêu cầu duy nhất, tất cả lưu lượng truy cập xác thực cần phải đi qua
SSL, không chỉ yêu cầu đăng nhập thực tế.
Mã hoá thông tin liên lạc với các máy chủ phụ trợ cũng rất quan trọng.
Mặc dù các mạng này có thể sẽ là an toàn hơn, các thông tin và các thông tin
mà họ mang theo là nhạy cảm hơn và nhiều hơn nữa rộng rãi. Vì vậy bằng
cách sử dụng SSL trên phụ trợ khá quan trọng.
Học viện Kỹ thuật Mật Mã

19


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Mã hoá dữ liệu nhạy cảm, chẳng hạn như thẻ tín dụng, số an sinh xã
hội, đã trở thành một sự riêng tư và quy chế tài chính cho nhiều tổ chức. Bỏ
qua để sử dụng SSL cho các kết nối xử lý các dữ liệu đó tạo ra một rủi ro tuân
thủ.

1.3.10. Lỗi khi giới hạn truy cập URL
Thực tế, việc bảo vệ chỉ một URL có liên kết đến trang mà không phải
trình bày cho người sử dụng là trái phép. Tuy nhiên, với một động cơ, có một
tay nghề hay chỉ đơn giản kẻ tấn công có thể may mắn có thể tìm thấy và truy
cập các trang này, gọi chức năng, và xem dữ liệu. Bảo mật bằng cách tối tăm
không đủ để bảo vệ những chức năng, dữ liệu nhạy cảm trong một ứng dụng.
Quyền truy cập phải được kiểm tra trước khi một chức năng nhạy cảm được
gán quyền, và chắc chắn rằng người sử dụng phải được xác nhận khi truy cập
vào các chức năng, dữ liệu này.
Phương pháp tấn công chính cho lỗ hổng này được gọi là "buộc phải
xem", trong đó bao gồm các kỹ thuật đoán liên kết và sức mạnh vét cạn để
tìm các trang không được bảo vệ. Các ứng dụng thường xuyên cho phép mã
điều khiển truy cập và lan rộng ra khắp mã cơ sở, kết quả trong một mô hình
phức tạp đó là khó hiểu đối với các nhà phát triển và cả các chuyên gia bảo
mật. Phức tạp này làm cho nó có khả năng sai sót sẽ xảy ra và các trang sẽ
được bỏ qua, để lại cho họ tiếp xúc.
Một số ví dụ phổ biến của những sai sót bao gồm:
- "Ẩn" hoặc các URL "đặc biệt", kết xuất chỉ để các quản trị viên hoặc
người sử dụng đặc quyền trong lớp trình bày, nhưng truy cập vào tất cả người
dùng nếu họ biết nó tồn tại, như /admin/adduser.php hay /approveTransfer.do.
Điều này đặc biệt phổ biến với mã menu.
- Các ứng dụng thường cho phép truy cập tới các tập tin ẩn, chẳng hạn
như XML tĩnh hoặc hệ thống tạo ra các báo cáo, tin tưởng vào thông qua bảo
mật yếu để ẩn chúng.

Học viện Kỹ thuật Mật Mã

20

Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

- Mã thực thi một chính sách kiểm soát truy cập nhưng đã hết hạn hoặc
không đủ. Ví dụ, hãy tưởng tượng /approveTransfer.do đã từng có sẵn cho tất
cả người dùng, nhưng kể từ khi điều khiển SOX đã được đưa vào, nó chỉ là
nghĩa vụ phải có sẵn cho người chấp nhận. Một sửa chữa có thể có được để
không có mặt nó cho người sử dụng trái phép, nhưng không có kiểm soát truy
cập là thực sự thi hành khi yêu cầu trang đó.

Chương 2: CÁC GIẢI PHÁP ĐẢM BẢO AN TOÀN ỨNG
DỤNG WEB (WEB APPLICATION)
2.1. Lập trình an toàn
Ngày nay, các ứng dụng web ngày càng được các công ty sử dụng. Các
ứng dụng web một mặt mở ra rất nhiều những khả năng, cơ hội kinh doanh
mới cho các tổ chức, doanh nghiệp, song mặt khác cũng đã và đang đặt hệ
thống thông tin của các đơn vị này trước những mối đe dọa bị hacker tấn
công. Nguy cơ này càng trở nên nghiêm trọng hơn đối với những tổ chức có
các ứng dụng web quan trọng như Web Portal, e-Banking, e-Commerce... Do
đó để ngăn chặn các nguy cơ đã nêu ở trên, giải pháp đầu tiên xuất phát từ
nhà phát triển đó là lập trình an toàn.
Các thói quen cần có để đảm bảo lập trình an toàn:
- Kiểm tra hợp lệ đầu vào
- Bảo vệ hệ thống tệp tin

Học viện Kỹ thuật Mật Mã

21


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

- Bảo vệ cơ sở dữ liệu
- Bảo vệ dữ liệu phiên làm việc
- Bảo vệ chống lại các sơ hở của kịch bản lệnh xuyên các trang (CrossSite Scripting - XSS)
- Kiểm tra các biểu mẫu gửi lên
- Bảo vệ chống lại các giả mạo yêu cầu xuyên các trang (Cross-Site
Request Forgeries - CSRF)
2.1.1. Kiểm tra hợp lệ đầu vào
Kiểm tra dữ liệu hợp lệ là thói quen quan trọng nhất mà ta có thể tuân
thủ khi nói về an ninh. Và khi nói đến đầu vào, đơn giản là: Đừng tin tưởng
người sử dụng. Người sử dụng của ta có lẽ là người tốt, và hầu hết họ có lẽ sử
dụng ứng dụng của ta đúng như ta đã mong đợi. Tuy nhiên, bất cứ khi nào có
cơ hội nhập đầu vào, có nghĩa là cũng có cơ hội để nhập đầu vào xấu, thực sự
là xấu. Là một nhà phát triển ứng dụng, ta phải bảo vệ ứng dụng của mình
trước đầu vào xấu. Việc xem xét cẩn thận đầu vào từ người sử dụng của ta
đang hướng tới đâu và đó phải là cái gì sẽ cho phép ta xây dựng một ứng
dụng vững chãi, an toàn.
Mặc dù tương tác hệ thống tệp tin và cơ sở dữ liệu sẽ được trình bày
sau, dưới đây là các lời khuyên chung về kiểm tra hợp lệ, bao gồm mọi loại:
- Sử dụng danh sách các giá trị hợp lệ (white-listed)
- Luôn luôn kiểm tra hợp lệ lại các lựa chọn bị hạn chế
- Sử dụng các hàm thoát lập sẵn
- Kiểm tra kiểu dữ liệu đúng đắn, ví dụ như là các số
Các giá trị trong danh sách trắng (white-listed) là các giá trị được chấp
nhận, đối lập với các giá trị thuộc danh sách đen (black-listed) là không được
chấp nhận. Sự phân biệt là ở chỗ, thông thường khi kiểm tra hợp lệ, danh sách
Học viện Kỹ thuật Mật Mã

22

Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

hoặc dải các giá trị khả dĩ nhỏ hơn danh sách các giá trị không hợp lệ vì nhiều
giá trị không hợp lệ còn chưa biết hoặc rất bất ngờ.
Khi ta đang thực hiện kiểm tra hợp lệ, nên nhớ rằng thường dễ hình
dung và kiểm tra hợp lệ những cái mà ứng dụng đó cho phép thay vì cố gắng
bảo vệ chống lại tất cả các giá trị chưa biết. Ví dụ, để giới hạn các giá trị trong
một trường chỉ là các số, hãy viết ra một thủ tục (routine) bảo đảm đầu vào tất
cả phải là số. Đừng viết thủ tục để tìm kiếm các giá trị không phải là số và
đánh dấu nó là không hợp lệ nếu tìm thấy.
2.1.2. Bảo vệ hệ thống tệp tin
Vào tháng Bảy năm 2000, một trang web đã để lọt dữ liệu của khách
hàng trong các tệp tin trên một máy chủ Web. Một người xem truy cập vào
trang web đó đã điều khiển URL để xem được các tệp tin có chứa dữ liệu.
Mặc dù các tệp tin này bị đặt sai vị trí, ví dụ này nhấn mạnh tầm quan trọng
của việc bảo vệ hệ thống tệp tin của ta chống lại những kẻ thâm nhập.
Nếu ứng dụng PHP làm bất cứ điều gì với các tệp tin và có dữ liệu biến
đổi mà người sử dụng có thể nhập vào, hãy cẩn thận rằng ta phải lau chùi sạch
sẽ dữ liệu đầu vào của người sử dụng để đảm bảo rằng người sử dụng không
thể làm được bất cứ điều gì đối với hệ thống tệp tin mà ta không muốn họ
làm. Liệt kê 1 cho thấy một thí dụ về một trang web PHP để tải xuống một
hình ảnh khi cung cấp tên.
Như ta có thể thấy, kịch bản tương đối nguy hiểm trong Liệt kê 1 đưa
ra phục vụ bất kỳ tệp tin nào mà máy chủ Web có quyền đọc, kể cả các tệp tin
trong thư mục phiên làm việc và thậm chí một số tệp tin hệ thống như
/etc/passwd. Thí dụ này có một hộp văn bản trong đó người sử dụng có thể gõ
nhập vào tên tệp tin dùng làm ví dụ, nhưng tên tệp tin đó cũng có thể được
cung cấp một cách dễ dàng trong chuỗi truy vấn.

Học viện Kỹ thuật Mật Mã

23


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

Hình 2.1: Liệt kê 1 – Tải xuống một tập tin
Việc cấu hình cho phép truy cập hệ thống tệp tin tùy theo đầu vào của
người sử dụng là nguy hiểm, vì vậy tốt nhất là tránh hoàn toàn việc đó bằng
cách thiết kế ứng dụng của ta để nó sử dụng một cơ sở dữ liệu và các tên tệp
tin được tạo ra và giấu kín. Tuy nhiên, không phải lúc nào cũng có thể làm
thế. Liệt kê 2 cung cấp một thí dụ về một thủ tục kiểm tra hợp lệ tên tệp tin.
Nó sử dụng các biểu thức chính quy để đảm bảo rằng chỉ các ký tự hợp lệ là
được sử dụng trong tên tệp tin và đặc biệt kiểm tra các ký tự chấm chấm: ...

Hình 2.2: Liệt kê 2 – Kiểm tra hợp lệ với các ký tự trong tên tập tin
2.1.3. Bảo vệ cơ sở dữ liệu
Vào tháng Tư năm 2008, Cục quản lý nhà tù (Department of
Corrections) của một bang của Mỹ đã để rò rỉ dữ liệu nhạy cảm vì lý do tên
cột SQL được sử dụng trong chuỗi vấn tin. Chỗ sơ hở này cho phép những
người sử dụng ác ý chọn được (select) những cột nào muốn hiển thị, đưa ra
các trang, và lấy dữ liệu. Vụ rò rỉ này cho thấy rằng người sử dụng có thể tính
Học viện Kỹ thuật Mật Mã

24


Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa ModSecurity và Iptables

toán ra được các cách để làm cho đầu vào của họ làm những việc mà các nhà
phát triển ứng dụng chắc chắn không lường trước được và nhấn mạnh sự cần
thiết phải bảo vệ một cách cẩn thận chống lại các cuộc tấn công bằng bơm
vào SQL (SQL injection).
Liệt kê 3 cho thấy một thí dụ của một kịch bản chạy một lệnh SQL.
Trong thí dụ này, lệnh SQL là một lệnh động, có thể để lọt cùng một kiểu tấn
công đó. Chủ nhân của biểu mẫu này có thể đã nghĩ rằng chúng là an toàn vì
họ đã hạn chế các tên cột chỉ trong một danh sách chọn. Tuy nhiên, mã này bỏ
qua sự chú ý nói trong thói quen cuối cùng về việc nhại mẫu (form spoofing) chỉ vì mã hạn chế việc lựa chọn chỉ trong các hộp thả xuống không có nghĩa
rằng một ai đó không thể gửi lên một biểu mẫu với bất cứ cái gì mà họ muốn
trong đó (kể cả một dấu sao [*]).

Học viện Kỹ thuật Mật Mã

25