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.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

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

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ừ

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 QUAN1.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 (back-

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)

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

ứ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ì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

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

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

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

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

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

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”

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

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

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ẽ

- 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

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

- 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

- 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 Site Scripting - XSS)

(Cross 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

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ì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

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ình 2.3: Liệt kê 3 - Thi hành một lệnh SQL

Vì vậy, để hình thành thói quen bảo vệ cơ sở dữ liệu của ta, tránh mã SQL động càng nhiều càng tốt Nếu ta không thể tránh được mã SQL động, đừng sử dụng trực tiếp đầu vào đối với các cột Liệt kê 4 hiển thị một thí dụ

về năng lực khi bổ sung một thủ tục kiểm tra hợp lệ đơn giản đối với trường

số tài khoản để đảm bảo rằng nó không thể là một dữ liệu không-phải-số, đồng thời sử dụng các tên cột tĩnh

Hình 2.4: Liệt kê 4 - Liệt kê bằng kiểm tra hợp lệ

Ví dụ này cũng cho thấy việc sử dụng hàm mysql_real_escape_string() Hàm này chải sạch một cách đúng đắn đầu vào của ta, sao cho nó không còn

báo trước là nó đã lạc hậu và sẽ được loại bỏ trong PHP V6 Bây giờ hãy tránh dựa vào nó và viết các ứng dụng PHP của ta an toàn mà không cần đến

nó Ngoài ra, hãy nhớ rằng nếu ta đang sử dụng một ISP, có nhiều khả năng là magic_quotes_gpc không được kích hoạt

Cuối cùng, trong ví dụ được cải tiến, ta có thể thấy rằng lệnh SQL và đầu ra không bao gồm việc lựa chọn cột động Bằng cách này, nếu ta sau này thêm cột vào bảng mà có các thông tin khác nhau, ta có thể in chúng ra Nếu

ta đang sử dụng một khung công tác để làm việc với cơ sở dữ liệu của ta, có nhiều khả năng là khung công tác của ta đã kiểm tra hợp lệ SQL cho ta rồi Hãy kiểm tra tài liệu về khung công tác của ta xem đúng như thế không; nếu

ta vẫn chưa chắc chắn, hãy thực hiện việc kiểm tra hợp lệ với các lỗi về an toàn Thậm chí nếu ta đang sử dụng một khung công tác để tương tác cơ sở dữ liệu, ta vẫn cần phải thực hiện những kiểm tra hợp lệ khác

2.1.4 Bảo vệ phiên làm việc

Theo mặc định, thông tin phiên làm việc trong PHP được viết vào một thư mục tạm thời Hãy xem xét biểu mẫu trong Liệt kê 5, nó cho thấy cách lưu một mã nhận dạng người sử dụng và số tài khoản trong một phiên làm việc

Hình 2.5: Liệt kê 5 - Lưu trữ dữ liệu trong phiên

Liệt kê 6 cho thấy nội dung của thư mục /tmp

Hình 2.6: Liệt kê 6 - Các tập tin phiên trong thư mục /tmp

Như ta có thể thấy, tệp tin phiên, khi được in ra (xem Liệt kê 7), chứa các thông tin trong một định dạng khá dễ đọc Vì tệp tin phải đọc được và viết được đối với người sử dụng máy chủ web, các tệp tin phiên này có thể tạo ra một vấn đề lớn đối với bất cứ người nào trên một máy chủ chia sẻ Người nào

đó không phải là ta có thể viết một kịch bản lệnh đọc các tệp tin này để họ có thể thử lợi dụng phiên làm việc đó

Hình 2.7: Liệt kê 7 – Nội dung của một tập tin phiên

Ta có thể làm hai điều để bảo vệ dữ liệu phiên của ta Trước tiên là mã hóa mọi thứ mà ta đưa vào phiên Tuy nhiên chỉ riêng việc ta đã mã hóa dữ liệu không có nghĩa là nó đã an toàn trọn vẹn, do đó hãy cẩn thận, đừng tin tưởng vào việc này như là phương tiện duy nhất của ta để bảo vệ phiên làm việc của mình Có cách khác là lưu dữ liệu phiên của ta ở một nơi khác, ví dụ như một cơ sở dữ liệu Ta vẫn phải đảm bảo rằng ta đang khóa kín cơ sở dữ liệu của ta, nhưng cách tiếp cận này giải quyết được hai vấn đề: Trước nhất,

nó đặt dữ liệu của ta vào một nơi an toàn hơn một hệ thống tệp tin chia sẻ; thứ hai, nó cho phép ứng dụng của ta mở rộng trải ra bao gồm nhiều máy chủ web

dễ dàng hơn với các phiên được chia sẻ xuyên qua nhiều máy chủ

Để thực hiện ghi lưu bền vững các dữ liệu về phiên làm việc của chính

ta, xem hàm session_set_save_handler() trong PHP Dùng nó, ta có thể lưu trữ thông tin phiên trong một cơ sở dữ liệu hoặc triển khai thực hiện một trình xử lý

một thí dụ về cách sử dụng hàm này và các hàm khung cho việc triển khai thực hiện Ta cũng có thể kiểm tra các thí dụ về cách sử dụng một cơ sở dữ liệu.

Mật khẩu sẽ tuyệt đối không bao giờ được lưu giữ ở dạng văn bản rõ ở bất kỳ nơi nào — không được nằm trong một cơ sở dữ liệu, phiên làm việc,

hệ thống tệp tin, hoặc ở bất kỳ dạng nào khác Cách tốt nhất để xử lý các mật khẩu là lưu chúng đã mã hóa và so sánh với các mật khẩu đã mã hóa với nhau Mặc dù điều này có vẻ là hiển nhiên, song việc lưu giữ chúng ở dạng văn bản rõ dường như được làm khá nhiều trong thực tế Bất cứ khi nào ta sử dụng một trang web mà có thể gửi cho ta mật khẩu của ta thay vì việc đặt lại, điều đó có nghĩa là hoặc mật khẩu được lưu ở dạng văn bản rõ hoặc đã có mã lệnh sẵn để giải mã mật khẩu nếu nó được mật mã hóa Ngay cả ở trường hợp sau, mã lệnh để giải mã có thể tìm thấy và khai thác được

Hình 2.8: Liệt kê 8 – Ví dụ về hàm session_set_save_handler()

2.1.5 Bảo vệ chống lại các lỗ hổng XSS

Các lỗ hổng XSS chiếm một tỷ lệ lớn trong tất cả các lỗ hổng về trang web được ghi chép lại trong năm 2007 Một lỗ hổng XSS xuất hiện khi một người sử dụng có khả năng bơm mã HTML vào các trang web của ta Mã HTML có thể mang theo mã JavaScript bên trong các thẻ kịch bản (script tags), bằng cách đó cho phép JavaScript chạy bất cứ khi nào một trang được rút ra Biểu mẫu trong Liệt kê 9 có thể đại diện cho một diễn đàn, trang mạng biên tập tự do (wiki), mạng xã hội, hoặc bất kỳ trang web nào khác thông dụng để gõ nhập văn bản

Hình 2.9: Liệt kê 9 – Biểu mẫu để nhập vào văn bản

Liệt kê 10 chứng tỏ cách biểu mẫu này in ra được các kết quả, cho phép tấn công bằng XSS

Hình 2.10: Liệt kê 10 - showResults.php

Liệt kê 11 đưa ra một thí dụ cơ sở trong đó các cửa sổ mới bật ra mở đến trang chủ của Google Nếu ứng dụng web của ta không bảo vệ chống lại các tấn công bằng XSS, thì giới hạn thiệt hại duy nhất chỉ còn là sức tưởng tượng của kẻ thâm nhập mà thôi Ví dụ, một ai đó có thể thêm vào một liên kết mà bắt chước kiểu dáng của trang web đó để lừa đảo

Hình 2.11: Liệt kê 11 – Mẫu văn bản đầu vào độc hại

Để tự bảo vệ ta chống lại các tấn công XSS, hãy lọc đầu vào của ta thông qua hàm htmlentities() bất cứ khi nào giá trị của một biến được in đến đầu ra Hãy nhớ làm theo thói quen đầu tiên về kiểm tra hợp lệ dữ liệu đầu vào bằng các giá trị trong danh sách trắng trong ứng dụng web của ta đối với tên, địa chỉ email, số điện thoại, và thông tin về hoá đơn thanh toán

Một phiên bản an toàn hơn nhiều của trang để hiển thị văn bản đầu vào như dưới đây

Hình 2.12: Liệt kê 12 – Một biểu mẫu an toàn hơn

2.1.6 Bảo vệ chống lại việc gửi lên (post) không hợp lệ

Nhại mẫu (Form spoofing) là khi một ai đó thực hiện gửi lên đến một

trong các biểu mẫu của ta từ một nơi nào đó mà ta không mong đợi Cách dễ nhất để nhại mẫu chỉ đơn giản là tạo ra một trang web đệ trình một biểu mẫu,

chuyển theo tất cả các giá trị Do các ứng dụng web là phi trạng thái (stateless), nên không có cách nào để chắc chắn tuyệt đối là dữ liệu đã được gửi lên từ nơi mà ta muốn nó đến từ đó Mọi thứ từ các địa chỉ IP cho đến tên máy chủ, cuối cùng rồi đều có thể bị nhại Liệt kê 13 hiển thị một biểu mẫu điển hình cho phép ta nhập thông tin.

Hình 2.13: Liệt kê 13 – Một biểu mẫu để xử lý văn bản

Liệt kê 14 cho thấy một biểu mẫu sẽ được gửi đến biểu mẫu trong Liệt

kê 13 Để thử việc này, ta có thể đặt mẫu đó lên một trang web, sau đó ghi lưu

mã trong Liệt kê 14 như một tài liệu HTML trên máy tính của ta Khi ta đã lưu lại biểu mẫu này, hãy mở nó ra trong một trình duyệt Sau đó ta có thể điền dữ liệu vào và đệ trình biểu mẫu đó rồi quan sát trong khi dữ liệu được

xử lý

Hình 2.14: Liệt kê 14 - Một biểu mẫu để thu nhập dữ liệu

Tác động tiềm tàng của việc nhại mẫu thực ra là ở chỗ nếu ta có một biểu mẫu mà có các hộp thả xuống, nút radio, hộp kiểm, hoặc các đầu vào hạn chế khác, những hạn chế đó không có ý nghĩa gì cả nếu biểu mẫu đó bị giả mạo Xem xét mã trong Liệt kê 15, trong đó chứa một biểu mẫu với dữ liệu không hợp lệ

Hình 2.15: Liệt kê 15 – Một biểu mẫu với dữ liệu không hợp lệ

Nếu ta có một hộp thả xuống hoặc một nút radio, hạn chế người sử dụng chỉ có một số lượng đầu vào nhất định, ta có thể bị thuyết phục rằng không phải lo lắng về việc kiểm tra hợp lệ đầu vào Rốt cuộc, biểu mẫu đầu vào của ta bảo đảm rằng người sử dụng chỉ có thể nhập vào một số dữ liệu nhất định, đúng không? Để hạn chế việc nhại mẫu, hãy lập ra các biện pháp

để bảo đảm rằng những người gửi dữ liệu lên đúng là những người khai nhận rằng họ là những người đó Một kỹ thuật mà ta có thể sử dụng là thẻ bài sử dụng một lần (single-use token), nó không làm cho việc giả mạo mẫu của ta bất khả thi nhưng làm cho nó trở thành một điều rắc rối kinh khủng Vì thẻ bài thay đổi mỗi khi mẫu được rút xuống, một kẻ xâm nhập tương lai cần phải lấy một cá thể của biểu mẫu đang gửi, rút thẻ bài, và đặt nó vào phiên bản giả mạo của biểu mẫu đó Kỹ thuật này làm cho rất khó có khả năng một ai đó lập

ra một biểu mẫu web lâu dài để gửi các yêu cầu không mong muốn đến ứng dụng của ta Liệt kê 16 đưa ra một thí dụ về một thẻ bài biểu mẫu dùng một lần

Hình 2.16: Liệt kê 16 – Sử dụng một thẻ bài biểu mẫu một lần

2.1.7 Bảo vệ chống lại các giả mạo truy vấn liên trang (CSRF)

Các giả mạo truy vấn liên trang (các tấn công CSRF-Cross-Site

Request Forgeries) khai thác các lợi thế về quyền ưu tiên của người sử dụng

để thực hiện tấn công Trong một cuộc tấn công CSRF, người sử dụng của ta

có thể dễ dàng trở thành các kẻ đồng loã không bị nghi ngờ Liệt kê 17 cung cấp một thí dụ về một trang web thực hiện một số hành động Trang web này tìm kiếm thông tin đăng nhập của người sử dụng từ cookie Khi mà cookie này hợp lệ, trang web sẽ xử lý yêu cầu

Hình 2.17: Liệt kê 17 - Một thí dụ của CSRF

Các cuộc tấn công CSRF thường được thực hiện dưới dạng các thẻ

<img> vì trình duyệt gọi URL một cách không ý thức để lấy hình ảnh Tuy nhiên, nguồn hình ảnh dễ dàng có thể chỉ là URL của một trang web trên cùng

Khi thẻ <img> này được đặt trong một cuộc tấn công XSS — cũng là các tấn công phổ biến nhất được ghi chép lại — người sử dụng dễ dàng có thể làm một việc gì đó với quyền ưu tiên được cấp mà không biết mình đã làm — như vậy, có thể giả mạo

Để tự bảo vệ ta chống lại CSRF, hãy sử dụng cách tiếp cận thẻ bài sử dụng một lần mà ta áp dụng tuân theo thói quen xác minh các biểu mẫu gửi lên Ngoài ra, sử dụng biến hiển $_POST thay vì $_REQUEST Liệt kê 18 trình bày một ví dụ xấu về trang web mà xử lý y như thế — cho dù trang web đó được gọi bởi một yêu cầu GET hay bởi vì có một biểu mẫu gửi lên đến nó

Hình 2.18: Liệt kê 18 – Lấy dữ liệu từ $_REQUEST

Liệt kê 19 cho thấy một phiên bản đã làm sạch của trang này, sẽ chỉ làm việc khi POST biểu mẫu

Hình 2.19: Liệt kê 19 - Lấy dữ liệu chỉ từ $_POST

2.2 Sử dụng các thiết bị và phần mềm bảo mật cho ứng dụng web

Mặc dù các máy chủ có thể nâng cấp phần mềm, vá các bản vá được cung cấp, nhưng giải pháp này không thật sự an toàn Vì sau khi nâng cấp, vá các bản vá có thể sẽ gây ra nhiều nguy cơ hơn Do đó ta có thể sử dụng các thiết bị tường lửa, tường lửa ứng dụng Web, các phần mềm tường lửa, các thiết bị chống xâm nhập (IDS/IPS) để bảo vệ Website, che giấu các thông tin

về máy chủ web, chống lại các tấn công nguy hiểm như SQL Injection, XSS 2.2.1 Giải pháp sử dụng tường lửa

Trong các giải pháp an toàn, ta có thể sử dụng giải pháp tường lửa, có thể là thiết bị như của các hãng nổi tiếng thế giới như Checkpoint, Imperva hay phần mềm như ModSecurity, Iptables (Linux), PF (BSD Unix), ufw (Uncomplicated Firewall) để bảo vệ hệ thống máy chủ web

2.2.1.1.Giải pháp với thiết bị tường lửa của CheckPoint

Từ việc phân tích các nguy cơ và các điểm yếu bảo mật đối với hệ thống ứng dụng web kể trên, việc trang bị một hệ thống phòng vệ và giảm nhẹ các rủi ro là một điều tất yếu để đáp ứng nhu cầu trao đổi thông tin và cạnh tranh trong kinh doanh như hiện nay, nhưng đầu tư thế nào cho hiệu quả về kinh tế và tương xứng với hệ thống cần bảo vệ không phải là một việc làm đơn giản Dưới con mắt của các chuyên gia bảo mật thì các mức độ đầu tư sẽ được phân loại đối với từng mô hình ứng dụng web như sau:

a Giải pháp bảo vệ ứng dụng web cho các tổ chức/doanh nghiệp vừa

và nhỏ.

Đối với các tổ chức/doanh nghiệp vừa và nhỏ có một hệ thống ứng dụng web với phần lớn các thông tin tĩnh (ít thay đổi), không chứa các dữ liệu quý cũng như không có các giao dịch mua bán,… có thể trang bị một thiết bị

an ninh tích hợp (UTM) và bổ sung thêm module tường lửa cho ứng dụng web

Hình 2.20: Giải pháp CheckPoint UTM cho danh nghiệp vừa và nhỏ

Các tính năng trong thiết bị an ninh tích hợp:

- Tường lửa (Firewall): sẽ ngăn chặn các tấn công tại tầng mạng, các hành vi dò quét vào hệ thống…

- Ngăn chặn xâm nhập (IPS): sẽ loại bỏ các tấn công tập trung vào các điểm yếu của phần mềm ứng dụng web, của phần mềm cơ sở dữ liệu, tấn công khai thác điểm yếu của hệ điều hành

- Thành phần mạng riêng ảo: cho phép kết nối VPN giữa trụ sở chính

và các chi nhánh, và các nhân viên làm việc từ xa…

- Thành phần quét virus: loại bỏ worm, virus ẩn mình qua dịch vụ web

và mail…

Thành phần tường lửa cho ứng dụng web bổ sung vào thiết bị an ninh tích hợp cho phép ngăn chặn các tấn công tận dụng các điểm yếu của ứng dụng web

b Giải pháp cho các tổ chức/doanh nghiệp lớn

Đối với các tổ chức/doanh nghiệp lớn thường có một hệ thống web với rất nhiều dữ liệu quan trọng mang tính chất sống còn đối với tổ chức/doanh nghiệp, đồng thời thường xuyên diễn ra các giao dịch trực tuyến… đòi hỏi phải có độ an toàn, sẵn sàng cao Cần triển khai hệ thống với nhiều lớp bảo

mật khác nhau, sử dụng các công nghệ bảo mật hàng đầu trên thế giới Mô hình triển khai bảo mật có thể xây dựng dưới ba mức bảo mật như sau:

Hình 2.21: Giải pháp CheckPoint UTM cho doanh nghiệp lớn

• Mức 1: sử dụng thiết bị an ninh tích hợp (Check Point UTM-1): thành

phần tường lửa trong thiết bị sẽ ngăn chặn các tấn công tại mức mạng, các tấn công dò quét Thành phần IPS ngăn chặn các tấn công khai thác điểm yếu của các hệ điều hành, điểm yếu của phần mềm web, phần mềm cơ sở dữ liệu Thành phần VPN cho phép thiết lập kênh riêng ảo với các chi nhánh, phòng giao dịch và các người dùng từ xa

• Mức 2: sử dụng thiết bị tường lửa chuyên dụng cho ứng dụng web

(NetContinuum) tạo thành lớp bảo vệ thứ hai

o Thành phần Application Firwall kiểm soát mọi luồng dữ liệu đi đến mỗi máy chủ ứng dụng và thành phần Dynamic Application Protection (DAP) cho qua đối với các yêu cầu hợp lệ và ngăn chặn mọi yêu cầu bất hợp pháp Các chính sách bảo mật được thiết lập cho từng phần của ứng dụng web với danh sách điều khiển truy cập web (Access Control Lists - ACL) có thể thiết lập luật cho từng trang web (URL), các tham

số, thiết lập kiểm soát dữ liệu trên các trường của form nhập liệu và cho phép mã hoá các trường có thông tin quan trọng như trường nhập thông

o Cũng giống như các tường lửa lớp mạng được thiết kế để chống lại tấn công từ chối dịch vụ tại tầng mạng để bảo vệ tài nguyên mạng thì NetContinuum đưa ra giải pháp AppDoS (Application level Denial of Service) để chống lại tấn công từ chối dịch vụ tại tầng ứng dụng để bảo

vệ tài nguyên tầng ứng dụng web

o Thành phần Website Cloaking: làm giảm các nguy cơ tấn công bằng cách che giấu toàn bộ tài nguyên của ứng dụng web đằng sau nó Sau khi che giấu trang web, hệ thống tự động kiểm tra để đảm bảo ứng dụng hoạt động theo đúng ý đồ của người phát triển ứng dụng web

• Mức 3: có thể thiết lập thêm một mức bảo vệ thứ ba với thiết bị an ninh

tích hợp (Check Point UTM-1) để phân tách mạng thành nhiều vùng mạng (zone) với các mức độ bảo mật khác nhau khi truy cập đến hệ thống máy chủ

cơ sở dữ liệu và máy chủ ứng dụng web, chính sách trên thiết bị an ninh tích hợp này được siết chặt hơn so với thiết bị Mức 1 Đồng thời tại Mức 3 này cũng có thể sử dụng một thiết bị ngăn chặn xâm nhập (IPS) chuyên dụng để loại bỏ các tấn công vào ứng dụng trong trường hợp chúng vượt qua lớp bảo

vệ thứ nhất và thứ hai hoặc các tấn công có nguồn gốc trong mạng

c Giải pháp bảo vệ ứng dụng web cho Intranet/Extranet (Web Security Portal)

Ngày nay, với sự phát triển mạnh của các kết nối Internet băng thông rộng và máy tính/thiết bị cá nhân, và tính chất của công việc, các tổ chức/doanh nghiệp cho phép nhân viên làm việc tại bất cứ đâu như: ở nhà, khách sạn, quán cafe internet, trên đường đi công tác,…và có thể làm việc bất

kể thời gian nào và bất cứ nơi nào có kết nối Internet Việc mở rộng phương thức làm việc có thể giúp cho hiệu quả làm việc của nhân viên tăng, chi phí giảm và giúp kéo dài thời gian hoạt động của doanh nghiệp, nhưng các tổ chức và doanh nghiệp lại phải đối đầu với nguy cơ thất thoát thông tin cũng như mất an toàn với hệ thống