ATTT Ứng dụng Web - PHẦN 3: BẢO VỆ AN TOÀN THÔNG TIN ỨNG DỤNG WEB

PHẦN 3: BẢO VỆ AN TOÀN THÔNG TIN ỨNG DỤNG WEB


I.  Quy hoạch, thiết kế hệ thống web an toàn

1.  Mô hình triển khai ứng dụng web

  • Trong phần trên, chúng ta đã tìm hiểu về các loại lỗ hổng cơ bản thường thấy trong hệ thống ứng dụng web. Phần này chúng ta sẽ tiếp tục tìm hiểu cơ chế bảo mật/phòng thủ trong từng bước xây dựng, triển khai hệ thống ứng dụng web.

  • Thông thường, quá trình xây dựng/triển khai hệ thống ứng dụng web gồm 4 bước cơ bản:

  • Quy hoạch/thiết kế

  • Phát triển

  • Triển khai

  • Vận hành

  • Tương ứng với mỗi bước là từng chức năng cụ thể. Trong mỗi chức năng giai đoạn này, yếu tố an toàn thông tin là bắt buộc phải có. Phần hai này sẽ trình bày các yếu tố, phương pháp đảm bảo an toàn thông tin trong từng bước đó. An toàn thông tin trong quy hoạch/thiết kế ứng dụng web được trình bày trong mục I phần 2 này. An toàn thông tin trong phát triển ứng dụng web được trình bày trong mục II phần 2. An toàn thông tin trong triển khai và vận hành hệ thống web trình bày trong mục III, IV phần 2.

  • Với mỗi phần tương ứng với chức năng nhiệm vụ của cá nhân, đơn vị. Cán bộ thiết kế/giải pháp tham khảo chính phần quy hoạch/thiết kế an toàn. Cán bộ phát triển tham khảo phần phát triển ứng dụng web an toàn. Cán bộ triển khai, vận hành tham khảo phần triển khai, vận hành an toàn. Tuy nhiên chúng tôi khuyến khích người đọc đọc hết tất cả các phần. Bởi vì việc đảm bảo an toàn thông tin cho hệ thống ứng dụng web không phải là việc của riêng cá nhân/đơn vị nào. Đó là việc của tất cả mọi người: Từ thiết kế, phát triển, vận hành cho đến người sử dụng. Chỉ cần một sai sót nhỏ của bất kỳ cá nhân nào cũng có thể gây ra sự cố an toàn thông tin, ảnh hưởng đến hoạt động của toàn bộ hệ thống ứng dụng web đó.

  • Trong phần trước đã trình bày về các mối nguy cơ đối với một hệ thống ứng dụng web. Đối với từng hệ thống đặc thù, đặc biệt khác (ví dụ như ngân hàng, viễn thông) sẽ phải đối mặt với nhiều loại nguy cơ khác nhau. Ví dụ như ngân hàng phải đối mặt nhiều hơn đối với các nguy cơ trong logic, xử lý nghiệp vụ, các sản phẩm viễn thông đối mặt nhiều hơn với các nguy cơ trong xử lý nghiệp vụ viễn thông, kết nối thiết bị… Phần này sẽ trình bày về các biện pháp bảo vệ, phòng tránh các nguy cơ đó. Trong đó sử dụng chiến lược “Phòng thủ theo chiều sâu” làm nền tảng của các phương pháp.

2.  Chiến lược phòng thủ theo chiều sâu

  • Phòng thủ theo chiều sâu là một phương pháp triển khai các giải pháp bảo mật/ an toàn thông tin. Phương pháp này dựa theo những ý tưởng chính sau:

  • Bảo mật mạng phải tổng quát và toàn diện, bao gồm nhiều biện pháp được liên kết với nhau để đạt được mục đích.

  • Nhiều biện pháp bổ sung, tương hỗ cho nhau dựa trên đặc điểm (nhận diện và ngăn chặn) của từng biện pháp.

  • An toàn thông tin nguyên thủy bao gồm 3 yếu tố chính: Confidentiality, Integrity, Availability (C-I-A). Một hệ thống được gọi là an toàn khi đảm bảo cả 3 yếu tố đó. Các yếu tố đó là:

  • Tính bí mật: chống lại sự phơi bày, để lộ, thất thoát dữ liệu

  • Tính toàn vẹn: chống lại sự thay đổi trái phép dữ liệu

  • Tính sẵn sàng: chống lại sự phá hoại, làm mất tính sẵn sàng của hệ thống

  • Độ ưu tiên của các thuộc tính: Trong các thuộc tính bí mật, toàn vẹn và sẵn sàng là quan trọng của tổ chức thì sẽ có một thuộc tính quan trọng nhất so với các thuộc tính còn lại. Việc xác định yếu tố nào là quan trọng nhất phụ thuộc vào đặc thù của hệ thống, công ty đó. Ví dụ:

  • Tính bí mật 🡪 Ví dụ: Dược phẩm

  • Tính toàn vẹn 🡪 Ví dụ: Tài chính, Ngân hàng

  • Tính sẵn sàng 🡪 Ví dụ: Thương mại điện tử

  • Mục tiêu của phương pháp phòng thủ theo chiều sâu là đảm bảo ba yếu tố đó của hệ thống ứng dụng web. Dựa trên ý tưởng phải tổng quát, toàn diện, có thể bổ sung, tương hỗ cho nhau, phương pháp phòng thủ theo chiều sâu được phát triển thành 4 phương pháp, đó là:

  • Phân tích các tác nhân đe dọa

  • Bảo vệ đồng nhất

  • Phân đoạn bảo vệ

  • Bảo vệ thông tin trung tâm

Hình 28: Các phương pháp trong phòng thủ theo chiều sâu

  • Bảo vệ đồng nhất (Uniform Protection): Tất cả các thành phần của hệ thống đều nhận sự bảo vệ như nhau. (Firewall, VPN, IDS, Antivirus, …), dù là ở bên trong hay bên ngoài. Phương pháp này có thể gây ra nhiều lỗi đối với những kẻ tấn công bên trong vì hệ thống không được chia tách và phân loại. Phương pháp này là cách tiếp cận thông dụng nhất và cũng là yếu nhất nếu như không có một thiết kế hoàn hảo.

  • Phân đoạn bảo vệ (Protected Enclaves): Phân đoạn bảo vệ là phương pháp phân đoạn mạng cho hệ thống. Triển khai bằng cách sử dụng VPN hoặc VLAN, Firewall. Phương pháp này đơn giản và hiệu quả, giảm thiểu được thiệt hại trong trường hợp hệ thống bị tấn công.

  • Bảo vệ trong tâm (Information Centric): Nhận diện những thành phần quan trọng và chia ra nhiều lớp bảo vệ, gồm:

  • Dữ liệu được truy cập bởi ứng dụng.

  • Ứng dụng là tồn tại trong hosts.

  • Hosts thì hoạt động trên mạng.

Hình 29: Bảo vệ trọng tâm

  • Các tác nhân đe dọa (Vector-Oriented): Cung cấp cơ chế bảo mật bằng cách vô hiệu hóa các tác nhân đe dọa (Ví dụ: Vô hiệu hóa ổ USB, ổ đĩa mềm). Bằng cách gỡ bỏ các tác nhân thì tấn công sẽ không có cơ hội thành công.

  • Trên cơ sở 4 phương pháp tiếp cận này, tài liệu đưa ra một số biện pháp kỹ thuật để đảm bảo an toàn thông tin trong hệ thống ứng dụng web trong giai đoạn thiết kế/quy hoạch. Đó là:

  • Xác định cấu trúc Web

  • Triển khai hệ thống phòng thủ

  • Thiết đặt và cấu hình hệ thống máy chủ an toàn

  • Vận hành ứng dụng Web an toàn

  • Thiết đặt và cấu hình cơ sở dữ liệu an toàn

  • Cài đặt các ứng dụng bảo vệ

  • Thiết lập cơ chế sao lưu và phục hồi.

  • Xác định cấu trúc Web: Kiến trúc Web thường được chia làm 3 lớp cơ bản, gồm:

  • Lớp trình diễn: là một máy chủ phục vụ Web. Lớp này giao tiếp trực tiếp với web client, chịu trách nhiệm trình diễn và thu thập đầu vào từ người dùng cuối. Chính vì thế luôn luôn đối diện với các nguy cơ bị tấn công. Các loại máy chủ phục vụ Web thông dụng: IIS, Apache, Tomcat.

  • Lớp ứng dụng: là nơi các kịch bản ứng dụng Web thực thi. Sử dụng ngôn ngữ lập trình (PHP, ASP.NET, Java, …) nhận dữ liệu đệ trình của người sử dụng từ lớp trình diễn kết hợp với nguồn dữ liệu đầu cuối để thực thi ứng dụng Web. Máy chủ ứng dụng thông dụng: IBM Websphere, WebLogic, .NET Framework, …

  • Lớp cơ sở dữ liệu: là nơi lưu trữ dữ liệu ứng dụng Web. Chịu trách nhiệm lưu trữ và thao tác với dữ liệu ứng dụng Web. Các hệ quản trị cơ sở dữ liệu thông dụng: MySQL, SQL Server, Oracle, …

  • Dựa trên 3 lớp này người ta sẽ tạo thành các mô hình ứng dụng web. Số lượng lớp sẽ quyết định cấu trúc, các yếu tố bảo mật của hệ thống ứng dụng web đó. Thông thường sẽ có các loại mô hình: 2 lớp, 3 lớp, N lớp.

  • Mô hình 2 lớp: Kết hợp lớp trình diễn và ứng dụng trên một máy chủ. Mô hình này thiết kế đơn giản và đầy đủ cho các ứng dụng Web nhỏ. Tuy nhiên khả năng mở rộng hạn chế và triển khai biện pháp bảo mật khó khăn hơn những mô hình khác.

  • Mô hình 3 lớp: Các lớp trình diễn, ứng dụng và cơ sở dữ liệu nằm trên các máy chủ riêng biệt trong cùng một hệ thống. Trong đó các lớp được tách biệt vật lý cho nên có thể áp dụng thêm nhiều điều khiển truy cập và theo dõi mạng cũng như có thể đặt tường lửa và IDS giữa các lớp này. Nếu một lớp bị thỏa hiệp thì kẻ tấn công cũng phải cần bẻ gãy nhiều lớp nữa mới có thể thỏa hiệp được toàn bộ hệ thống.

  • Mô hình N lớp: Hình thành các nhóm dịch vụ để gia tăng khả năng chịu tải cũng như dự phòng. Nhiều lớp sẽ cung cấp lớp bảo mật, tuy nhiên nó cũng kèm theo sự phức tạp khi triển khai và bảo trì.

Hình 30: Các mô hình web

  • Tùy theo trường hợp cụ thể mà lựa chọn mô hình web tương ứng. Tuy nhiên chúng tôi khuyến khích lựa chọn mô hình từ 3 lớp trở lên để đảm bảo các yếu tố an toàn thông tin.

  • Triển khai hệ thống phòng thủ: Để đảm bảo an toàn thông tin cho mô hình, quy hoạch mạng, việc triển khai phải tổ chức mô hình mạng hợp lý. Đây là cơ sở đầu tiên cho việc xây dựng các hệ thống phòng thủ và bảo vệ. Việc này sẽ hạn chế tấn công từ bên trong và bên ngoài một cách hiệu quả. Cần phân biệt rõ ràng giữa các vùng mạng theo chức năng và thiết lập các chính sách an toàn thông tin riêng cho các vùng mạng theo yêu cầu thực tế.

  • Một số khuyến cáo khi tổ chức mô hình mạng đó là:

  • Nên đặt các máy chủ Web, Mail, FTP… cung cấp dịch vụ ra mạng Internet trong vùng DMZ: Nhằm tránh các tấn công từ mạng nội bộ, giảm thiểu nguy cơ tấn công vào mạng nội bộ nếu như các máy chủ này bị tin tặc chiếm quyền điều khiển.

  • Các máy chủ không trực tiếp cung cấp dịch vụ mạng ngoài như máy chủ ứng dụng, cơ sở dữ liệu,… nên đặt trong vùng mạng server network: Nhằm tránh tấn công trực diện từ Internet và từ mạng nội bộ. Nếu hệ thống thông tin yêu cầu mức bảo mật cao thì có thể chia vùng server network thành các vùng nhỏ hơn và độc lập để nâng cao tính bảo mật.

  • Triển khai các hệ thống phòng thủ như tường lửa và IDS/IPS để bảo vệ hệ thống, chống tấn công và xâm nhập trái phép: Đặt tường lửa giữa kết nối mạng Internet với các vùng mạng khác; giữa vùng mạng nội bộ và DMZ nhằm hạn chế các tấn công giữa các vùng đó. Đặt IDS/IPS tại vùng cần theo dõi và bảo vệ

  • Đặt một Router ngoài cùng (router biên) trước khi kết nối đến ISP: Nhằm lọc một số lưu lượng không mong muốn, chặn những gói tin đến từ những địa chỉ IP không hợp lệ.

  • Trong các khuyến cáo này có nhắc tới Firewall. Tường lửa (Firewall) là thiết bị điều khiển chặn, cho phép thông qua một số điểm trong mạng bằng cách áp dụng các chính sách. Vị trí firewall trong mạng là giữa vùng Internet và mạng bên trong của tổ chức và giữa giao tiếp mạng của PC với các PC khác.

Hình 31: Vị trí đặt Firewall

  • Trong triển khai Firewall, cần lưu ý tới Luật mặc định trong Firewall: Chuyện gì xảy ra khi gói tin không khớp với luật tồn tại: Nếu mặc định là từ chối 🡪 sự giới hạn nhiều hơn, nếu mặc định là cho phép 🡪 sự cho phép nhiều hơn. Nếu luật mặc định là từ chối sẽ cho phép chống lại các tấn công chưa biết. Chúng tôi yêu cầu các hệ thống phải đặt luật mặc định là từ chối. 

  • Lưu ý tiếp theo trong sử dụng Firewall là Phương thức lọc: Có 2 phương thức lọc là:

  • Ingress filtering: được áp dụng đối với dữ liệu đi vào bên trong mạng. Chỉ những địa chỉ mà không thuộc về mạng được bảo vệ hoặc dãy địa chỉ dành riêng thì được phép đến mạng bảo vệ.

  • Egress filtering: được áp dụng đối với dữ liệu ra khỏi mạng. Chỉ những địa chỉ thuộc về mạng bảo vệ thì cho phép ra ngoài mạng Internet.

Hình 32: Phương thức lọc

  • Lưu ý cuối cùng là: Thiết kế nhiều vùng. Việc thiết kế các vùng tuân theo nguyên tắc sau:

  • Nhiều lớp phòng thủ: Cấp độ tin tưởng sẽ được gia tăng với mỗi vùng.

  • Vùng cho phép truy cấp tối thiểu từ vùng trước đó, để giảm thiểu sự rủi ro.

  • Không được phép truy cập từ một vùng độc lập với một vùng khác.

Hình 33: Thiết kế nhiều vùng

  • Thiết đặt và cấu hình máy chủ an toàn: Chi tiết về thiết đặt máy chủ an toàn, webserver và database an toàn sẽ được trình bày cụ thể ở mục III của phần 2 này. 

  • Thiết lập cơ chế sao lưu và phục hồi: Mục đích nhằm

  • Đảm bảo toàn vẹn dữ liệu: Không bị thay đổi dữ liệu khi có tấn công, vì đã được lưu trữ từ trước khi có tấn công

  • Tiết kiệm chi phí: Không tốn chi phí triển khai lại từ đầu khi có sự cố

  • Khôi phục hệ thống ngay khi có sự cố

  • Hạn chế rủi ro

Hình 34: Vai trò của sao lưu

  • Việc sao lưu tuân theo các cơ chế:

  • Phạm vi sao lưu: Sao lưu toàn bộ dữ liệu của hệ thống 🡪 Đảm bảo được tính toàn vẹn của hệ thống và có thể phục hồi toàn bộ dữ liệu. Sao lưu từng phần riêng trong hệ thống 🡪 Sao lưu từng phần riêng và có thể phục hồi chúng khi gặp sự cố.

  • Thời gian sao lưu: Cần thiết lập một cơ chế sao lưu theo định kỳ (ngày, tuần, tháng,…) một cách tự động, nhằm đảm bảo việc sao lưu đầy đủ các dữ liệu theo yêu cầu.

  • Nội dung sao lưu: Sao lưu hệ điều hành máy chủ. Máy chủ web, Cơ sở dữ liệu, v.v…Sao lưu thư mục và tập tin

  • Tùy nhu cầu, khả năng hỗ trợ chi phí để lựa chọn giải pháp sao lưu phù hợp.

  • Việc phục hồi tuân theo các cơ chế:

  • Khôi phục nguyên trạng hệ thống

  • Khôi phục từng phần riêng biệt (hệ điều hành, cơ sở dữ liệu, các ứng dụng khác).

  • Thường xuyên kiểm tra bản sao lưu, phục hồi nhanh chóng.

  • Trên đây là một số phương pháp, ý tưởng liên quan đến quy hoạch hệ thống ứng dụng web. Tùy thuộc vào hoàn cảnh, chi phí mà cán bộ thiết kế/quy hoạch lựa chọn giải pháp phù hợp, đảm bảo an toàn thông tin.

3.  Phương pháp xây dựng/thiết kế hệ thống web an toàn

  • Mục này tập trung trình bày vào việc thiết kế một ứng dụng web an toàn. Việc thiết kế an toàn nhằm mục đích sau:

  • Biết được các mối đe dọa đối với ứng dụng web, đảm bảo chắc chắn những mối đe dọa này được giải quyết trong thiết kế của ứng dụng.

  • Khi quá trình thiết kế ứng dụng, có cách tiếp cận hệ thống đến các thành phần của ứng dụng dễ bị tấn công. Tập trung vào việc xem xét triển khai; xác nhận đầu vào, xác thực và ủy quyền; mật mã và dữ liệu nhạy cảm, cấu hình, phiên, và quản lý ngoại lệ.

  • Về cơ bản, thiết kế một ứng dụng web an toàn sẽ tuân theo 2 nguyên tắc chính:

  • Giảm các attack surface: giảm các mặt tiếp nối với bên ngoài có thể tạo ra một cuộc tấn công. Thực hiện nguyên tắc này theo triết lý “đặc quyền tối thiểu”. Có nghĩa là ứng dụng cần gì thì cấp cho cái đó, không nhiều hơn những gì mà ứng dụng cần. Việc tồn tại thành phần thừa, thành phần không cần thiết sẽ tạo ra nhiều “cửa” cho kẻ tấn công khai thác. Rõ ràng một ngôi nhà có 1 cửa vào duy nhất sẽ an toàn hơn là có nhiều cửa sổ.

  • Sử dụng threat modeling: Phương pháp này dựa trên phân tích các sự đe dọa đối với ứng dụng web. Để từ đó thiết kế lên một ứng dụng có khả năng chống lại các nguy cơ, đe dọa đó. Để làm được phương pháp này người thiết kế phải có tư duy nhìn thấy được các nguy cơ của ứng dụng, để rồi từ đó lựa chọn ra giải pháp thiết kế phù hợp. 

  • Tài liệu tập trung trình bày nguyên tắc thứ 2: sử dụng threat modeling để thiết kế hệ thống an toàn. Phương pháp giảm attack surface sẽ thiên về phần quy hoạch, hạ tầng hệ thống hơn (đã được trình này trong phần trên).

3.1 Kiến trúc và thiết kế ứng dụng web

  • Bản chất của giao thức HTTP là giao thức phi trạng thái – statesless. Có nghĩa là cho phép mỗi người dùng trở thành một thành phần của ứng dụng. Do đó, ứng dụng web phải làm thế nào đó nhận biết được người dùng bằng xác sử dụng một số hình thức  xác thực. Giả sử cơ chế xác thực là tốt, là an toàn, xác thực đúng người dùng thì việc quản lý phiên được sử dụng theo dõi người dùng là vô cùng quan trọng. Thiết kế chứng thực an toàn và cơ chế quản lý phiên làm chỉ là một vài trong những vấn đề phải đối mặt với các nhà thiết kế ứng dụng web và các nhà phát triển. Những vấn đề khác xảy ra như đầu vào và đầu ra dữ liệu đi qua các mạng công cộng. Ngăn chặn thao tác tham số và việc tiết lộ dữ liệu nhạy cảm là vấn đề hàng đầu khác.

  • Một số vấn đề cần giải quyết được thể hiện trong hình sau:

Hình 35: Các vấn đề cần giải quyết khi thiết kế

  • Hướng dẫn thiết kế trong phần này tập trung vào các loại lỗ hổng – nguy cơ – mối đe dọa mà ứng dụng web dễ bị tổn thương khi mắc phải. Kinh nghiệm cho thấy, khi thiết kế kém tại những vị trí này sẽ dẫn đến lỗ hổng bảo mật. Bảng tiếp theo liệt kê các loại lỗ hổng bảo mật dễ bị tổn thương, từ đó làm  nổi bật các vấn đề do thiết kế không tốt.

Loại lỗ hổng

Vấn đề do thiết kế không tốt

Input Validation

Cho phép kẻ tấn công truyền mã độc vào query strings, form fields, cookies và HTTP header. Bao gồm các các lỗi command execution, cross-site scripting (XSS), SQL injection, và buffer overflow attacks.

Authentication

Tấn công giả mật, phá mật khẩu, ưu tiên trái phép

Authorization

Truy cập vào dữ liệu bí mật hoặc bị hạn chế, giả mạo, và thực hiện các hoạt động trái phép.

Configuration Management

Truy cập trái phép vào giao diện quản lý, khả năng cập nhật dữ liệu cấu hình và truy cập trái phép vào tài khoản người dùng, hồ sơ tài khoản

Dữ liệu nhạy cảm

Tiết lộ thông tin bí mật và dữ liệu giả mạo.

Session Management

Bắt session identifiers trong phiên, giả mạo danh tính.

Cryptography

Truy cập vào thông tin bí mật, tài khoản hoặc cả hai

Parameter Manipulation

Path traversal attacks, command execution, vượt qua cơ chế bảo mật, từ đó dẫn đến lộ thông tin, leo thang đặc quyền, từ chối dịch vụ.

Exception Management

Từ chối dịch vụ, để lộ thông tin nhạy cảm

Auditing and Logging

Không có khả năng phát hiện các dấu hiệu của sự xâm nhập, không có khả năng để chứng minh hành động của người dùng, và những khó khăn trong chẩn đoán vấn đề.

  • Trong giai đoạn thiết kế ứng dụng, bạn nên xem lại chính sách bảo mật của công ty bạn và các thủ tục cùng với cơ sở hạ tầng ứng dụng của bạn sẽ được triển khai trên. Thông thường môi trường mục tiêu là cố định, và thiết kế ứng dụng của bạn phải xử lý vấn đề đó. Đôi khi sự cân bằng thiết kế được yêu cầu. Xác định hạn chế đầu trong giai đoạn thiết kế để tránh những bất ngờ sau và liên quan đến các thành viên của mạng lưới cơ sở hạ tầng và đội để giúp quá trình này.

Hình 36: Các khía cạnh cần quan tâm trong thiết kế an toàn

  • Security Policies and Procedures: Chính sách an ninh xác định những gì ứng dụng được phép làm và những gì người sử dụng của ứng dụng được phép làm. Quan trọng hơn, xác định các hạn chế để ứng dụng và người sử dụng không được phép làm. Xác định và làm việc trong khuôn khổ quy định của chính sách bảo trong khi thiết kế các ứng dụng để chắc chắn rằng không vi phạm chính sách. Không những thế có thể ngăn chặn nguy cơ đối với ứng dụng đang được triển khai.

  • Network Infrastructure Components: Chắc chắn rằng hiểu được cấu trúc mạng được cung cấp, hiểu các yêu cầu bảo mật cơ bản của mạng lưới về các quy tắc lọc, hạn chế cổng, giao thức hỗ trợ…  Trong đó cần xác định cách tường lửa và các chính sách tường lửa có khả năng ảnh hưởng đến thiết kế và triển khai ứng dụng của bạn. Có thể có tường lửa để tách các ứng dụng Internet phải đối mặt từ mạng nội bộ. Có thể có thêm tường lửa ở phía trước của cơ sở dữ liệu. Đây có thể ảnh hưởng đến kết nối của bạn.

  • Ở giai đoạn thiết kế, xem xét những gì các giao thức, cổng, và các dịch vụ được phép truy cập tài nguyên nội bộ từ các máy chủ web trong mạng biên – vành đai. Cũng xác định các giao thức và cổng mà các thiết kế ứng dụng yêu cầu và phân tích các mối đe dọa tiềm năng xảy ra từ việc mở cảng mới hoặc sử dụng các giao thức mới. Trao đổi và ghi lại bất kỳ giả định về mạng và bảo mật lớp ứng dụng và thành phần nào sẽ xử lý gì. Điều này tránh một vấn đề kiểm soát an ninh bị bỏ qua khi cả hai đội phát triển mạng và đội khác cho rằng đang giải quyết vấn đề này. Chú ý đến việc bảo vệ an ninh ứng dụng của bạn dựa vào các thành phần do hệ thống mạng cung cấp. Xem xét các tác động của sự thay đổi trong cấu hình mạng. Bao nhiêu cấu hình an ninh đã bị mất nếu thực hiện một thay đổi mạng cụ thể?

  • Deployment Topologies: Nếu bạn có một lớp ứng dụng từ xa, bạn cần phải xem xét làm thế nào để an toàn mạng giữa các máy chủ để giải quyết các mối đe dọa nghe trộm mạng và cung cấp bảo mật và tính toàn vẹn cho dữ liệu nhạy cảm. Thông thường sẽ lưu nhận dạng và xác định các tài khoản sẽ được sử dụng để xác thực mạng khi ứng dụng kết nối với máy chủ từ xa. Một phương pháp phổ biến là sử dụng một tài khoản đặc quyền ít nhất và tạo một tài khoản trùng lặp (nhân đôi) trên các máy chủ từ xa với cùng một mật khẩu. Ngoài ra, bạn có thể sử dụng tài khoản domain, quản lý dễ dàng hơn nhưng sẽ có vấn đề vận hành vì những khó khăn hạn chế sử dụng của tài khoản trên toàn mạng. 

3.2 Input Validation

  • Kiểm tra dữ liệu đầu vào là vấn đề khó khăn chính mà bất kỳ nhà phát triển phần mềm nào cũng sẽ gặp phải khi xây dựng phần mềm. Tuy nhiên, kiểm tra đầu vào là phương pháp chính tốt nhất chống lại các cuộc tấn công ngày nay. Kiểm tra đầu vào là một biện pháp phòng chống có hiệu quả giúp ngăn ngừa XSS, SQL injection, lỗi tràn bộ đệm, và các cuộc tấn công liên quan đến dữ liệu đầu vào khác.

  • Việc kiểm tra đầu vào là một việc khó mà không thể có một câu trả lời chung cho tất cả các hệ thống ứng dụng web. Tương tự, sẽ không có định nghĩa thế nào là một đầu vào chứa mã độc. Sau đây là một số biện pháp dùng để nâng cao chất lượng kiểm tra đầu vào khi thiết kế:

  • Coi tất cả đầu vào đều là độc hại: Kiểm tra tất cả đầu vào với giả thiết rằng tất cả đầu vào đều chứa mã tấn công độc hại. Liệu đầu vào từ một ứng dụng khác, người dùng, chia sẻ file… có thực sự được tin tưởng. Ví dụ, yêu cầu một trang web bên ngoài trả về một chuỗi kết quả. Có cách nào chắc chắn chuỗi trả về không chứa mã độc ? Ngoài ra, khi ứng dụng truy xuất lấy dữ liệu từ một cơ sở dữ liệu dùng chung, có chắc rằng ứng dụng khác có quyền ghi vào cơ sở dữ liệu đó không chứa mã độc, cơ sở dữ liệu đó an toàn ?

  • Cơ chế kiểm tra tập trung: Sử dụng việc lọc dữ liệu như là một thành phần trong lõi core của phần mềm. Xem xét đến việc sử dụng tập trung, kết hợp giữa lọc thông thường và các bộ thư viện chia sẻ chung. Điều đó sẽ giúp việc lọc được nhất quán giữa các thành phần. Điều đó giúp làm giảm công sức trong phát triển và giúp bảo trì trong tương lai. Trong một số trường hợp cụ thể, mang tính cá nhân hóa như: email, số điện thoại, zip code thì có thể sử dụng cách tiếp cận sau:

Hình 37: Cơ chế kiểm tra tập trung

  • Không phụ thuộc vào việc kiểm tra phía người dùng (client-site validation): Phía server sẽ kiểm tra đầu vào theo cách của server. Nếu kẻ tấn công vượt qua được cơ chế kiểm tra dưới client (ví dụ như tắt Javascript) thì sẽ ra sao ? Sử dụng kiểm tra phía client sẽ giảm bớt cho phía máy chủ, tuy nhiên nó không phải là phương pháp có chiều sâu. Tất cả phải thực hiện phía server.

  • Sử dụng dữ liệu ở dạng chuẩn nhất, cơ bản nhất: Canonicalization là thuật ngữ mô tả quá trình chuyển dữ liệu sang dạng canonical, được mô tả như dạng mã hóa url, hex encode để khác so với bình thường. Đường dẫn tập tin và URL dễ bị tấn công nếu như sử dụng trực tiếp. Thông thường, tránh sử dụng các dữ liệu đầu vào như tên file để tránh các vấn đề này. Nếu sử dụng phải đảm bảo chúng được kiểm tra nghiêm ngặt, chỉ được truy cập vào các tập tin đã được chỉ định.

  • Hạn chế, từ chối, chặn lọc đầu vào: Phương pháp tốt nhất để kiểm tra đầu vào là chỉ cho phép những dữ liệu bạn cảm thấy an toàn (white list). Cách này sẽ dễ dàng hơn là việc kiểm tra đầu vào hợp lệ, phân tích mẫu, tìm kiếm các ký tự “bad character”. Khi thiết kế, xác định những kiểu dữ liệu mà ứng dụng mong muốn nhận về. Chắc chắn tập các dữ liệu này sẽ hữu hạn, ít hơn tập có thể chứa mã độc tấn công.  Tuy nhiên, nếu chiến lược có chiều sâu hơn thì bạn nên quan tâm đến việc từ chối các ký tự bad, santize  đầu vào. Có thể thực hiện theo chiến lược sau:

Hình 38: Chiến lược: Constrain, Reject, Sanitize

  • Chiến lược này được mô tả như sau: 

  • Constrain Input: Hạn chế đầu vào, chỉ cho phép các dữ liệu “good”. Ý tưởng là sử dụng bộ lọc theo: Kiểu (type), độ dài dữ liệu, format, phạm vi. Định nghĩa dữ liệu mong muốn, nếu ngoài loại đó, đều là dữ liệu xấu. Kết hợp sử dụng Validate Data for Type đối với các dạng đặc biệt như email, số điện thoại cũng được coi là một Constrain Input.

  • Reject Known Bad Input: Loại bỏ tất cả dữ liệu “bad”. Phương pháp này sẽ không hoàn hảo như phương pháp trên. Nó đòi hỏi phải giả thiết tất cả dữ liệu đều chứa mã độc, cần phải xử lý. Để xử lý được, đòi hỏi ứng dụng phải được thiết kế “biết” được tất cả các biến thể của mã độc hại.

  • Sanitize Input: Sanitizing làm cho dữ liệu độc hại có thể trở lên an toàn. Điều này có ích khi không thể đảm bảo dữ liệu là an toàn. Một ví dụ là sử dụng HTML encode để lọc dữ liệu như là dạng văn bản thường chứ không phải là mã thực thi. 

3.3 Authentication

  • Authentication là quá trình xác định người dùng. Đa số ứng dụng web sử dụng username/password để xác định người dùng qua HTML form. Vấn đề đó sẽ đặt ra những câu hỏi sau đây:

  • Username/password được gửi dạng rõ trên kênh truyền không an toàn? Nếu như vậy kẻ tấn công có thể chặn bắt lấy username/password của người dùng. Một giải pháp đó là sử dụng SSL/HTTPS

  • Thông tin bí mật, nhạy cảm được lưu trữ thế nào ? Nếu đang lưu trữ tên người dùng và mật khẩu trong bản rõ, hoặc trong các tập tin hoặc trong một cơ sở dữ liệu thì đó là một vấn đề: Nếu thư mục ứng dụng cấu hình không đúng và một kẻ tấn công có thể duyệt các tập tin và tải về nội dung của nó hoặc thêm một tài khoản đăng nhập có đặc quyền mới? Nếu một quản trị viên bất mãn có cơ sở dữ liệu của gồm username và password? 

  • Làm thế nào để xác minh thông tin: Không cần thiết phải lưu dạng rõ của mật khẩu nếu chỉ để xác minh. Có thể sử dụng hash để và tính toán dựa trên giá trị người dùng cung cấp để xác minh. Để chống lại dictionary attack, yêu cầu sử dụng mật khẩu mạnh kết hợp sử dụng salt.

  • Làm thế nào để xác thực người dùng đã đăng nhập ? Thông thường sẽ sử dụng authentication cookie, nhưng authentication cookie sẽ được truyền như thế nào ? Một cookie bị đánh cắp thì phiên đăng nhập sẽ bị đánh cắp.

  • Để giải quyết trên những câu hỏi trên, người thiết kế có thể sử dụng một số giải pháp sau:

  • Separate Public and Restricted Areas: Một vùng public được truy cập bởi người dùng bất kỳ. Khu vực hạn chế chỉ được truy cập bởi cá nhân cụ thể, và phải được xác minh. Bằng cách phân chia làm khu vực công cộng và hạn chế, ứng dụng có thể áp dụng các quy tắc riêng biệt khác nhau và hạn chế phải sử dụng SSL mã hóa kênh truyền cho người dùng đã xác thực. 

  • Use Account Lockout Policies for End-User Accounts: Disable account nếu như đăng nhập sai một số lần nhất định. Nếu sử dụng NTLM hay Kerberos trong Windows thì có thể sử dụng ngay trong hệ điều hành. Đối với các ứng dụng web khác, chính sách này phải được đưa vào thiết kế của ứng dụng. Lưu ý cần tránh kẻ tấn công sử dụng điều này để tấn công từ chối dịch vụ, khóa tài khoản người dùng hợp pháp. Giải pháp sử dụng CAPTCHA là phù hợp trong trường hợp này.

  • Support Password Expiration Periods: Password không phải tĩnh và nên được thay đổi thường xuyên. Vấn đề này cần được đưa vào trong thiết kế.

  • Be Able to Disable Accounts: Nếu hệ thống bị xâm nhập, có thể sử dụng thiết kế này để tránh các tấn công không mong muốn.

  • Do Not Store Passwords in User Stores: Như đã nói ở trên, nếu chỉ cần xác mình người dùng thì nên lưu mật khẩu dạng hash kết hợp sử  dụng salt.

  • Require Strong Passwords: Để tránh tấn công crack password thì phải sử dụng mật khẩu mạnh. Mật khẩu mạnh là mật khẩu có độ dài tối thiểu 8 ký tự, kết hợp chữ hoa chữ thường số và ký tự đặc biệt.

  • Do Not Send Passwords Over the Wire in Plaintext: Gửi mật khẩu qua kênh không mã hóa hoàn toàn có thể bị nghe lén. Sử dụng SSL làm một giải pháp mã hóa kênh truyền.

  • Protect Authentication Cookies: Cookie bị đánh cắp là phiên đăng nhập bị đánh cắp, do đó cần bảo vệ kênh truyền cookie. Cũng cần hạn chế thời gian cookie có giá trị để chống tấn công giả mạo. 

3.4 Authorization

  • Authorization là quá trình xác định những tài nguyên, chức năng nào được phép truy cập. Nếu quá trình cấp quyền không đúng dẫn đến lộ thông tin, leo thang đặc quyền. Phòng thủ theo chiều sâu là phương pháp áp dụng để phòng chống các lỗi liên quan đến cấp quyền. Có thể thực hiện các biện pháp sau:

  • Use Multiple Gatekeepers: Sử dụng nhiều lớp bảo mật. Có thể sử dụng IPSec – Firewall giới hạn các địa chỉ có thể truy cập vào ứng dụng. Sử dụng các tính năng của web server để giới hạn quyền truy cập vào ứng dụng web, DNS tương ứng. Cuối cùng, ứng dụng web giới hạn truy cập vào các tài nguyên. Kết hợp nhiều lớp bảo vệ sẽ mang lại hiệu quả mong muốn.

  • Restrict User Access to System Level Resources:  Phân cấp các tài nguyên được phép truy cập. Sử dụng ACL để hạn chế người dùng truy cập vào các tài nguyên chức năng mà họ không có quyền truy cập.

3.5 Configuration Management

  • Cẩn thận xem xét thành phần quản trị của ứng dụng. Hầu hết các ứng dụng đều có giao diện cho quản trị trị cấu hình các ứng dụng và quản lý các hạng mục như nội dung trang Web, tài khoản người dùng, hồ sơ thông tin người dùng, chuỗi kết nối cơ sở dữ liệu. Nếu quản trị được hỗ trợ, như thế nào là giao diện quản trị bảo đảm? Hậu quả của việc này là nghiêm trọng, bởi vì những kẻ tấn công thường xuyên kết thúc chạy với quyền quản trị và có thể truy cập trực tiếp đến toàn bộ trang web. Có thể thực hiện các biện pháp sau:

  • Secure Your Administration Interfaces: Điều quan trọng là giao diện quản trị chỉ được truy cập bởi quản trị, quản lý có quyền. Có thể sử dụng xác thực mạnh, ví dụ xác thực hai nhân tố trở lên. Nếu có thể, tránh đăng nhập từ xa và chỉ đăng nhập từ mạng nội bộ. Nếu cần đăng nhập từ xa thì sử dụng giải pháp SSL VPN.

  • Secure Your Configuration Stores: Text-based configuration files, registry, database là những nơi thường được sử dụng để lưu trữ cấu hình. Nếu có thể tránh sử dụng file cấu hình, tránh trường hợp tải về file cấu hình của hệ thống. Ngoài ra, tránh lưu dạng rõ các thông tin kết nối cơ sở dữ liệu, thông tin nhạy cảm. Đảm bảo việc sử dụng mã hóa, sau đó hạn chế truy cập vào những địa điểm lưu trữ này.

  • Separate Administration Privileges: Phân tách vai trò các quản trị có thể. Ví dụ, quản trị nội dung thì chỉ tương tác với các thành phần nội dung mà thôi.

  • Use Least Privileged Process and Service Accounts: Chắc chắn tài khoản sử dụng để chạy ứng dụng là tài khoản thấp nhất, ít đặc quyền nhất. Nếu kẻ tấn công có được quyền quản trị ứng dụng thì chỉ có quyền tối thiểu của hệ thống.

3.6 Sensitive Data

  • Các dữ liệu nhạy cảm như số thẻ tín dụng, địa chỉ, hồ sơ y tế phải được còn bí mật, không bị thay đổi gì. Ngoài ra, mật khẩu và kết nối cơ sở dữ liệu cũng phải được đảm bảo. Đây là vấn đề khó khi cần phải lưu trữ, lại luôn thường trực trên mạng. Có các biện pháp sau:

  • Do Not Store Secrets if You Can Avoid It: Không lưu trữ khi không dùng. Không cần dùng mật khẩu dạng rõ thì có thể lưu dưới dạng hash, tránh trường hợp quản trị, hoặc kẻ tấn công đọc được nội dung này.

  • Do Not Store Secrets in Code: Không hard code trong code, kể cả ứng dụng web được chạy trên máy chủ. Một lỗi cấu hình có thể cho phép kẻ tấn công lấy được mã nguồn ứng dụng.

  • Do Not Store Database Connections, Passwords, or Keys in Plaintext: Như đã nói ở trên, không lưu dưới dạng rõ. 

  • Sensitive Per User Data: Đảm bảo chỉ đúng người dùng đó mới có khả năng đọc được nội dung của chính mình. 

3.7 Session Management

  • Ứng dụng web xây dựng trên stateless HTTP protocol. Vì vậy quản lý phiên là việc của ứng dụng. Thực hiện các biện pháp sau:

  • Sử dụng SSL mã hóa kênh truyền. Như đã trình bày ở trên,mất cookie là mất phiên. Vì vậy phải gửi cookie qua SSL để đảm bảo Cookie sẽ được mã hóa. Khi đó, cookie phải được thiết lập cờ “secure” trong thuộc tính, để bắt buộc phải truyền qua giao thứ SSL/HTTPS

  • Giới hạn thời gian sử dụng Session.

3.8 Parameter Manipulation

  • Thay đổi HTTP header, kẻ tấn công có thể thực hiện nhiều kiểu tấn công khác nhau. Thực hiện các nguyên tắc thiết kế sau:

  • Encrypt Sensitive Cookie State: Mã hóa các Cookie nhạy cảm

  • Make Sure that Users Do Not Bypass Your Checks: Giả sử URL http://www.<YourSite>/<YourApp>/sessionId=10 có giá trị 10 bị thay đổi, hãy trả về những nội dung ngẫu nhiên khác nhau. Đảm bảo check phía Server, không phải Client.

  • Validate All Values Sent from the Client: Kiểm tra tất cả dữ liệu từ Client

  • Do Not Trust HTTP Header Information: Không tin, không sử dụng trực tiếp các thông tin nhận được trong HTTP header, ví dụ như User-Agent chẳng hạn.

3.9 Exception Management

  • Thực hiện quản lý các Exception theo các biện pháp sau đây:

  • Do Not Leak Information to the Client: Trong trường hợp xuất hiện lỗi, không để xuất hiện thông tin chi tiết về lỗi dạng debug. Đó là thông tin về dòng bao nhiêu, file nào, chức năng nào.

  • Log Detailed Error Messages: Bản ghi lỗi chỉ gửi lại thông tin tối thiểu cho người dùng. Thông thường gửi thông tin về mã lỗi, chứa ID của lỗi để từ đó ánh xạ tới lỗi mà người dùng gặp phải.

  • Catch Exceptions: Sử dụng cấu trúc ngoại lệ để tránh ứng dụng hoạt động không hiệu quả, thông báo lỗi về phía người dùng. Nó cũng giúp bảo vệ ứng dụng chống lại tấn công từ chối dịch vụ.

    1. Auditing and Logging

  • Cần thực hiện audit và ghi log ở tất cả các lớp của ứng dụng. Log phục vụ cho công tác điều tra rất tốt, sớm phát hiện ra các mối nguy hiểm và có thể được sử dụng làm bằng chứng đối với kẻ tấn công. Còn quá trình audit có thể xem là có quyền lớn nhất  nếu trong đúng thời điểm đó cũng có các thủ tục khác tiến hành truy cập tài nguyên giống nó. Để tăng cường khả năng bảo mật cho ứng dụng Web cần thực hiện các công việc sau:

  • Audit và ghi log ở các lớp của ứng dụng: Đây là một việc bắt buộc phải thực hiện. Sử dụng kết hợp giữa việc ghi log ở tầng ứng dụng và audit ở tầng platform, ví dụ như quá trình auditing của Windows, IIS, hay SQL Server.

  • Xem xét các luồng thực thể: Cần xem xét cách mà ứng dụng sẽ gọi các thực thể như thế nào thông qua các tầng/lớp khác nhau của ứng dụng. Có hai lựa chọn cơ bản. Một là các thực thể được gọi ở mức hệ điều hành thông qua giao thức Kerberos. Ở cách này có thể sử dụng được audit ở mức OS. Tuy nhiên nhược điểm của cách tiếp cận này là khả năng mở rộng, bởi vì sẽ không thể có các kết nối cơ sở dữ liệu hiệu quả chung ở lớp giữa (middle tier). Do vậy, dẫn đến việc có lựa chọn thứ hai là, các thực thể được gọi ở mức ứng dụng và sử dụng các thực thể tin cậy để có thể truy cập được vào khu vực tài nguyên quản trị (back-end). Ở cách này, buộc phải tin tưởng các lớp giữa.  Do đó nên thực hiện quan sát việc audit ở lớp giữa. Cần đảm bảo đồng bộ thời gian của server (mặc dù AD có thể làm hộ bạn việc này). 

  • Ghi log các sự kiện quan trọng: Các sự kiện nên ghi log bao gồm việc đăng nhập thành công/thất bại, thay đổi dữ liệu, sử dụng dữ liệu, giao tiếp trong mạng, và các chức năng quản trị như enable hoặc disable việc ghi log. Trong log nên có thời gian xảy ra sự kiện, vị trí của sự kiện bao gồm tên máy, định danh của người dùng hiện tại, định danh của tiến trình khởi tạo sự kiện, và mô tả chi tiết sự kiện đó.

  • Bảo mật các file log: Bảo mật các file log bằng cách sử dụng Windows ACLs và hạn chế việc truy cập các file log này. Điều này tránh việc attacker có được log file và xóa hoặc thay đổi dấu vết cuộc tấn công. Tối thiểu hóa số người có thể thao tác được với các file log. Phân quyền truy cập log cho các tài khoản tin cậy, ví dụ như tài khoản quản trị.

  • Thực hiện backup và phân tích các file log thường xuyên: Nếu không phân tích log thì việc ghi log là vô nghĩa. Các file log nên được xóa bỏ thường xuyên. Tần suất này phụ thuộc vào mức độ hoạt động của ứng dụng. Cần xem xét cách các file log sẽ được sử dụng và chuyển sang các máy chủ offline để dùng cho việc phân tích. Các giao thức và port mở thêm trên Web server để thực hiện việc đọc lại các file log cần khóa an toàn. 

  • Dựa trên ý tưởng thiết kế an toàn thông tin theo phân tích Threat Modeling, phần này đã trình bày các nguy cơ trong thiết kế đối với ứng dụng web. Bằng việc đưa ra các vấn đề, nguy cơ, phần này cũng đưa ra giải pháp thiết kế để giải quyết vấn đề đó. Trên đây là một số gợi ý trong thiết kế phần mềm.

II. Phát triển ứng dụng web an toàn

1.  Quy trình phát triển phần mềm an toàn

1.1 Tổng quan về quy trình phát triển phần mềm

  • Một số người đã cố gắng hệ thống hóa hoặc hình thức hóa các nhiệm vụ viết phần mềm vốn không tuân theo quy tắc nào cả. Một số khác áp dụng các kỹ thuật quản lý dự án để viết phần mềm. Nếu như không có quản lý dự án, thì các dự án phần mềm có thể sẽ dễ bị chuyển giao chậm hoặc vượt quá ngân sách. Với một số lượng lớn các dự án phần mềm không đáp ứng được kỳ vọng về chức năng, chi phí hoặc kế hoạch chuyển giao đã cho thấy một thực tế là do đang thiếu các phương thức quản lý dự án hiệu quả.

  • Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần mềm. Các thuật ngữ tương tự là vòng đời phần mềm và quy trình phần mềm. Đây được coi là một thành phần tập con của vòng đời phát triển hệ thống. Có một số mô hình cho việc xây dựng các quy trình này, mỗi mô hình mô tả các phương thức cũng như các nhiệm vụ hoặc thao tác cần được thực hiện trong cả quá trình. Nhiều người coi mô hình vòng đời là một thuật ngữ phạm vi rộng và quy trình phát triển phần mềm là một thuật ngữ ở mức chi tiết cụ thể hơn. Ví dụ, có rất nhiều quy trình phát triển phần mềm tuân theo mô hình vòng đời xoắn ốc. ISO/IEC 12207 là một tiêu chuẩn quốc tế cho các quy trình vòng đời phần mềm, mục đích là trở thành một tiêu chuẩn định nghĩa tất cả các công việc cần thực hiện để xây dựng và bảo trì sản phẩm phần mềm.

  • Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:

  • Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được định nghĩa.

  • Sự phát triển phần mềm: Để phần mềm đạt được đặc tả thì phải có quy trình phát triển này.

  • Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó làm những gì mà khách hàng muốn.

  • Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các yêu cầu của khách hàng.

1.2 Các mô hình phát triển sản phẩm phần mềm

  • Mô hình thác nước: Mô hình này làm cho ý nghĩa việc sản xuất phần được thấy rõ hơn. 

  • Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu được hình thành bởi sự trợ ý của hệ thống người tiêu dùng. Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người tiêu dùng.

  • Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay nhiều chương trình khả thi.

  • Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập họp nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó.

  • Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.

  • Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là pha lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì sống; nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện vê yêu cầu mới.

  • Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm - phần cứng.

  • Mô hình xoắn ốc Boehm: Đây là mô hình phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. Mô hình được đề nghị bởi Boehm vào năm 1988. Mô hình này có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quy trình (sản xuất) tổng quát. Mô hình Boehm có dạng xoắn ốc. Mỗi vòng lặp đại diện cho một pha của quy trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định nghĩa các yêu cầu, kế đến là thiết kế, ...

  • Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có 4 phần tương ứng với một pha: 

  • Cài đặt đối tượng: Chỉ ra các đối tượng của pha trong đề án. Những khó khăn hay cưỡng bức của quy trình và của sản phẩm được xác định và được lên kế hoạch chi tiết. Xác định các yếu tố rủi ro của đề án. Các phương án thay thế tùy theo các rủi ro này có thể được dự trù.

  • Lượng định và giảm thiểu rủi ro: Tiến hành phân tích mỗi yếu tố rủi ro đã xác định. Các bước đặt ra để giảm thiểu rủi ro.

  • Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình phát triển cho hệ thống được chọn.

  • Lên kế hoạch: Đề án được xem xét và quyết định có nên hay không tiếp tục pha mới trong vòng lặp.

  • Các quy trình linh hoạt: Là quy trình mà trong đó cấu trúc khởi động sẽ nhỏ nhưng linh động và lớn dần của các đề án phần mềm nhằm tìm ra các khó khăn trước khi nó trở thành vấn đề có thể dẫn tới những hủy hoại. quy trình này nhấn mạnh sự gọn nhẹ và tập trung hơn là các phương pháp truyền thống. Các quy trình linh hoạt dùng các thông tin phản hồi thay vì dùng các kế hoạch, như là một cơ chế diều khiển chính. Các thông tin phản hồi có được từ các thử nghiệm và các phiên bản phát hành của phần mềm tham gia. 

  • Các quy trình linh hoạt thưòng có hiệu quả hơn các phương pháp cũ, nó dùng ít thời gian lập trình để sản xuất ra nhiều chức năng hơn, chất lượng cao hơn, nhưng nó không cung cấp một khả năng kế hoạch lâu dài. Một cách ngắn gọn các phuơng pháp này cung ứng hiệu quả cao nhất cho vốn đầu tư, nhưng lại không định rõ hiệu quả gì.

1.3 Quy trình phát triển phần mềm 

  • Quy trình phát triển phần mềm cơ bản được xây dựng dựa trên hai bộ tiêu chuẩn  ISO 9001 – 2008 và quy trình CMMI level 3. Kết hợp cùng những yêu cầu/giải pháp thực tế trong quá trình làm việc trong quá trình xây dựng phần mềm. Quy trình được cải tiến liên tục nhằm đảm bảo tính cập nhật, phù hợp với yêu cầu thực tế.

  • Trong quy trình phát triển phần mềm, tiêu chuẩn ISO 9001 – 2008 nhằm quy định các nguyên tắc cơ bản của hệ thống tài liệu. Trong đó bao gồm quy định các tiêu chuẩn về:

  • Hệ thống quy trình

  • Tài liệu

  • Hồ sơ

  • Xem xét thẩm định

  • Quy trình áp dụng cho xây dựng các dự án, sản phẩm mới, nâng cấp các dự án sản phẩm đã có và các dự án đang triển khai. Quy trình gồm các bước chính:

  • Khởi động

  • Xây dựng giải pháp

  • Phát triển

  • Kiểm thử

  • Triển khai

  • Kết thúc


  • Bước khởi động đưa ra kế hoạch thực hiện dự án. Bao gồm:

  • Phạm vi, mục đích, thời gian thực hiện

  •  Mô hình tổ chức, trách nhiệm trong dự án

  •  Đầu mối làm việc của dự án

  •  Quy trình thực hiện của dự án (dựa trên quy trình chuẩn + Tailoring theo đặc thù dự án)

  •  Các giai đoạn, các sản phẩm, các mốc milestone chính

  •  Các công cụ thực hiện dự án 

  •  Các điều kiện đảm bảo


  • Bước xây dựng giải pháp phân tích bài toán, thống nhất yêu cầu người sử dụng. Từ đó đặc tả yêu cầu người dùng thành chức năng của chương trình làm cơ sở để thiết kế, lập trình, và kiểm thử.


  • Bước phát triển gồm ba bước chính: Thiết kế, Lập trình và Viết hướng dẫn. Thiết kế gồm thiết kế tổng thể, thiết kê cơ sở dữ liệu và thiết kế màn hình. Lập trình chương trình dựa trên các tài liệu giải pháp đã có và theo chuẩn lập trình (). Viết tài liệu gồm hướng dẫn cài đặt, hướng dẫn vận hành, hương dẫn khai thác


  • Bước kiểm thử gồm kiểm thử nội bộ và kiểm thử nghiệm thu. Kiểm thử nội bộ chương trình nhằm đáp ứng các yêu cầu đã được xác định của chương trình, dựa vào các tài liệu giải pháp, thiết kế đã có. Kiểm thử nghiệm thu với khách hàng để xác nhận sản phẩm đáp ứng đúng yêu cầu người sử dụng


  • Bước triển khai sẽ triển khai phần mềm cho khách hàng sử dụng. Thực hiện bước này có: Cán bộ kiểm thử, cán bộ phát triển và quản trị dự án. Cán bộ kiểm thử đào tạo, hướng dẫn sử dụng trên cở sở tài liệu đã viết. Cán bộ phát triển cài đặt phần mềm và phối hợp kiểm tra bảo mật chương trình. Quản trị dự án chuyển giao chương trình cho đơn vị vận hành khai thác ứng dụng.


  • Bước kết thúc tổng kết toàn bộ quá trình thực hiện dự án. Bao gồm:

  • Đưa ra bài học kinh nghiệm

  • Đánh giá kết quả thực hiện dự án

  • Lưu trữ cấu hình, hồ sơ bản giao thành tài sản của tổ chức


1.4 Quy trình phát triển phần mềm an toàn

  • Trên cơ sở quy trình phát triển phần mềm, tiến hành bổ sung các yêu cầu bảo mật, an toàn thông tin. Từ đó hoàn thiện quy trình phát triển phần mềm có bao gồm yếu tố an toàn thông tin. Về cơ bản, quy trình phát triển phần mềm an toàn bao gồm các bước chính:

  • Đào tạo

  • Phân tích yêu cầu

  • Thiết kế

  • Triển khai

  • Kiểm thử

  • Thử nghiệm

  • Bảo trì

  • Từng bước có những yêu cầu, ràng buộc về an toàn thông tin khác nhau. 

  • Bước Đào tạo: Không trực tiếp sản xuất ra sản phẩm, nhưng đây là một trong bước quan trọng nhất trong quy trình. Chất lượng, đảm bảo an toàn thông tin hay không hoàn toàn phụ thuộc vào chất lượng đào tạo. Nhân lực tham gia càng được đào tạo tốt thì chất lượng sản phẩm càng tốt.

  • Tùy từng đối tượng, nhiệm vụ trong quá trình phát triển phần mềm mà cần có đào tạo hợp lý. Căn cứ theo chức năng các thành viên trong đội dự án, việc đào tạo được chia làm các nội dung chính sau đây:

  • Khóa học cơ bản về an toàn thông: Dành cho tất cả các thành viên tham gia vào dự án. Đảm bảo tất cả thành viên phải được đào tạo về an toàn thông tin cơ bản, các nguy cơ mất an toàn thông tin đối với phát triển ứng dụng web.

  • Phân tích yêu cầu, thiết kế an toàn: Dành cho đối tượng cán bộ phân tích yêu cầu, cán bộ thiết kế phần mềm, hệ thống. Mục tiêu của việc đào tạo về các nguy cơ trong phân tích, thiết kế phần mềm. Cùng với đó là những triển khai, giải pháp thiết kế an toàn

  • Security Coding: Dành cho đối tượng lập trình viên, triển khai giải pháp, phần mềm. Hiện tại khóa học này có tên là “Lập trình an toàn trong phát triển ứng dụng web”.

  • Security Testing: Dành cho đối tượng kiểm thử, cán bộ an toàn thông tin tại các đơn vị. Hiện tại khóa học này có tên là “Quy trình đánh giá an toàn thông tin ứng dụng web”

  • Tùy từng hoàn cảnh cụ thể, việc đào tạo này sẽ có những yêu cầu về tỷ lệ thành viên tham gia, thời gian tham gia gần nhất tối thiểu cơ bản. Thông thường, tỷ lệ được Microsoft đưa là lớn hơn 80% số thành viên trong đội dự án phải tham gia. Trong đó, một năm phải được tham gia đào tạo tối thiểu 1 lần trong một năm
    (12 tháng).

  • Bước Phân tích yêu cầu: Tương tự như phân tích yêu cầu trong quy trình phát triển phần mềm, trong quy trình phát triển phần mềm an toàn sẽ tập trung vào việc phân tích, tìm ra các yêu cầu an toàn thông tin trong phần mềm. Để làm được điều này, cán bộ phân tích yêu cầu phải có tư duy về các loại lỗ hổng trong phát triển ứng dụng web (Tham khảo mục II phần 1, Lỗ hổng ứng dụng web). 

  • Cán bộ phân tích yêu cầu chủ động gợi ý, trao đổi với khách hàng về các yếu tố, yêu cầu an toàn thông tin. Ví dụ như: “Phần mềm của quý khách có cần sử dụng mật khẩu mạnh hay không ?”, “Quý khách có đầu tư việc mã hóa đường truyền hay không ?”. Việc hỏi các yêu cầu an toàn thông tin là nhạy cảm, do đó cán bộ cần có kỹ năng giao tiếp, tránh các câu hỏi trực tiếp, nhạy cảm.

  • Để đảm bảo phân tích yêu cầu đầy đủ, ngoài các câu hỏi có sẵn trong bộ câu hỏi, cán bộ nên chủ động tìm hiểu bổ sung bộ câu hỏi chuẩn. Ngoài ra, cán bộ có thể sử dụng phương pháp sau để đảm bảo phân tích yêu cầu đầy đủ:

  • Bước 1: Thiết lập các yêu cầu, ràng buộc an toàn thông tin: Xác định các yêu cầu, ràng buộc an toàn thông tin cơ bản của hệ thống (Sử dụng bộ câu hỏi có sẵn). Tương ứng với từng ứng dụng, xác định các nguy cơ, lỗ hổng bảo mật có thể mắc phải. Từ đó hoàn thiện, xây dựng mức độ an toàn tối thiểu của ứng dụng. Xây dựng mô hình các mối đe dọa đối với phần mềm.

  • Bước 2: Xây dựng yếu tố bảo mật: Xác định mức độ bảo mật chấp nhận tối thiểu. Ví dụ: “Ứng dụng có giao tiếp với cơ sở dữ liệu 🡪 Có khả năng mắc lỗi SQLinjection”. Do đó chấp nhận có khả năng mắc lỗi SQLinjection. Từ đó xác định phương pháp khắc phục, phòng tránh. Tiếp tục với ví dụ trên: “Có khả năng mắc lỗi SQLinjection 🡪 Sử dụng prepareStastement để phòng tránh”. 

  • Bước 3: Thực hiện đánh giá rủi ro bảo mật, an toàn thông tin: Không phải bất kỳ giải pháp nào cũng có thể được khách  hàng chấp nhận. Cần cân nhắc giữa yếu tố an toàn thông tin và chi phí bỏ ra. Ngoài ra, cần đánh giá khả năng tác động của giải pháp với những chức năng khác của phần mềm. Ví dụ: “Việc triển khai module mã hóa có thể ảnh hưởng tới hiệu năng của hệ thống ?”

  • Trong trường hợp các yêu cầu, gợi ý bảo mật không được khách hàng chấp nhận (sử dụng HTTPS, sử dụng mật khẩu mạnh, không ghi log …) thì cán bộ phân tích cần làm biên bản xác nhận với khách hàng.

  • Bước Thiết kế: Thiết kế an toàn giúp tránh được các nguy cơ mất an toàn thông tin (Tham khảo mục I phần 2: Quy hoạch, thiết kế ứng dụng/hệ thống web an toàn). Để đảm bảo các yếu tố an toàn thông tin trong thiết kế, tuân theo các nguyên tắc sau: 

  • Sử dụng Threat Modeling: Phân tích chức năng ứng dụng, từ chức năng xác định những nguy cơ, kịch bản có thể xảy ra đối với phần mềm. Từ đó, tương ứng với mỗi nguy cơ xác định phương pháp phòng chống phù hợp. Ví dụ: “Ứng dụng có chức năng hiển thị nội dung comment người dùng 🡪 Có khả năng mắc lỗi XSS 🡪 Sử dụng giải pháp mã hóa output để tránh XSS”

  • Giảm Attack Surface: Giảm tối đa các “bề mặt tiếp xúc” mà kẻ tấn công có thể thực hiện được khai thác. Việc giảm các attack surface tuân theo nguyên tắc hạn chế các dịch vụ, truy cập vào hệ thống. Sử dụng nguyên lý “đặc quyền tối thiểu” và “bảo vệ bất cứ nơi nào”. Có nghĩa là: Chỉ dùng khi thật sự cần thiết, ví dụ “nếu không cần chức năng gì thì không cần sử dụng, để chức năng đó tồn tại”.

  • Bước Triển khai: Thực hiện theo Guide Line lập trình an toàn trong phát triển ứng dung web (Tham khảo mục II.2 phần 2: Lập trình an toàn trong phát triển ứng dụng web). Trong đó tập trung theo các nguyên tắc:

  • Kiểm soát đầu vào và đầu ra, các thao tác giao tiếp với cơ sở dữ liệu, file. 

  • Không được tin (trust) bất kỳ dữ liệu nào từ phía người dùng.

  • Không sử dụng các hàm, thư viện nguy hiểm. Việc sử dụng các thư viện, third party cần phải có sự giảm sát, cảnh báo khi có sự cố. Các hàm nguy hiểm là các hàm có lỗi về an toàn thông tin, hàm tương tác trực tiếp với database, hệ thống, file. 

  • Kết thúc mỗi giai đoạn phải có bước review code. Việc review code có  thể thực hiện kiểu “kiểm tra chéo” hoặc do đơn vị độc lập. Tuyệt đối không tự review code. Việc kiểm chéo code nhằm đảm bảo tất cả phải thực hiện theo Guide Line lập trình an toàn.

  • Bước Kiểm thử: Kiểm thử an toàn thông tin do một đơn vị độc lập với đội phát triển thực hiện. Việc thực hiện phải đảm bảo toàn diện, gồm hai bước sau:

  • Kiểm tra động: Thực hiện kiểm tra an toàn thông tin ứng dụng, sử dụng ứng dụng thực tế (đã được build) nhằm tìm các lỗi liên quan đến quản lý phiên, session, phân quyền…

  • Kiểm tra bằng Fuzzing: Sử dụng phương pháp Fuzzing nhằm xác định khả năng mắc các lỗi liên quan đến data validation (kiểm tra dữ liệu đầu vào – đầu ra)

  • Rà soát lại Attack Surface: Kiểm tra lại các mặt kết nối, các chức năng nhằm giảm tối đa attack surface. Bao gồm kiểm tra an toàn thông tin cho webserver, máy chủ OS, mô hình thiết kế.

  • Bước Thử nghiệm, Vận hành: Xây dựng kế hoạch thử nghiệm phần mềm với khách hàng. Phần mềm sau trước khi giao cho khách hàng sử dụng phải được bộ phận an toàn thông tin kiểm tra.

  • Trong quá trình vận hành, cần phải liên tục bảo trì, cập nhật các bản vá bảo mật. Xây dựng quy trình xử lý sự cố là cần thiết.

2.  Lập trình an toàn trong phát triển ứng dụng web  

  • Là một trong những bước của quy trình phát triển phần mềm, trực tiếp sản xuất ra sản phẩm. Đây là bước trực tiếp triển khai những giải pháp, phương pháp phòng tránh lỗ hổng an toàn thông tin trong ứng dụng web. Nhằm mục tiêu xây dựng ứng dụng web an toàn, lập trình an toàn thực hiện tại:

  • Kiểm soát dữ liệu đầu vào

  • Kiểm soát dữ liệu đầu ra

  • Kiểm soát truy vấn database

  • Kiểm soát thao tác với File

  • Các lỗi khác

2.1 Kiểm soát dữ liệu đầu vào

  • Nguy cơ: Dữ liệu do người dùng nhập vào đều được truyền lên server. Do đó, mọi cuộc tấn công đều phải thông qua dữ liệu đầu vào. Điều đó dẫn đến nguy cơ mắc các lỗi về an toàn thông tin như: SQL Injection, XSS (Cross Site Scripting) , CSRF (Cross Site Request Forgery), Path Traversal, lỗi phân quyền. Chính vì thế cần phải kiểm soát đầu vào dữ liệu gửi lên từ phía người dùng.

  • Việc kiểm soát dữ liệu đầu vào được thực hiện như sau:

  • Chỉ chấp nhận dữ liệu hợp lệ: Dữ liệu đưa vào chỉ là những loại dữ liệu được cho phép, không chấp nhận những dữ liệu không hợp lệ, chứa mã tấn công, mã khai thác hay có hành động nguy hiểm, ảnh hưởng đến an toàn thông tin hệ thống.

  • Kiểm tra phía server là cần thiết: Không bao giờ được tin tưởng vào dữ liệu người dùng, dù là người dùng trên mạng Internet hoặc người dùng nội bộ. Bất kỳ dữ liệu nào từ người dùng cũng đều phải được kiểm tra, xử lý trước khi đưa vào trong ứng dụng trực tiếp sử dụng, tương tác.

  • Kết hợp các tiêu chuẩn kiểm tra: Một dữ liệu đầu vào có thể là đầu vào của nhiều loại tấn công, có thể vừa là SQLinjection vừa là XSS. Chính vì thế việc kiểm tra phải thực hiện kết hợp, đầy đủ các tiêu chuẩn.

  • Kiểm tra độ dài xâu là tiêu chuẩn nhanh và hiệu quả: Thông thường mã tấn công thường khá dài, do phải sử dụng nhiều kỹ thuật, mã hóa. Việc hạn chế độ dài dữ liệu đầu vào cũng hạn chế được phần nào khả năng khai thác thành công. 

2.2 Kiểm soát dữ liệu đầu ra

  • Nguy cơ: Dữ liệu từ phía server sẽ được trả về cho người dùng dưới dạng HTML. Dữ liệu trả về này có thể là Form cho người dùng nhập, nội dung trang web, kết quả truy vấn database, kết quả tương tác của người dùng. Nếu như quá trình hiển thị dữ liệu ra HTML không được xử lý thì có thể hiển thị ra các mã độc Javascript do người dùng đệ trình lên không xử lý, lọc, gây ra lỗi Cross-site-scripting.

  • Biện pháp: Để phòng tránh các lỗi do không kiểm soát đầu ra, cần lọc các ký tự đặc biệt trước khi hiển thị cho người dùng dưới dạng output. Encode dưới dạng HTML các ký tự đặc biệt do người dùng gửi lên máy chủ và các ký tự đặc biệt trong cơ sở dữ liệu trước khi gửi tới người dùng. Encode dưới dạng HTML các ký tự đặc biệt do client gửi đến bao gồm: <,>,&,’,”,/ trong các trường hợp

  • Dữ liệu client gửi lên máy chủ

  • Dữ liệu lấy ra từ database khi trả về cho client

  • Bản chất của việc encode là thay thế các kí tự trên bằng chuỗi tương ứng trong bảng bên dưới:

STT

Ký tự

HTML

1

&quot;

2

&amp;

3

&#x27;

4

&#x2F;

5

&lt;

6

&gt;

  • Khi in các tham số ra HTML trong trang JSP sử dụng các hàm an toàn:

Hàm bị lỗi

Hàm an toàn

Grid: escapeHTMLInData="false"

escapeHTMLInData="true"

${var}

${fn:escapeXml(var)}

<%=var%>

<%=StringEscapeUtils.escapeHtml(var)%>

out.print(var)

out.print(StringEscapeUtils.escapeHtml(var))

  • Ví dụ: 

Hình 43: Đoạn code mắc lỗi XSS

Hình 44: Đoạn code phòng chống lỗi XSS

  • Ví dụ: Trang jsp bên dưới hiển thị lên lời chào với tên người dùng được lấy từ client

<html>

    <head>

        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

        <title>JSP Page</title>

    </head>

    <body>

        <% 

            String user = request.getParameter("user");

            request.setAttribute("user", user);

        %>

      <h1>Hello ${user} !</h1>

    </body>

</html>

<%@taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"%>

<html>

    <head>

        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

        <title>JSP Page</title>

    </head>

    <body>

        <% 

            String user = request.getParameter("user");

            request.setAttribute("user", user);

        %>

      <h1>Hello ${fn:escapeXml(user)} !</h1>

    </body>

</html>

2.3 Kiểm soát truy vấn database

  • Nguy cơ: Cơ sở dữ liệu là trái tim của ứng dụng. Đối với các ứng dụng ngày nay, truy vấn cơ sở dữ liệu là thao tác chủ yếu, thao tác chính trong ứng dụng web. Có hai dạng ngôn ngữ truy vấn chính là SQL và HQL. Việc tạo câu truy vấn không an toàn bằng cách công xâu có thể dẫn đến lỗi SQL injection như ở trong phần trên. Khi truy vấn tới cơ sử dữ liệu lập trình viên thường sử dụng cách cộng xâu Input từ người dùng, các câu truy vấn này có thể bị mắc lỗi SQL Injection hoặc HQL Injection (nếu sử dụng Hibernate). Bằng việc lợi dụng các lỗi này, kẻ tấn công có thể xem, thêm, sửa, xóa dữ liệu trong database từ đó chiếm được tài khoản admin, lấy cắp thông tin người dùng...

  • Ngoài ra, việc tổ chức cơ sở dữ liệu không tốt, không triển khai mã hóa thông tin nhạy cảm trong cơ sở dữ liệu có thể để lộ, thất thoát thông tin quan trọng.

  • Biện pháp: Để phòng tránh lỗi SQLinjection nên sử dụng phương pháp gán tham số cho các câu truy vấn database. Dữ liệu từ người dùng phải được truyền dưới dạng tham số không được sử dụng cách cộng xâu trong các truy vấn tới cơ sở dữ liệu. Cụ thể là:

  • Truy vấn SQL phải dùng PrepareStatement, tất cả tham số phải được add bằng hàm(  setParam..), không được xử dụng cách cộng xâu trong truy vấn.

  • Truy vấn SQL tất cả tham số phải được add bằng hàm( setParam..), không được xử dụng cách cộng xâu trong truy vấn.

  • Với một số trường hợp sử dụng ORDER BY không thể dùng được hàm setParam thì có thể định nghĩa một mảng chứa toàn bộ các column (field) cần ORDER BY gọi là whitelist. Mỗi khi cần ORDER BY thì kiểm tra lại xem column(field) đó có thuộc mảng whitelist đã định nghĩa không.

  • Đối với mã hóa cơ sở dữ liệu, cần phải mã hóa các dự liệu nhạy cảm trong cơ sở dữ liệu. Đối với các hàm mã hóa 1 chiều phải có thêm salt khi thực hiện mã hóa (salt là dữ liệu thêm vào plain text trước khi mã hóa)

  • Nguyên lý: hash = encrypt(salt + pass)

  • Ví dụ: encryptPass = SHA1(“ttpmdn” + pass)

  • Ví dụ:

Hình 45: Tấn công SQLinjection

Hình 46: Đoạn code mắc lỗi SQLinjection

Hình 47: Đoạn code sau lập trình an toàn sử dụng prepareStatement

  • Ví dụ: Đoạn code kiểm tra đăng nhập với username/password do người dùng nhập vào

String sql = "select * from users where user_name = '" + userName

        + "' and password = '" + encrypt(password) + "'";

Statement statement = connection.createStatement();

ResultSet rs = statement.executeQuery(sql);

if (!rs.next()) {

bResult = false;

} else {

bResult = true;

}

  • Nhập vào username là test’ or ‘1’=‘1 thì câu query sẽ là: select * from users where user_name=‘test’ or ‘1’=‘1’ and password=‘...’. Mệnh đề where sẽ tương đương với user_name = ‘test’. Như vậy dù không có password vẫn đăng nhập được vào hệ thống.

  • Đoạn code bên dưới, username,password được tham số hóa khi đưa vào câu truy vấn nên tránh được lỗi SQL Injection:

String sql = "select * from users where user_name = ? and password = ?";

PreparedStatement statement = connection.prepareStatement(sql);

statement.setString(0, userName);

statement.setString(1, encrypt(password));

ResultSet rs = statement.executeQuery(sql);

if (!rs.next()) {

     bResult = false;

} else {

     bResult = true;

}

  • Ví dụ: Một số trường hợp không thể ngăn chặn được lỗi SQL injection qua lệnh "order by". Do không sử dụng được hàm setParam có thể sử dụng phương pháp sau:

// Mảng lưu danh sách các column (field) của BO cần order by (hay gọi là whitelist)

private static List columnSort = new ArrayList();

public static String getColumnSort(String sortField) {

               // Thực hiện 1 lần và lấy ra toàn bộ mảng column cần order và  add vào whitelist

if (columnSort.size() == 0) {

// Danh sách BO cho phép order by

String[] arrTableName = {"ActionLog",

"BanPosition",

"Category",

........

};

// Lấy ra toàn bộ các column (field) BO cần order by

for (String tableName : arrTableName) {

try {

Class cls = Class.forName("com.demo.DEMOATTT.database.BO." + tableName);

Field[] fieldArr = cls.getDeclaredFields();

for (int i = 0; i < fieldArr.length; i++) {

String fieldName = fieldArr[i].getName();

// add các column vào 1 mang

columnSort.add(fieldName);

}

} catch (ClassNotFoundException ex) {

}

}

}

// Cắt ký tự "-" ở đầu field sort

String sort = sortField;

if (sortField != null && sortField.startsWith("-")) {

sortField = sortField.substring(1);

}

// Kiểm tra field cần order by có nằm trong danh sách field cho phép sort hay không

              if (sortField != null && columnSort.contains(sortField)) {

return sort;

return null;

}

Hình 48: Mã hóa không sử dụng salt

2.4 Kiểm soát thao tác với File

  • Nguy cơ: Các thao tác đọc ghi, upload file nếu không xử lý tốt có thể dẫn đến các lỗi liên quan đến xử lý file như: File Upload, File Inclusion, Path Traversal. Các ký tự đặc biệt có thể ảnh hưởng đến phần xử lý tên file như:

  • Xử lý lấy phần mở rộng của file không tốt

  • Chứa xâu ../ hoặc ..\ đẫn đến thư mục cha

  • Chứa ký tự NULL (%00) kết thúc xâu của đường dẫn

  • Biện pháp: Để xử lý các lỗi File Inclusion hay Path Traversal, các phòng chống tốt nhất là chặn các ký tự đặc biệt trong tên file

  • Đối với lỗi File Upload, để đảm bảo File upload an toàn thì phải kiểm tra chặt phần mở rộng của file (sử dụng các API hỗ trợ) kết hợp với xử lý các ký tự đặc biệt trong file. Nên kết hợp với kiểm tra nội dung file xem có đúng định dạng hay không.

  • Phần filename ban đầu người dùng upload lên server phải bỏ đi, dùng 1 chuỗi mới ngẫu nhiên thay thế cho tên file. Tên này được sinh ra ngẫu nhiên không được dùng các thuật toán md5, sha256... Thay vào đó có thể sử dụng các hàm sinh chuỗi ngẫu nhiên có sẵn trong ngôn ngữ lập trình để sinh ra tên.

  • Ví dụ:

Hình 49: Đoạn code mắc lỗi thao tác với File

Hình 50: Đoạn code an toàn khi thao tác với file

  • Ví dụ 1: Tạo tên file cho file ảnh định dạng jpg với hàm UUID có sẵn như sau.

#!/usr/bin/env python

import uuid

filename='%032x' % uuid.uuid4() + ".jpg"

  • Tên file ban đầu là shell.php.jpg upload lên server thì đổi thành 6817c84abd3d4c9abfee21a01cb39b98.jpg

  • Ví dụ 2: Đoạn code bên dưới in ra đường dẫn file với đầu vào là tên file 

String fileName = "temp.txt";

File file1 = new File(fileName);

System.out.println("File 1 path: " + file1.getCanonicalPath());

fileName = "./../../../../../../../boot.ini";

File file2 = new File(fileName);

System.out.println("File 2 path: " + file2.getCanonicalPath());

fileName = "boot.ini" + String.valueOf((char) 0) + ".txt";

File file3 = new File(fileName);

System.out.println("File 3 path: " + file3.getCanonicalPath());

  • Với đường dẫn thư mục hiện tại là

  • C:\Documents and Settings\Website\upload\test\”.Ta có kết quả thực hiện:

File 1 path: C:\Documents and Settings\Website\upload\test\temp.txt

File 2 path: C:\boot.ini

File 3 path: C:\Documents and Settings\Website\upload\test\boot.ini

  • Trong trường hợp 1, kết quả in ra đường dẫn file temp.txt nằm trong thư mục hiện tại. Trong 2 trường hợp còn lại, tên file được thay đổi để truy cập đến các file không được phép.

  • Trường hợp 2: Trong tên file có chứa các chuỗi ./../, các chuỗi này có tác dụng chuyển đến thư mục hiện tại (./) và thư mục cha của thư mục hiện tại (../). Vì thế với tên file là “./../../boot.ini”, kết quả in ra là file boot.ini nằm trong thư mục gốc ổ C. Chú ý: Kỹ thuật này thường được dùng để truy cập đến các thư mục nằm ngoài thư mục hiện tại. Các chuỗi .\..\ cũng có tác dụng tương tự như ./../

  • Trường hợp 3: Các hàm xử lý file của hệ điều hành khi gặp kí tự NULL (mã ASCII là 0) trong tên file sẽ hiểu rằng đây là kí tự kết thúc xâu chứa tên file và bỏ qua tất cả các kí tự phía sau (đặc điểm của các hàm xử lý xâu bằng ngôn ngữ C – ngôn ngữ của hầu hết các hệ điều hành). Vì thế kết quả trong trường hợp này sẽ là file boot.ini trong thư mục hiện tại mặc dù tên file nhập vào có phần mở rộng là “.txt”. 

  • Chú ý: Kỹ thuật này thường được dùng để vượt qua việc chặn phần mở rộng của file.

  • Để sửa lỗi trên ta có thể sử dụng hàm lọc các kí tự /,\,null trong tên file.

public static String getSafeFileName(String input) {

        StringBuilder sb = new StringBuilder();

        for (int i = 0; i < input.length(); i++) {

            char c = input.charAt(i);

            if (c != '/' && c != '\\' && c != 0) {

                sb.append(c);

            }

        }

        return sb.toString();

    }

  • Ví dụ 3: Đoạn mã bên dưới có tác dụng upload file từ client và save vào thư mục upload.

private File clientFile;

private String clientFileFileName;

@Override

public String execute() throws Exception {

    try {

        if (clientFileFileName != null) {

            clientFileFileName = getSafeFileName(clientFileFileName);

            if (!clientFileFileName.endsWith(".txt")) {

                message = "Not .txt file!";

            } else {

                String uploadDir = "C:\\upload\\";

                File uploadFile = new File(uploadDir + clientFileFileName);

                FileUtils.copyFile(clientFile, uploadFile);

                message = "Upload file success!";

            }

        }

    } catch (Exception e) {

        message = "Upload file error!";

    }

    return SUCCESS;

}

  • Sử dụng hàm  getSafeFileName trong ví dụ 1 kết hợp với việc kiểm tra phần mở rộng đảm bảo upload file an toàn, chỉ các file được phép mới được upload lên server và các file này chỉ có thể được phép save vào thư mục chỉ định.

2.5 Các lỗi khác

A.  Lỗi CSRF (Cross Site Request Forgery)

  • Nguy cơ: CSRF (Cross-site request forgery) là phương pháp mượn quyền của người dùng khác để thực hiện một hành động không cho phép. Ví dụ: Để có thể xóa một bài viết trên diễn đàn một member có thể mượn tay của một admin để làm việc đó vì member không đủ chủ quyền nhưng admin lại đủ chủ quyền để thực hiện hành động này. Kẻ tấn công lừa admin truy cập vào trang web có chứa đoạn mã xóa bài viết trên diễn đàn (Admin đang đăng nhập vào diễn đàn) như vậy admin đã gửi yêu cầu xóa bài viết trên diễn đàn mà không hề biết.

  • Biện pháp: Trong các tương tác của người dùng với cơ sở dữ liệu thông qua các form, liên kết, sử dụng thêm biến token (được tạo ra mỗi đầu phiên truy cập của người dùng) như một tham số trong phương thức GET hoặc POST và kiểm tra giá trị token này tại server để xác nhận hành vi của người dùng.

  • Đối với các yêu cầu quan trọng, sử dụng thêm biến token. Trên server sẽ kiểm tra token trong yêu cầu gửi lên từ client, nếu token không hợp lệ thì yêu cầu sẽ không được thực hiện.

Hình 51: Đoạn code mắc lỗi

Hình 52: Đoạn code khắc phục lỗi CSRF

  • Ví dụ: Ứng dụng struts cho phép hiển thị lời chào với tên người dùng nhập từ form index.jsp.

<%@taglib prefix="s" uri="/struts-tags" %><br />

<html>

    <head>

        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    </head>

    <body>

        <h2>Hello World!</h2>

        Struts 2 Message: <s:property value="message" default="Guest." />

        <s:form method="GET" action="/HelloStruts2World.action">

            Enter your name:<s:textfield name="userName" />

            <s:submit value="Submit" />            

        </s:form>

    </body>

</html>


struts.xml

<struts>

    <package name="/" extends="struts-default">        

        <action name="HelloStruts2World" class="hello.HelloStruts2World">            

            <result name="success">/index.jsp</result>            

        </action>

    </package>

</struts>

helloStruts2World.java

package hello;

import com.opensymphony.xwork2.ActionSupport;

public class HelloStruts2World extends ActionSupport {

    private String userName;

    public String getUserName() {

        return userName;

    }

    public void setUserName(String userName) {

        this.userName = userName;

    }

    private String message;

    public String getMessage() {

        return message;

    }

    @Override

    public String execute() {

        message = "Hello, " + userName + ".";

        return SUCCESS;

    }

}

  • Tuy nhiên, yêu cầu trên có thể được thực hiện mà không cần phải nhập username từ form bằng cách đưa trực tiếp vào URL:

  • http://localhost:8084/TestStruts/HelloStruts2World.action?userName=abc  

  • Để khắc phục lỗi trên, ta có thể sử dụng token intercepter đã có sẵn của struts. 

index.jsp

<%@taglib prefix="s" uri="/struts-tags" %><br />

<html>

    <head>

        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    </head>

    <body>

        <h2>Hello World!</h2>

        Struts 2 Message: <s:property value="message" default="Guest." />

        <s:form method="GET" action="/HelloStruts2World.action">

            <s:token/>

            Enter your name:<s:textfield name="userName" />

            <s:submit value="Submit" />            

        </s:form>

    </body>

</html>

struts.xml

<struts>

    <package name="/" extends="struts-default">

        <interceptors>

            <interceptor-stack name="defaultSecurityStack">

                <interceptor-ref name="defaultStack" />

                <interceptor-ref name="tokenSession">

                    <param name="excludeMethods">*</param>

                </interceptor-ref>

            </interceptor-stack>

        </interceptors>

        <default-interceptor-ref name="defaultSecurityStack" />

        <global-results>

            <result name="invalid.token">/error.jsp</result>

        </global-results>

        <action name="HelloStruts2World" class="hello.HelloStruts2World">

            <interceptor-ref name="defaultSecurityStack">

                <param name="tokenSession.includeMethods">*</param>

            </interceptor-ref>

            <result name="success">/index.jsp</result>            

        </action>

    </package>

</struts>

B.  Lỗi phân quyền

  • Biện pháp: Kiểm tra quyền trong từng request gửi lên server. 

  • Kiểm tra quyền thực hiện action: Sử dụng VSA

  • Kiểm tra quyền tác động dữ liệu

  • Ví dụ:

Hình 53: Đoạn code mắc lỗi phân quyền

Hình 54: Đoạn code khắc phục lỗi phân quyền

C.  Lỗi liệt kê người dùng

  • Nguy cơ: Trường hợp thông báo lỗi trên trang đăng nhập phân biệt giữa nhập sai tên đăng nhập và sai mật khẩu 🡪 Dựa vào đó kẻ tấn công có thể thử và tìm ra các user có trên hệ thống. Với các chức năng phải thông báo tên user nhập vào là đúng hay sai như các chức năng reset password, forgot password, chức năng đăng ký thì kẻ tấn công có thể thử và tìm ra các user có trên hệ thống.

  • Biện pháp: Sử dụng chung thông báo lỗi cho cả 2 trường hợp nhập sai tên đăng nhập và mật khẩu trên trang đăng nhập vào hệ thống. Ngoài ra nên sử dụng captcha cho các chức năng đăng ký, reset, forgot mật khẩu để tránh các công cụ tự động khai thác lỗi user enumeration.

D.  Lỗi Session Fixation

  • Nguy cơ: Kỹ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ bằng cách gửi một sesion ID hợp lệ đến người dùng, sau khi người dùng đăng nhập vào hệ thống thành công, hacker sẽ dùng lại sesion ID đó và nghiễm nhiêm trở thành người dùng hợp lệ.

  • Biện pháp: Chống việc đăng nhập với một session ID có sẵn: Theo kiểu tấn công này, người dùng đăng nhập vào hệ thống thông qua một session ID do hacker tạo sẵn thay vì cho trình chủ tạo mới, do đó để có phòng chống, ứng dụng phải hủy bỏ session ID được cung cấp bởi trình duyệt của người dùng khi đăng nhập và luôn tạo một session ID mới khi người dùng đăng nhập thành công.

E.  Lỗi Session Hijacking

  • Nguy cơ: Kỹ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ sau khi nạn nhân đã đăng nhập vào hệ thống bằng cách giải mã session ID của họ được lưu trữ trong cookie hay tham số URL, biến ẩn của form.

  • Biện pháp: Giới hạn phạm vi ứng dụng của session ID:

  • Kết hợp session ID với địa chỉ của trình duyệt. Chú ý trường hợp mạng client có sử dụng NAT để truy cập vào server ứng dụng sẽ không dùng được phương pháp này.

  • Xóa bỏ session khi người dùng thoát khỏi hệ thống hay hết hiệu lực, có thể thực hiện trên trình máy chủ.

  • Thiết lập thời gian hết hiệu lực cho session, tránh trường hợp hacker có thể duy trì session và sử dụng nó lâu dài.

F.  Lỗi chuyển hướng và chuyển tiếp thiếu thẩm tra

  • Nguy cơ: Có thể redirect đến URI có nhiễm mã độc để cài phần mềm độc hại, hoặc lừa nạn nhân khai báo mật khẩu, hoặc những thông tin nhạy cảm khác.

  • Biện pháp: Hạn chế sử dụng việc chuyển hướng và chuyển tiếp đến URI khác. Nếu sử dụng thì nên hạn chế truyền tham số là trang sẽ chuyển hướng đến, hoặc tham số này phải được mã hóa và được kiểm tra tính hợp lệ của nó.

G.  Sử dụng Captcha an toàn.

  • Nguy cơ: Với các chức năng quan trọng, hoặc có thể lộ thông tin, hacker có thể sử dụng công cụ tự động cố gắng thực thi chức năng đó nhiều lần với các tham số khác nhau cho đến khi đạt được ý đồ của hacker.

  • Biện pháp: Sử dụng captcha an toàn theo Guideline sử dụng Captcha an toàn do Tập đoàn ban hành. Và việc kiểm tra captcha của 1 chức năng phải thực hiện trước khi phần chính của chức năng thực thi.

H.  Command injection.

  • Nguy cơ: Khi ứng dụng cho phép người dùng đưa dữ liệu vào các câu lệnh thực thi trên hệ điều hành, hacker có thể lợi dụng để chèn các ký tự đặc biệt cho phép nối, thực thi nhiều câu lệnh khác của hệ điều hành.

  • Biện pháp: Validate chặt chẽ dữ liệu người dùng gửi vào, tránh các ký tự cho phép nối thêm các câu lệnh thực thi của hệ điều hành. Sử dụng whitelist là danh sách chứa các ký tự được phép xuất hiện trong dữ liệu, để so sánh, đối chiếu loại bỏ các ký tự không nằm trong danh sách đó. 

Ví dụ: Loại bỏ các ký tự không nằm trong whitelist: a-z0-9\-\. Với các ngôn ngữ như sau:

  • PHP

$param=escapeshellarg($param);

system(«nslookup $param»);

hoặc

$param=preg_replace("/[^a-z0-9\-\.]/i", "", $param);

system("nslookup $param");

  • PERL

$param=~s/[^a-z0-9\-\.]//gi;

$param="\"".$param."\"";

system("nslookup ".$param);

  • ASP.NET

<asp:RegularExpressionValidator runat="server" id="ParamValidator" ControlToValidate="param" ErrorMessage="Invalid input. You are allowed to enter characters and digits only" ValidationExpression="^[a-zA-Z0-9\-\.]" />

  • ColdFusion

<cfscript>

param=ReReplace(param,'[^a-z0-9\-\.]','','all');

</cfscript>

  • Python

param = re.sub("[^a-zA-Z0-9\-\.]+", "_", param)

  • JAVA/JSP

param.replaceAll("[^a-z0-9\-\.]","");

III.Triển khai, cấu hình, thiết lập hệ thống web an toàn

1.  Xây dựng kế hoạch và quản lý Web Server an toàn

1.1.  Kế hoạch cài đặt và triển khai hệ thống

  • Vấn đề về bảo mật an toàn thông tin phải được xem xét và tính toán ngay từ những bước đầu xây dựng trong vòng đời phát triển hệ thống để tăng cường tối đa vấn đề bảo mật đồng thời tối thiểu hóa được chi phí. Sẽ khó khăn và tiêu tốn hơn rất nhiều khi phát hiện những vấn đề về an toàn thông tin sau khi đã triển khai và cài đặt hệ thống. Do đó việc triển khai xây dựng hệ thống tuân theo một kế hoạch đã được vạch ra từ ban đầu sẽ giúp kiểm soát được tốt hơn về vấn đề an toàn thông tin, hỗ trợ việc xác định các lỗ hổng.

  • Khi xây dựng kế hoạch cài đặt và triển khai hệ thống cần phải chú ý các bước sau đây:

  • Xác định các mục tiêu của Web Server:

  • Các loại thông tin gì sẽ được lưu trữ trên Web server?

  • Các loại thông tin gì sẽ được xử lý và trao đổi với Web server?

  • Yêu cầu bảo mật cho những thông tin này là gì?

  • Những thông tin gì nhận được hoặc lưu trữ trên những máy chủ khác? (back-end database, mail server, …)?

  • Những yêu cầu bảo mật cho những máy chủ liên quan khác là gì? (back-end database, directory server, mail server, proxy server)?

  • Những dịch vụ khác được cung cấp bởi Web Server là gì? 

  • Yêu cầu bảo mật cho những dịch vụ bổ sung này là gì?

  • Những yêu cầu về tính liên tục sẵn sàng của Web Server? Như tính liên tục cần duy trì trong các kế hoạch tác động và kế hoạch khôi phục sau sự cố?

  • Vị trí Web Server trong mô hình mạng?

  • Xác định các dịch vụ mạng Web Server cung cấp, như những dịch vụ này được cung cấp qua giao thức gì?

  • HTTP

  • HTTPS

  • Internet Caching Protocol (ICP)

  • Hyper Text Caching Protocol (HTCP)

  • Web Cache Coordination Protocol (WCCP)

  • SOCKS

  • Database services (ODBC)

  • Xác định các phần mềm dịch vụ mạng cả phía client và server được cài đặt.

  • Xác định người dùng, nhóm người dùng của Web Server và các máy chủ hỗ trợ liên quan.

  • Chỉ ra những quyền của nhóm người dùng này.

  • Chỉ ra các thức quản trị Web Server (local, remote từ mạng nội bộ, remote từ mạng bên ngoài, …)

  • Xác định Web Server phù hợp với yêu cầu của đơn vị mình. Xem xét máy chủ loại nào tuy ít tính năng hơn trong một số trường hợp những lại được bảo mật tốt hơn? Vài vấn đề cần chú ý:

  • Giá thành.

  • Tính tương thích với hạ tầng sẵn có.

  • Trình độ kiến thức của chuyên viên đơn vị

  • Lịch sử các lỗ hổng đã có.

  • Các tính năng.

  • Việc lựa chọn Web Server sẽ chỉ ra được hệ điều hành nào sẽ được sử dụng. Tuy nhiên, có thể quản trị Web Server có thể chọn hệ điều hành có những khả năng sau:

  • Hạn chế được quyền quản trị/root cho chỉ những cá nhân có thẩm quyền chỉ định.

  • Kiểm soát truy cập dữ liệu trên server.

  • Tắt các dịch vụ mạng không cần thiết (những dịch vụ được tích hợp sẵn trong OS)

  • Kiểm soát các dạng thực thi chương trình khác nhau trên Web Server như “Common Gateway Interface (CGI) scripts and plug-ins”.

  • Ghi log những hoạt động của Server để phát hiện tấn công.

  • Có host-based firewall.

  • Thêm nữa, đơn vị nên xem xét khả năng đào tạo, kinh nghiệm của chuyên viên để quản trị server. Nhiều đơn vị gặp phải vấn đề là người quản trị thường đã quen với môi trường, nền tảng sẵn có mà gặp khó khăn khi gặp phải những cái mới khác biệt.

  • Mặc dù nhiều Web Server có thể không chứa những dữ liệu nhạy cảm, quan trọng nhưng hầu hết các Web Server nên được coi là nhạy cảm vì nhiều khi việc mất tính toàn vẹn của dữ liệu trên Web Server sẽ ảnh hưởng rất lớn đến uy tín của đơn vị, tổ chức.

  • Cơ chế bảo vệ an toàn về phần cứng của hệ thống cũng cần phải được xem xét? Ví dụ:

  • Các vấn đề về khóa, an ninh, bảo vệ. Cơ chế kiểm soát truy cập giới hạn việc tiếp xúc, tấn công vật lý server. Các biện pháp kiểm soát truy cập qua sinh trắc học nên được áp dụng nếu có thể trong trường hợp này.

  • IDS vật lý (cảm biến, cameras)

  • Các nguy cơ về thảm họa tự nhiên.

  • Cơ chế bảo vệ nguồn điện năng cung cấp, nguồn phòng ngừa luôn sẵn sàng hoạt động thay thế ngay lập tức.

  • Duy trì nhiệt độ, độ ẩm thích hợp.

  • Cơ chế phòng ngừa thảm họa, như có một node server đặt tại vị trí khác được sao lưu luôn ở trạng thái sẵn sàng hoạt động. 

  • Nếu hệ thống có tính sẵn sàng cao, phải duy trì tối thiểu 2 đường mạng khác nhau (Internet server providers – ISP).

1.2 Nhân sự phụ trách an toàn thông tin 

  • Phần này chúng ta sẽ xác định một cách tương đối các quyền chung, vai trò trách nhiệm của các cá nhân liên quan đến vấn đề bảo mật an toàn thông tin cho Web Server. 

A. Senior IT Management/Chief Information Officer

  • The Senior IT Management/Chief Information Officer (CIO) đảm bảo rằng các cơ chế về bảo mật an toàn thông tin hệ thống là phù hợp. Họ sẽ đưa ra những phương hướng, ý kiến lời khuyên cho việc bảo mật an toàn thông tin, chịu trách nhiệm cho những hoạt động sau liên quan đến Web Servers:

  • Phối hợp xây dựng, phát triển, duy trì các chính sách, chuẩn hóa quy trình an toàn thông tin của đơn vị.

  •  Phối hợp xây dựng, phát triển, duy trì cơ chế kiểm soát thay đổi.

  • Đảm bảo việc thiết lập, tuân thủ các chính sách an toàn thông tin của người dùng trong tổ chức.

  • Phối hợp với quản lý cấp cao hơn, các các nhân có liên quan khác để đưa ra ccs chính sách chuẩn hóa và đảm bảo các chính sách này bặt buộc được thi hành.

 B. Information Systems Security Program Managers

  • The Information Systems Security Program Managers (ISSPM) phụ trách việc tuân thủ theo các quy trình, quy định, chính sách của tổ chức. ISSPMs chịu trách nhiệm cho những hoạt động sau liên quan đến Web Servers:

  • Đảm bảo rằng các thủ tục về an toàn thông tin được phát triển và thực thi.

  • Đảm bảo các chính sách, tiêu chuẩn, các yêu cầu được tuân theo.

  • Đảm bảo xác định được tất cả những hệ thống quan trọng, xây dựng sẵn sàng đầy đủ kế hoạch dự phòng, kế hoạch khôi phục sau sự cố, thảm họa, kế hoạch duy trì hoạt động liên tục của các hệ thống này.

  • Đảm bảo xác định được tất cả các hệ thống quan trọng và lập kế hoạch cho việc đánh giá rà soát an toàn thông tin định kỳ, đều đặn cho các hệ thống quan trọng này.

C.  Information System Security Officers

  • ISSOs chịu trách nhiệm cho những hoạt động sau liên quan đến Web Servers:

  • Phát triển các tiêu chuẩn bảo mật nội bộ, các thủ tục cho việc hỗ trợ hạ tầng mạng Web Servers.

  • Phối hợp phát triển, cài đặt các công cụ, các cơ chế, kĩ thuật an toàn thông tin.

  • Duy trì cấu hình profiles chuẩn hệ thống Web Server, hỗ trợ hạ tầng mạng bao gồm cả Oss, firewalls, routers, Web Server applications.

  • Duy trì tính toàn vẹn hoạt động hệ thống bằng cách thực hiện các bài test, đánh giá rà soát trên các hệ thống quan trọng.

D.  Web Server and Network Administrators

  • The administrators chịu trách nhiệm cho những hoạt động sau liên quan đến Web Servers:

  • Cài đặt và cấu hình hệ thống tuân thủ theo những chính sách, tiêu chuẩn của tổ chức.

  • Duy trì đảm bảo hệ thống an toàn bằng cách thường xuyên sao lưu, cập nhật các bản vá kịp thời.

  • Theo dõi, giám sát tính toàn vẹn của hệ thống, các events liên quan đến an toàn thông tin.

  • Theo dõi phát hiện những bất thường liên quan đến tài nguyên hệ thống.

  • Thực hiện việc kiểm tra, rà soát an toàn thông tin theo yêu cầu.

E.  Web Application Developers

  • Web Application Developers phải đảm bảo ứng dụng họ viết có những đặt tính sau:

  • Hỗ trợ cơ chế xác thực, ủy quyền, điều khiển truy cập hệ thống.

  • Thực hiện sàng lọc dữ liệu đầu vào sao cho không bị bypassed bao gồm cả những HTTP requests, headers, query strings, cookies, form fields, và hidden fields.

  • Xử lý lỗi để không lộ những thông tin nhạy cảm của hệ thống.

  • Bảo vệ các thông tin nhạy cảm được lưu trữ và xử lý bởi ứng dụng.

  • Duy trì cơ chế log mức ứng dụng đầy đủ chi tiết để sử dụng trong những trường hợp Web Server log là không đủ thông tin.

  • Có cơ chế chống DoS mức ứng dụng. Mặc dù DoS thường tấn công vào các tài nguyên lớp mạng hoặc transport, nhưng ứng dụng bản thân nó cũng có thể trở thành mục tiêu. Nếu kẻ tấn công có thể độc chiếm tài nguyên hệ thống, ứng dụng có thể dẫn đến người dùng hợp lệ sẽ không thể sử dụng được dịch vụ.

1.3 Kế hoạch thiết lập an toàn bảo mật hệ thống

  • Mục đích của kế hoạch thiết lập an toàn bảo mật cho hệ thống là nhằm tăng cường việc bảo vệ tài nguyên hệ thống, cung cấp một nhìn tổng quan về các yêu cầu bảo mật của hệ thống, mô tả các cơ chế kiểm soát hoặc dự định để đáp ứng các yêu cầu này. Kế hoạch này cũng phải mô tả trách nhiệm, hành vi của các cá nhân truy cập hệ thống này. Một cách tổng quát thì một kế hoạch thiết lập an toàn bảo mật hệ thống phải bao gồm những nội dụng sau:

  • Xác định hệ thống – Phần đầu tiên là cơ bản phải xác định được thông tin về hệ thống. Những thông tin chung, mục đích của hệ thống, mức độ nhạy cảm, quan trọng, môi trường sẽ triển khai hệ thống.

  • Kiểm soát – Phần này sẽ mô tả các biện pháp kiểm soát (hiện tại hoặc kế hoạch) dự định đáp ứng các yêu cầu bảo vệ thông tin cho hệ thống. Kiểm soát được chia thành ba loại chính:

    • Kiểm soát về quản lý, tập trung vào việc quản lý bảo mật hệ thống máy tính và quản lý rủi ro cho hệ thống. 

    • Kiểm soát vận hành, được cài đặt và thực thi chính bởi con người chứ không phải hệ thống. Do đó cần yêu cầu về chuyên môn, kĩ thuật chuyên ngành.

    • Kiểm soát kĩ thuật, cơ chế bảo mật cho hệ thống máy tính được sử dụng. Việc kiểm soát này có thể đưa ra một cơ chế bảo vệ tự động khỏi việc truy cập, lạm dụng quyền trái phép, phát hiện các hành vi vi phạm an ninh. 

1.4 Yêu cầu về nguồn nhân lực

  • Thách thức lớn nhất và cũng là tốn kém nhất trong việc phát triển và duy trì một Web Server an toàn bảo mật đó là nguồn nhân lực đáp ứng được các yêu cầu cần thiết. Nhiều tổ chức không lường hết được tầm quan trọng của vấn đề này dẫn đến kết quả là nhân viên làm việc quá tải hoặc hệ thống không được bảo vệ an toàn. Do đó, ngay từ những bước đầu của việc lập kế hoạch, tổ chức cần tính đến yêu cầu về nguồn nhân sự cần thiết. Nguồn nhân sự phù hợp và chất lượng là khía cạnh quan trọng nhất của việc đảm bảo an toàn bảo mật cho Web Server hiệu quả. Các tổ chức nên xem xét thực tế là những giải pháp về kĩ thuật không thể thay cho những cá nhân có kĩ năng và kinh nghiệm.

  • Khi xem xét vấn đề nguồn nhân lực của việc triển khai một Web Server, tổ chức cần quan tâm những vấn đề sau:

  • Yêu cầu cá nhân – Yêu cầu vị trí nào? Bao gồm như là: Web Server administrators, Webmasters, network administrators, and ISSOs.

  • Yêu cầu về kĩ năng – Những kĩ năng yêu cầu lập kế hoạch, phát triển, duy trì, vận hành Web Server an toàn là gì? Ví dụ: quản trị OS, quản trị mạng, lập trình.

  • Nguồn nhân sự có sẵn trong tổ chức chưa? Có thể có những trường hợp nguồn nhân sự sẵn có để sử dụng lại không có đủ kĩ năng và kinh nghiệm cần thiết, khi đó cần: 

    • Đào tạo – Thực hiện đào tạo những cá nhân này cho đầy đủ các kĩ năng phù hợp với yêu cầu.

    • Bổ sung thêm nhân sự - Có thể tuyển dụng thêm, thuê hoặc sử dụng nguồn nhân sự bổ sung bên ngoài.

2. Cài đặt, cấu hình an toàn cho Web Server 

  • Trước khi thực hiện quá trình này đảm bảo đọc kĩ tài liệu chuẩn của nhà cung cấp, hiểu rõ các thông số cầu hình cần thiết trong quá trình cài đặt, cấu hình. Đảm bảo xem xét, tra cứu kĩ các cơ sở dữ liệu lỗ hổng về phiên bản Web Server dữ kiến sử dụng. Phần này của tài liệu chúng ta sẽ đi vào các vấn đề, nguyên tắc chung nhất của việc cài đặt, cấu hình an toàn cho Web Server (Chi tiết cụ thể cho từng loại Web Server có thể tham khảo các Guideline hướng dẫn cấu hình bảo mật cho Web Server đã được TĐ ban hành).

  • Một chú ý quan trọng đó là không được public Web Server lên Internet khi chưa được cài đặt, cấu hình an toàn đầy đủ. Thêm nữa là việc kết nối mạng từ bên trong cũng nên giới hạn cho đến khi Web Server được cài đặt, cấu hình, cập nhật hoàn tất. Một Web Server không an toàn có thể bị tổn hại trong vài phút sau khi public lên Internet. 

  • Các nguyên tắc cần ghi nhớ và tuân thủ trong quá trình cài đặt và cấu hình bảo mật cho Web Server là:

  • Cài đặt Web Server trên máy chủ chuyên dụng.

  • Cài đặt phiên bản mới nhất của Web Server cùng bản vá mới nhất. Đặc biệt những bản vá về an toàn bảo mật phải được cài đặt ngay trên hệ thống sớm nhất có thể, chỉ ngoại trừ trường hợp gây ảnh hưởng ngay lập tức đến yêu cầu nghiệp vụ của hệ thống.

  • Chỉ cài đặt những dịch vụ cần thiết của Web Server, loại bỏ những dịch vụ mặc lỗ hổng đã biết thông qua những bản vá, bản cập nhật. Bất cứ những ứng dụng, dịch vụ, scripts mặc định nào đã được cài đặt không cần thiết cũng phải được loại bỏ ngay lập tức.

  • Tạo một ổ đĩa vật lý chuyên dụng hoặc phân vùng logic cho việc cài đặt Web content (phân tách OS và ứng dụng Web Server)

  • Xóa bỏ hoặc tắt những tài khoản đăng nhập mặc định được tạo sau khi cài đặt Web Servers.

  • Xóa bỏ tất cả những tài liệu,  hướng dẫn, code thực thi, file test mặc định của Web Server.

  • Đổi mật khẩu mặc định những tài mặc định theo chính sách mật khẩu của đơn vị.

  • Cấu hình lại HTTP service banner để không để lộ thông báo Web Server, loại hệ điều hành (OS) và phiên bản sử dụng.

  • Nên thực hiện cài đặt Web server sử dụng các tham số như tên thư mục, đường đường dẫn, tên file khác với mặc định. Lý do là đa phần các công cụ tấn công Web server đều nhắm vào việc tìm kiếm những files hoặc thư mục mặc định trên hệ thống. Việc này có thể không ngăn được attacker tấn công Web server nhưng có lợi là sẽ gây khó khăn hơn cho chúng khi tấn công và làm tăng khả năng phát hiện tấn công căn cứ vào dấu hiệu truy cập lỗi vào những file hoặc thư mục mặc định.

2.1 Cấu hình việc phân quyền của ứng dụng Web server

  • Một điều quan trọng là ứng dụng Web server phải chạy dưới quyền một user và group duy nhất riêng biệt với quyền truy cập đã được hạn chế. Nên tạo một user và group mới độc lập với những user và group khác trên hệ thống để sử dụng cho Web server. Đây là điều kiện tiên quyết cho những cấu hình kiểm soát truy cập ở các bước tiếp sau. Trong quá trình khởi tạo ban đầu, server phải chạy với quyền root (Unix) hoặc quyền administrator/system (Windows) để chạy những cổng dưới 1024 (cụ thể là cổng 80 hoặc 443 là cổng mặc định cho HTTP và HTTPS). Đảm bảo rằng Web server được cấu hình để giảm quyền xuống Web server user sau khi thực hiện bước khởi tạo này.

  • Chú ý thêm là sử dụng hệ điều hành Web Server để giới hạn những files cho phép các tiến trình dịch vụ Web server truy cập. Những tiến trình này nên có quyền truy cập là read-only đối với những files cần thiết để chạy dịch vụ và không được truy cập đến những files như là file log server. Sử dụng cơ chế điều khiển truy cập của hệ điều hành Web server thực hiện các bước sau:

  • Tiến trình dịch vụ được cấu hình chạy dưới tài khoản user đã giới hạn quyền chặt chẽ (không được chạy dưới tài khoản root, administrator, hoặc những tài khoản quyền tương đương)

  • Với những files Web content thì tiến trình dịch vụ chỉ được quyền đọc, không được quyền ghi.

  • Các tiến trình dịch vụ không được quyền ghi vào thư mục lưu trữ Web content

  • Chỉ những tiến trình dưới quyền của quản trị Web server mới được quyền ghi các files Web content.

  • Ứng dụng Web server có thể ghi log files Web server nhưng không được phép đọc. Chỉ những tiến trình quyền root/system/administrator mới có thể đọc các file log của Web server.

  • Những files tạm  thời được ứng dung Web tạo ra như: files được tạo bởi những trang Web động hoặc những nội dung người dùng upload phải được giới hạn vào thư mục con chỉ định.

  • Việc truy cập vào các files tạm thời được tạo ra bởi ứng dụng Web phải được giới hạn cho những tiến trình Web server đã tạo ra chúng.

  • Thêm nữa là phải đảm bảo rằng ứng dụng không thể ghi files ra các phân vùng bên ngoài phân vùng của Web content. Đảm bảo không thể truy cập ra những files, thư mục bên ngoài thư mục Web trong trường hợp người dùng request trực tiếp trên trình duyệt truy cập đến URLs những files này hoặc thực hiện thông qua tấn công Directory Traversal.

  • Để giảm bớt ảnh hưởng của các loại tấn công DoS, cấu hình Web server giới hạn bớt số lượng tài nguyên hệ điều hành mà nó sử dụng. Ví dụ:

  • Cài đặt Web content trên ổ cứng hoặc phân vùng logic khác với ứng dụng Web server và hệ điều hành.

  • Đặt giới hạn dung lượng ổ cứng cho chức năng upload (trong trường hợp sử dụng tính năng cho phép upload). Thư mục upload nên được đặt ở phân vùng riêng biệt để đảm bảo an toàn cho ổ cứng.

  • Đảm bảo rằng những files uploaded không được đọc bởi Web server sau khi đã thực hiện việc rà soát lại những file này. Điều này để chống lại malware, các phần mềm chiếm băng thông, các công cụ tấn công, … Có thể giới hạn kích thước mỗi files upload, nhằm ngăn chặn việc lợi dụng tấn công DoS bằng việc upload nhiều files kích thước lớn.

  • Đảm bảo các file log được lưu trữ tại phân vùng riêng có kích thước thích hợp. 

  • Cấu hình số lượng tối đa những tiến trình Web server và các kết nối mạng mà Web server cho phép.

  • Có thể cấu hình timeout và những cơ chế kiểm soát khác để giảm nguy cơ tấn công DoS. Một loại tấn công DoS là lợi dụng giới hạn của những kết nối mạng đồng thời, các kết nối được thiết lập nhanh chóng chạm mức tối đa dẫn đến việc những người dùng hợp lệ bình thường không thể truy cập dịch vụ được. Việc thiết lập timeouts các kết nối mạng (thời gian sau khi một kết nối không có hoạt động gì sẽ bị hủy) đến một giá trị tối thiểu chấp nhận được sẽ giúp nhanh chóng tạo ra những kết nối mới cho người dùng hợp lệ. 

  • Không sử dụng links, aliases hoặc những shortcuts files trong thư mục Web content public trỏ đến những files ở vị trí khác trên server hoặc server khác trong mạng. Các yêu cầu nhằm giới hạn truy cập đến thư mục Web content:

  • Dành một ổ cứng hoặc phân vùng logic cho Web content và các thư mục con liên quan

  • Định nghĩa một cây thư mục duy nhất dành riêng cho những scripts hoặc những chương trình thực thi bên ngoài  như một phần của Web content (CGI, ASP, PHP, …)

  • Vô hiệu hóa việc thực thi những scripts không phải hoàn toàn dưới quyền kiểm soát của tài khoản quản trị. Việc này được thực hiện bằng cách tạo và kiểm soát truy cập đến một thưc mục riêng biệt chứa những scripts hợp lệ.

  • Tắt việc sử dụng hard links hoặc symbolic links.

  • Trong hầu hết các trường hợp, cấu hình tính năng Web server liệt kê danh sách files, thư mục nên được tắt (Directory listing). 

  • Hầu hết các phần mềm Web server đều cung cấp các chỉ thị hoặc lệnh cho phép quản trị giới hạn truy cập của người dùng tới những files Web server content. Ví dụ: Apache Web server có chỉ thị <Limit>, …

2.2 Kiểm soát nguy cơ Web “Bots” trên Web Servers

  • Web bots (hay còn gọi là crawlers hoặc spiders) là những phần mềm sử dụng để thu thập, phân tích, đánh chỉ mục cho Web content. Web bots được sử dụng bởi nhiều tổ chức với nhiều mục đích khác nhau. Ví dụ:

  • MSNBot, Slurp, and Googlebot phân tích, đánh chỉ mục, và ghi lại Web sites chậm và cẩn thận cho những search engines như Windows Live Search, Yahoo hay Google.

  • Mediabot được sử dụng bởi Google để phân tích nội dung cho các trang quảng cáo.

  • Hyperlink “validator” được sử dụng bởi Webmasters để tự động xác thực hyperlinks trên Web sites.

  • EmailSiphon and Cherry Picker là những bots thiết kế đặc biệt cho việc tìm kiếm email trên Web sites để đưa vào spam mailing lists.

  • Nhiều spambots tìm kiếm các trang Web có form login tạo free email từ đó gửi spam hoặc spam blogs, wikis, và các diễn đàn nhằm tăng rank trên các search engine.

  • Screen scrapers thì lấy nội dung Websites để copy sang một server khác. Những bản copy này có thể sử dụng nhằm mục đích lừa đảo người dùng…

  • Một vài loại bots độc hại dò quét Website nhằm tìm kiếm lỗ hổng, từ đó khai thác lấy những thông tin nhạy cảm như: SSN, Credit card data, …

  • Việc chống lại bots có thể xem là một thách thức đối với quản trị Website do một số trường hợp sau:

  • Web server chứa những thư mục không cần đánh chỉ mục

  • Tổ chức không muốn website của họ xuất hiện trong search engines

  • Web server chứa vài trang web tạm thời cũng không nên đánh chỉ mục

  • Tổ chức vận hành Web server mà đang phải trả phí cho băng thông, lưu lượng mà những robots hay spiders này không mang lại lợi ích gì.

  • Bots không phải loại nào cũng được lập trình hoạt động tốt hoặc với mục đích tốt, nhiều tình huống nó thực hiện request cực nhanh và nhiều tới server dẫn đến có thể gây DoS cho hệ thống.

  • Bots có thể khám phá ra nhiều thông tin mà Webmaster không muốn để lộ.

  • Quản trị Web muốn giới hạn những hoạt động của bots trên Web server của họ thì cần phải tạo một file đặt tên là “robots.txt”. File phải luôn đặt tên như vậy và phải được đặt tại thư mục gốc của Web server document. Thêm nữa, chỉ một file được cho phép trên mỗi Web site. Chú ý là file robots.txt là chuẩn mà những lập trình viên tình nguyện đã hỗ trợ, những loại bots độc hại (như EmailSiphon hay Cherry Picker) thường lờ file này đi.

  • File robots.txt chỉ là file text đơn giản chứa vài từ khóa và đặt tả file. Những từ khóa dùng để chỉ cho robots biết là phần nào của Web site được loại bỏ đi.

Những từ khóa sau được cho phép:

  • User-agent: là tên của robot hay spider. Quản trị Web có thể thêm nhiều hơn một loại tên agent nếu những loại trừ được áp dụng cho mỗi loại bots. Đầu vào không phân biệt chữ hoa hay thường (có nghĩa là “googlebot” cũng tương tự như “GOOGLEBOT” hay “GoogleBot”)

  • Disallow: chỉ cho bots trong User-agent biết là phần nào của Web sites được loại bỏ. Ví dụ: /images thông báo cho bot biết là không mở hoặc đánh chỉ mục cho bất cứ file nào trong thư mục images hoặc các thư mục con trong nó.
    Nếu giá trị chỉ là “/” có nghĩa là không phần nào trên Web sites cho phép truy bots truy cập. Ít nhất phải có một disallow cho mỗi User-agent. Có rất nhiều cách sử dụng file robots.txt. Ví dụ:

  • Không cho phép tất cả các loại bots trên một số thư mục của Web sites

User-agent: * 

Disallow: /images/ 

Disallow: /banners/ 

Disallow: /Forms/ 

Disallow: /Dictionary/ 

Disallow: /_borders/ 

Disallow: /_fpclass/ 

Disallow: /_overlay/ 

Disallow: /_private/ 

Disallow: /_themes/

  • Không cho phép tất cả các loại bots trên cả Web sites:

User-agent: * 

Disallow: /

  • Không cho phép một loại bots nào đó trên một trang nào đó

User-agent: GoogleBot 

Disallow: tempindex.htm

  • Chú ý là file robots.txt cho phép truy cập tự do và không áp dụng bất cứ cơ chế kiểm soát truy cập nào với những files disallowed. Do đó, quản trị Web không nên đặt những cái tên file hoặc thư mục nhạy cảm vì attacker thường phân tích file robots.txt thăm dò Web sites. Nếu files hoặc thư mục phải được loại bỏ, tốt hơn hết là sử dụng mật khẩu để bảo vệc trang không thể truy cập được bởi bots. 

  • Thông thường, spambots lờ file robots.txt và tìm kiếm địa chỉ email trên Web sites hoặc gửi những nội dung spam. Có thể phòng chống việc thu thập email của bots bằng cách hiển thị địa chỉ email dưới dạng human-readable, ví dụ: name at my www dot com. Tuy nhiên kĩ thuật này cũng không ngăn được mọi loại spambots. Cách tốt nhất là không hiển thị địa chỉ email lên sites.

  • Spambots tìm kiếm các web forms và gửi thông tin, nội dung spam là nguy cơ lớn trực tiếp với Web site. Chúng có thể gây ảnh hưởng tới hình ảnh của tổ chức, chúng cũng gây ảnh hưởng tới việc tìm kiếm nội dung của những người dùng bình thường. Một vài kĩ thuật nhằm giảm số lượng spam đó là:

  • Chặn việc gửi những thông tin web form có sử dụng những từ khóa dạng spam.

  • Sử dụng từ khóa rel=”nofollow” trong tất cả các submit links, điều này sẽ khiến cho search engines bỏ qua những link này trong giải thuật sếp hạng trang của họ, gây ảnh hưởng trực tiếp tới mục đích của spambots

  • Yêu cầu người dùng nhập CAPTCHA trước khi submit nội dung lên Web sites.

  • Phần này trình bày các nguyên tắc trong triển khai hệ thống an toàn. Quản trị hệ thống nên căn cứ các nguyên tắc, kết hợp hướng dẫn trong các Guideline quy chế do Tập đoàn ban hành để hoàn thiện cấu hình web server.

IV.Vận hành hệ thống web an toàn

  • Sau khi cài đặt, triển khai một Web server, người quản trị phải tiếp tục duy trì công tác an toàn bảo mật thông tin cho nó. Ở phần này của tài liệu chúng ta sẽ đưa ra những khuyến cáo chung nhất nhằm mục đích giúp người quản trị vận hành an toàn cho Web server. Cụ thể các vấn đề cần xem xét đó là công tác quản trị, cơ chế ghi log, cơ chế sao lưu backup, đánh giá an toàn thông tin định kì, …

1. Xây dựng thông tin Profile hệ thống

  • Người quản trị cần xây dựng và cập thông tin Profile hệ thống một cách đầy đủ, bao gồm tối thiểu các nội dung sau:

  • Tên/loại máy chủ, thiết bị.

  • Mô tả chức năng trong hệ thống.

  • Mô hình kết nối hệ thống (Topo mạng bao gồm cả sơ đồ logic, vật lý).

  • Cấu hình (RAM, CPU, port,…).

  • Hệ điều hành và các phần mềm dịch vụ đang được cài đặt/ vận hành, môi trường cho các ứng dụng.

  • Vị trí, địa chỉ mạng (IP), cổng kết nối với các thiết bị, các server khác.

Đầu mối liên hệ người quản lý, quản trị, chịu trách nhiệm.

2. Quản trị Web Server

  • Các quy định về công tác quản trị Web Server có thể thay đổi, khác nhau tùy thuộc vào đặc thù của từng đơn vị. Nhưng các nội dung sau cần lưu ý:

  • Quy định về đăng ký và quản lý đặc quyền

  • Bộ phận quản trị chỉ được cấp một tài khoản truy cập duy nhất cho người quản trị tương ứng với mỗi hệ thống, ứng dụng. Không cấp tài khoản sử dụng chung.

  • Thông báo cho người quản trị về các quyền truy cập của tài khoản, thời gian sử dụng tài khoản, yêu cầu người quản trị ký xác nhận quyền truy cập của mình.

  • Các tài khoản đặc quyền (quyền admin, root) chỉ sử dụng cho mục đích quản trị, không sử dụng cho các tác nghiệp thường ngày (ví dụ: dùng tài khoản quản trị domain trên máy tính cá nhân).

  • Bộ phận quản trị/vận hành có trách nhiệm lưu trữ hồ sơ đăng ký và cấp quyền truy cập đối với mỗi tài khoản người dùng/quản trị. Hồ sơ cần có các thông tin: Tài khoản/ID, Hệ thống được truy cập, Người dùng/Đơn vị, Quyền truy cập, thời hạn sử dụng, …

  • Quy định về quản lý mật khẩu:

  • Tất cả các tài khoản đều phải đặt mật khẩu

  • Mật khẩu phải có độ dài tối thiểu 8 ký tự, bao gồm cả chữ, số, ký tự thường, ký tự hoa và ký tự đặc biệt. Không sử dụng các mật khẩu đặt theo các quy tắc đơn giản ( như: 123, abc, nhóm ký tự/số liên tiếp,...)

  • Mật khẩu phải được lưu dưới dạng mã hóa (ví dụ đối với các mật khẩu local trên thiết bị mạng, phải mã hóa mật khẩu trong file cấu hình)

  • Không truyền các mật khẩu không được mã hóa trên mạng.

  • Thời gian tối đa phải tiến hành đổi mật khẩu đối với các hệ thống, thiết bị, ứng dụng (server, firewall, router, switch, phần mềm nghiệp vụ …) là 90 ngày.

  • Số lần đăng nhập hệ thống không thành công liên tiếp tối đa không được quá 5 lần. Trường hợp vi phạm hệ thống cần khóa tài khoản lại, thời gian khóa tài khoản tối thiểu là 10 phút.

  • Rà soát các quyền truy cập:

  • Người quản trị hệ thống định kỳ phải thực hiện rà soát các tài khoản tồn tại trên hệ thống, các quyền của từng tài khoản so với danh sách phê duyệt để thu hồi.

  • Tối đa trong vòng 3 tháng cần phải rà soát tài khoản đối với từng hệ thống.

  • Giới hạn thời gian phiên làm việc (Session timeout): Đối với Server là 5 phút.

  • Quy định về công tác vận hành quản trị:

  • Đơn vị quản trị thiết bị phải thực hiện sao lưu định kỳ (ngày/tuần/tháng) theo kế hoạch phê duyệt của từng đơn vị. Nội dung sao lưu gồm: hệ điều hành, file cấu hình thiết bị.

  • Đơn vị quản trị thiết bị phải xây dựng phương án khôi phục cấu hình thiết bị.

  • Các máy tính sử dụng để quản trị yêu cầu: 

    • Phải cài đặt phần mềm diệt virus và tường lửa 

    • Chỉ chạy ở quyền user, trừ trường hợp phải cài đặt mới chuyển quyền quản trị.

    • Không kết nối trực tiếp với mạng Internet(ví dụ: phải qua proxy hoặc firewall). Trường hợp các máy tính để cấu hình thiết bị/ máy chủ thuộc mạng lõi (core) quan trọng, không được phép kết nối vào Internet.

    • Các máy quản trị phải được bộ phận ATTT kiểm tra trước khi được đưa vào sử dụng.

3. Logging

  • Ghi log là nền tảng của việc bảo mật. Nắm bắt các số liệu chính xác trong log và sau đó theo dõi các log là một việc rất quan trọng. Các file log tạo điều kiện cho việc phát hiện các cuộc tấn công không thành công, thành công và là dấu hiệu cảnh báo khi cần điều tra sâu thêm. Log máy chủ web cung cấp:

  • Cảnh báo các hoạt động đáng ngờ khi cần điều tra thêm.

  • Theo dõi các hoạt động của kẻ tấn công.

  • Hỗ trợ trong việc phục hồi của hệ thống.

  • Hỗ trợ trong việc điều tra sau khi bị tấn công.

  • Thông tin cần thiết cho thủ tục tố tụng pháp lý.

3.1 Xác định khả năng ghi log của Web Server

  • Tùy từng loại Web server mà nó hỗ trợ các kiểu ghi log khác nhau.

  • Transfer Log: mỗi lần trao đổi là đều được ghi log.

  • Error Log: khi có lỗi thì ghi log.

  • Agent Log: chứa các thông tin về phần mềm người dùng dùng để truy cập nội dung Web.

  • Referer Log: thu thập các thông tin thích hợp để truy cập HTTP.

  • Hầu hết các Web Server đều hỗ trợ Transfer Log. Các format cho Log:

  • Common Log Format (CLF): Định dạng này chứa các thông tin liên quan đến một lần trao đổi dữ liệu, cụ thể:

  • Remote host

  • Remote user identity 

  • Authenticated user

  • Date

  • URL được yêu cầu

  • Trạng thái của yêu cầu

  • Kích thước của phiên trao đổi

  • Combined Log Format: Cũng chứa 7 trường trên. Nó cung cấp thêm các thông tin lưu trong Agent Log và Referrer Log. Nên giữ các thông tin này để hỗ trợ việc quản trị hiệu quả hơn.

  • Extended Log Format: cung cấp cách thức mô tả tất cả các đối tượng sẽ được ghi vào log. Hai dòng đầu tiên chứa phiên bản và tên của các trường sẽ được ghi log, theo format như sau

#Version: 1.0 

#Fields: date time c-ip sc-bytes time-taken cs-version 

1999-08-01 02:10:57 192.0.0.2 6340 3 HTTP/1.0

3.2 Xác định các yêu cầu ghi log bổ sung

  • Nếu Web server hỗ trợ thực thi các chương trình ứng dụng, scripts, plug-in, thì cần thiết phải ghi lại log cho các chương trình, scripts và plug-in đó.

3.3 Khuyến cáo cấu hình log cơ bản

  • Sử dụng Combined log format để lưu Transfer Log, (hoặc cấu hình bằng tay các thông tin được mô tả trong combined log format để chuẩn hóa lại format log của Transfer log).

  • Enable Referer Log hoặc Agent Log nếu Combined Log Format không khả dụng.

  • Tạo các tên file log khác nhau đối với các virtual Web site khác nhau.

  • Sử dụng remote user identity.

  • Đảm bảo việc ghi log không làm đầy ổ cứng.

3.4 Rà soát và lưu lại các file log

  • Tần suất của việc rà soát lại các file log phụ thuộc vào các yếu tố:

  • Lưu lượng các yêu cầu mà server nhận.

  • Mức độ nguy hiểm (các site nào đó bị tấn công nhiều hơn các site còn lại thì nên được rà soát log thường xuyên hơn).

  • Các mối nguy hiểm cụ thể (vào một thời điểm cụ thể khả năng bị nguy hiểm tăng cao thì cần phần tích log thường xuyên hơn).

  • Lỗ hổng của Web server.

  • Giá trị của các dữ liệu và dịch vụ được cung cấp bởi Web server.

  • Việc rà soat nên diễn ra thường xuyên (ví dụ, hàng ngày). Có thể sử dụng các công cụ phân tích log.

  • Ngoài ra còn cần những lần phân tích log trong thời gian dài và ở mức độ sâu. Bởi có một số mối nguy hiểm không thể quan sát qua một ngày hay một tuần mà có thể thông qua một tháng, một quý.

  • Cần bảo vệ cho các file log bởi có thể kẻ tấn công khi chiếm được Web server sẽ thay đổi các file log này để xóa dấu vết. Cách tốt nhất là lưu trữ log tập trung, các file log lưu ở một server khác với Web server.

  • Các file log nên được back up và lưu trữ thường xuyên. Chu kỳ backup này phụ thuộc vào một số yếu tố:

  • Các yêu cầu pháp lý.

  • Các yêu cầu của tổ chức.

  • Kích thước file log (liên quan trực tiếp đến việc truy cập đến site và số lượng các thông tin được ghi log).

  • Tầm quan trọng của các dữ liệu và dịch vụ trên Web server.

  • Mức độ nguy cơ.

4. Sao lưu dữ liệu

  • Có hai vấn đề liên quan đến việc backup: thứ nhất là backup thường xuyên dữ liệu và hệ điều hành trên Web server và thứ hai là việc lưu trữ các bản backup đó.

4.1 Chiến lược và chính sách backup

  • Nguy cơ: Web server có thể bị lỗi hoặc bị tấn công. Do đó phải luôn backup lại.

Mặc dù mỗi Web server của mỗi tổ chức có những chính sách sao lưu backup khác nhau, nhưng nó đều nên nhắm tới những vấn đề sau:

  • Mục đích của chính sách.

  • Các nhóm sẽ chịu ảnh bởi chính sách.

  • Các máy chủ web được áp dụng chính sách.

  • Các yêu cầu chi tiết về pháp lý, kinh doanh, và quan điểm của tổ chức

  • Tần suất yêu cầu backup.

  • Các thủ tục đảm bảo việc dữ liệu vẫn được duy trì vào bảo vệ.

  • Các thủ tục đảm bảo dữ liệu được triển khai và lưu trữ tốt.

  • Các thủ tục để bảo vệ thông tin đối với các yêu cầu Freedom of Information Act (Tự do thông tin), đầu tư pháp luật.

  • Trách nhiệm của những người liên quan trong lưu giữ, bảo vệ, và các hoạt động phá hoại dữ liệu.

  • Chu kỳ lưu trữ đối với mỗi thông tin được ghi log.

  • Trách nhiệm cụ thể của nhóm backup dữ liệu của trung tâm hoặc tổ chức (nếu có).

Có ba kiểu backup: 

  • Backup đầy đủ (full)

  • Backup tăng cường (incremental)

  • Backup khác biệt (differential)

  • Full backup bao gồm OS, ứng dụng, và các dữ liệu lưu trên Web server. Ưu điểm của loại này là dễ dàng restore toàn bộ Web server. Tuy nhiên nhược điểm của nó là tốn thời gian và tài nguyên.

  • Incremental backup là chỉ backup các dữ liệu thay đổi so với bản backup trước đó (có thể là full hoặc incremental). 

  • Differential backup sẽ backup các dữ liệu bị thay đổi so với bản full backup gần nhất. Tổng quát, nên full backup nhưng thời gian lâu hơn (hàng tuần hoặc hàng tháng), còn incremential và differential backup thường xuyên hơn (hàng ngày hoặc hàng tuần). Tần suất của backup phụ thuộc:

  • Sự biến động của thông tin trên Website

  • Các nội dung tĩnh thì ít backup hơn.

  • Các nội dụng động nên backup thường xuyên hơn.

  • Đối với các thông tin thương mại điện tử nên backup thường xuyên.

  • Sự biến động của việc cấu hình Web server.

  • Lượng dữ liệu cần được backup.

  • Thiết bị và phương tiện sẵn có cho việc backup.

  • Thời gian cho việc backup.

  • Tầm quan trọng của dữ liệu.

  • Mức độ nguy hiểm phải đối mặt của Web server.

  • Mức độ khó khăn khi tái tạo lại dữ liệu mà không được backup.

  • Backup các dữ liệu và tính năng dự phòng khác của Webserver

4.2 Duy trì việc kiểm thử Web Server

  • Cần có riêng một Web server cho việc kiểm thử và phát triển. Lợi ích của việc kiểm thử Web Server:

  • Cung cấp nền tảng để kiểm thử các bản vá và dịch vụ mới trước khi áp dụng và hệ thống thật.

  • Cung cấp nền tảng phát triển cho quản trị web.

  • Cung cấp nền tảng để kiểm thử các cấu hình trước khi áp dụng vào hệ thống thật.

  • Các phần mềm quan trọng cho việc phát triển và kiểm thử có thể không thể hiện được các rủi ro về bảo mật.

  • Server để kiểm thử nên là một server tách biệt với hệ thống thật.

4.3 Lưu trữ một bản sao nội dung Web đã được xác thực

  • Để có một bản sao lưu đáng tin, cần đảm bảo các yêu cầu sau:

  • Các truy cập không được phân quyền không thể truy cập được tới bản sao này

  • Sử dụng các phương tiện ghi một lần (write-once media)

  • Đặt máy chứa bản sao này ở phía sau tưởng lửa, và không có truy cập từ bên ngoài vào máy đó.

  • Tối thiểu số người dùng được phân quyền truy cập bản sao.

  • Kiểm soát người dùng truy cập.

  • Triển khai cơ chế xác thực mạnh đối với người dùng.

  • Triển khai các thủ túc ghi log và giám sát thích hợp.

  • Xem xét cất giữ bản sao đó ở các máy khác nữa.

  • Thiết lập các cơ chế cập nhật bản sao đó một cách phù hợp

  • Thực hiện cập nhật bản sao đầu tiên (mọi quá trình kiểm thử trên code nên thực hiện trước khi cập nhật bản sao).

  • Tạo các chính sách và thủ tục cho những người có quyền được cập nhật.

  • Thiết lập quy trình áp dụng bản sao tin cậy đó vào Web Server

  • Các dữ liệu được truyền đi qua kênh truyền an toàn.

  • Sử dụng các giao thức an toàn.

  • Thêm các thủ tục để khôi phục lại dữ liệu từ bản sao tin cậy đó.

Xem xét việc cập nhật tự động Web server từ các bản sao tin cậy đó theo chu kỳ.

5. Quản lý nội dung Website 

  • Việc sử dụng các công cụ remote để chỉnh sửa trực tiếp nội dung trên các Web sites public là không nên.

  • Khuyến cáo là quản trị Server nên thao tác trực tiếp thông qua console. Tuy nhiên nếu cần quản trị từ xa thì phải sử dụng công cụ quản trị qua kênh kết nối an toàn, đã được mã hóa đường truyền.

  • Việc tải nội dung Web lên server phải thực hiện qua kênh kết nối an toàn, ví dụ: nếu sử dụng SSH phải hardening cho cấu hình SSH: thiết lập thời gian time-out ngắn, giới hạn tài khoản SSH, …

  • Các máy client quản trị nội dung phải được đặt trong vùng mạng đã được giới hạn truy cập, phải được hardening và cài đặt các bản vá OS đầy đủ.

  • Những nội dung tải lên Web Server phải đảm bảo không có virus, malware, …

6. Quản lý tác động, thay đổi

  • Mọi tác động, thay đổi đên Web Server trong quá trình vận hành, quản trị đều phải tuân theo quy trình quản lý tác động, thay đổi của đơn vị, bao gồm tối thiểu các nội dung sau:

  • Tất cả những tác động đối về hệ thống CNTT (cập nhập bản vá, thay đổi topology mạng, cài đặt phần mềm mới, thêm thiết bị mới …) đều phải được lãnh đạo đơn vị phê duyệt kế hoạch triển khai. Kế hoạch triển khai cần đảm bảo:

    • Đánh giá, phân tích ảnh hưởng khi tác động, tiêu chí cần đạt được, các rủi ro gây gián đoạn hệ thống, mất an toàn thông tin, thời gian gián đoạn.

    • Các kết quả thử nghiệm (đánh giá tác động, thay đổi trên hệ thống test trước khi áp dụng cho hệ thống thật).

    • Các hướng dẫn triển khai chi tiết.

    • Các nguồn lực cần thiết (con người, thiết bị …).

    • Phương án rollback dự phòng trường hợp những tác động gây lỗi.

  • Khi tiến hành triển khai tác động, bộ phận triển khai cần thông báo trước với các bên liên quan, và phải có xác nhận lại.

  • Phải tiến hành đánh giá xem xét hiệu quả của các tác động đối với hệ thống đã được thực hiện.

  • Các thay đổi với hệ thống cần phải lưu hồ sơ đầy đủ (Hồ sơ tác động, hồ sơ đánh giá hệ thống, …)

  • Bộ phận quản trị máy chủ triển khai trên các máy chủ phải quản lý thông tin lịch sử các phiên bản ứng dụng được đưa lên khai thác, có tài liệu mô tả rõ sự thay đổi ứng dụng trong mỗi lần upcode (thay đổi file gì, tác động đến hệ thống như thế nào, giải quyết vấn đề gì).

7. Quản trị Web server từ xa an toàn

  • Việc quản trị và cập nhập nội dung Web server từ xa nên được tiến hành sau khi đã cân nhắc kĩ lưỡng các rủi ro. 

  • Nếu một tổ chức cần dùng quản trị hoặc cập nhập nội dung Web server từ xa, cần thức hiện các bước sau để đảm bảo nội dung của Web Server sẽ được thực thi một cách an toàn:

  • Dùng một cơ chế xác thực mạnh (ví dụ, sử dụng cặp khóa public/private, xác thực hai nhân tố).

  • Hạn chế những host nào có thể dùng quản trị hoặc cập nhật được nội dung Web server từ xa

  • Hạn chế bằng cách phân quyền người dùng.

  • Hạn chế chế bằng địa chỉ IP (không phải tên miền).

  • Hạn chế những host trong mạng nội bộ hoặc những host nào dùng giải pháp truy cập từ xa của tổ chức.

  • Sử dụng các giao thức an toàn để các dữ liệu và mật khẩu được mã hóa (SSH, HTTPS), không sử dụng các giao thức kém an toàn (như telnet, NFS, HTTP) nếu không thực sự cần thiết, và chế độ đường ngầm thông qua một giao thức mã hóa (ví dụ như SSH, SSL hoặc IPSec).

  • Thực thi các đặc quyền tối thiểu đối với quản trị và cập nhật nội dung từ xa.

  • Không cho phép quản trị từ xa trên Internet thông qua firewall khi chưa qua các khâu xác thực mạnh như VPNs.

  • Đổi tài khoản và mật khẩu mặc định của các tài khoản hoặc ứng dụng quản trị từ xa.

  • Không mount bất kỳ file nào để chia sẻ trong mạng nội bộ từ Web Server và ngược lại.

8. Theo dõi cập nhật tin tức lỗ hổng

Việc những lỗ hổng mới (0-days) được public trong tương lai là điều không thể tránh và không thể lường trước được. Do đó, người quản trị Web Server lưu ý cần phải:

  • Theo dõi danh sách mail (mailing lists), các Web sites cảnh báo về an toàn bảo mật thông tin. 

  • Thông thường phải theo dõi danh sách mail (mailing lists) cảnh báo an toàn bảo mật của tất cả các phần mềm có truy xuất mạng đã được cài đặt trên Web Server.

9. Công tác kiểm tra và đánh giá an toàn thông tin 

  • Việc đánh giá kiểm tra an toàn thông tin định kì là việc hết sức quan trọng. Có nhiều kĩ thuật đánh giá an toàn thông tin hệ thống nhưng phương pháp quét lỗ hổng là phổ biến nhất. Việc quét lỗ hổng sẽ hỗ trợ quản trị viên trong việc xác định lỗ hổng, xác minh lại hiệu quả của các biện pháp an ninh an toàn thông tin. Phương pháp đánh giá an toàn thông tin cũng thường được sử dụng, nhưng với tần suất thấp hơn.

9.1 Dò quét lỗ hổng (Vulnerability Scanning)

  • Các công cụ dò quét tự động thường sử dụng để xác định các lỗ hổng, lỗi cấu hình trên máy chủ. Các công cụ dò quét có thể giúp: xác định các phiên bản phần mềm đã hết hạn sử dụng, chưa cập nhật bản vá cần nâng cấp, kiểm tra việc tuân thủ theo các chính sách bảo mật của đơn vị. Để làm được điều này, các công cụ dò quét thường xác định OSs và các ứng dụng chính đang chạy trên máy chủ và so khớp chúng với những lỗ hổng đã biết trong cơ sở dữ liệu.

  • Tuy nhiên các công cụ dò quét này có một vài yếu điểm. Cụ thể là chúng chỉ xác định được những lỗ hổng bề ngoài mà không thể xác định được mức độ rủi ro một cách tổng thể của hệ thống. Mặc dù việc xử lý dò quét là hoàn toàn tự động, nhưng những công cụ này lại có tỉ lệ dự đoán sai (false positives) tương đối cao (thông báo lỗi mà trong thực tế là không tồn tại). Điều này có nghĩa là những cá nhân, quản trị có kinh nghiệm về an toàn thông tin phải đánh giá lại kết quả dò quét. Thêm nữa các công cụ dò quét thường không xác định được lỗ hổng trong mã nguồn, hoặc các ứng dụng đã chỉnh sửa tùy biến.

  • Cần cập nhật định kì cơ sở dữ liệu các lỗ hổng mới nhất cho công cụ dò quét để đạt hiệu quả cao nhất. Các công cụ dò quét lỗ hổng cung cấp khả năng:

  • Xác định các host đang hoạt động trên mạng.

  • Xác định các dịch vụ (port) đang hoạt động trên server và lỗ hổng của các dịch vụ này.

  • Xác định các ứng dụng bị lộ thông tin.

  • Xác định hệ điều hành.

  • Xác định các lỗ hổng liên quan đến hệ điều hành và ứng dụng.

  • Kiểm thử mức độ phù hợp khi sử dụng ứng dụng hoặc áp dụng các chính sách bảo mật.

  • Một vài chú ý khi sử dụng cac công cụ dò quét lỗ hổng đó là: Cần phải có các nhân có kinh nghiệm rào soát đánh giá lại kết quả quét. Việc dò quét có thể gây ảnh hưởng tới vận hành dịch vụ hệ thống do tiêu tốn băng thông mạng, làm chậm thời gian trả lời request, … Tuy nhiên việc sử dụng các công cụ quét lỗ hổng đặc biệt quan trọng do nó giúp phát hiện các lỗ hổng nhanh nhất có thể đề phòng bị kẻ tấn công lợi dụng và khai thác. Việc đặt lịch quét định kì nên được thiết lập tùy đặc thù từng đơn vị, nhiều tổ chức chạy quét lỗ hổng ngay lập tức khi cơ sở dữ liệu các lỗ hổng được cập nhật.

  • Khuyến cáo nên sử dụng nhiều hơn một loại công cụ dò quét lỗ hổng. Do việc dò quét không thể phát hiện được tất cả những lỗ hổng trên hệ thống nên việc sử dụng nhiều công cụ dò quét sẽ làm tăng hiệu quả của việc dò quét lỗ hổng. Thông thường nên sử dụng một công cụ thương mại và một công cụ miễn phí. 

9.2 Đánh giá an toàn thông tin (Penetration Testing)

  • Đánh giá an toàn thông tin hay kiểm thử thâm nhậm là việc kiểm tra an ninh hệ thống, trong đó người kiểm thử cố gắng phá vỡ các tính năng bảo mật của một hệ thống dựa trên sự hiểu biết của họ về việc thiết kế và cài đặt hệ thống. Việc đánh giá này đặc biệt được khuyến cáo áp dụng cho các hệ thống phức tạp và quan trọng. Tuy nhiên việc đánh giá này không phải đơn giản, yêu cầu những cá nhân chuyên nghiệp và có kinh nghiệm để đánh giá đạt kết quả cao và giảm thiểu rủi ro cho hệ thống khi đánh giá.

Công tác đánh giá an toàn thông tin mang lại những lợi ích sau:

  • Kiểm thử mạng sử dụng các cách thức và công cụ tương tự như kẻ tấn công.

  • Xác nhận lại những lỗ hổng đã có.

  • Khai thác sâu nhất có thể từ lỗ hổng tìm được.

  • Chứng minh các lỗ hổng một cách thực tế.

  • Cung cấp việc demo, minh họa cần thiết.

  • Cho phép kiểm thử các thủ tục và mức độ nhạy cảm của các yếu tố con người trong hình thức tấn công social engineering.

10. Khôi phục Web Server sau sự cố mất an toàn thông tin

  • Khi Web Server bị tấn công, việc đầu tiên cần làm là vạch ra các hành động để chống lại cuộc tấn công, thứ tự chính xác của các bước hành động.

  • Quản trị viên của Web server nên tuân theo các chính sách và quy trình của tổ chức trong việc xử lý tình huống bất ngờ.

  • Các bước thông thường thực hiện sau khi phát hiện bị tấn công như sau:

  • Báo cáo sự việc đến những người có khả năng ứng cứu.

  • Cách ly hệ thống bị tấn công.

  • Tham khảo ý kiến một số đối tượng như quản lý, tư vấn luật pháp.

  • Điều tra các máy tương tự để xem hacker có tấn công các hệ thống khác không.

  • Phân tích cuộc xâm nhập, bao gồm:

  • Trạng thái hiện tại của server.

  • Sửa đổi các phần mềm và cấu hình hệ thống.

  • Sửa đổi dữ liệu.

  • Các công cụ và dữ liệu còn lưu lại bởi kẻ tấn công.

  • Dò tìm xâm nhập hệ thống và các file log tường lửa.

  • Khôi phục hệ thống

  • Cài đặt phiên bản sạch của OS, ứng dụng, các bản vá cần thiết, và nội dung Web, hoặc khôi phục hệ thống từ các bản backup.

  • Tắt các dịch vụ không cần thiết.

  • Triển khai tất cả các bản vá.

  • Đổi tất cả các mật khẩu (bao gồm cả các máy không bị tấn công, nếu các mật khẩu đó đã bị kẻ tấn công thu thập hoặc sử dụng chung mật khẩu trên máy khác).

  • Cấu hình lại các thành phần bảo mật của mạng.

  • Kiểm thử lại hệ thống

  • Kết nối lại hệ thống với mạng

  • Giám sát hệ thống và mạng mà kẻ tấn công cố gắng truy cập lại.

  • Ghi lại bài học đã học được.

  • Trong đó, việc quyết định cài lại hệ điều hành hay không phụ thuộc vào các nhân tố sau:

  • Mức độ truy cập mà kẻ tấn công đạt được (root, user, guest, system).

  • Loại tấn công (internal hay external).

  • Mục đích của cuộc tấn công (deface, kho phần mềm, hoặc để tấn công các nền tảng khác).

  • Phương thức sử dụng để tấn công hệ thống.

  • Các hành động của kẻ tấn công trong và sau cuộc tấn công.

  • Quá trình bị tấn công.

  • Phạm vi tấn công trên toàn mạng (số máy bị tấn công).

Comments

Popular posts from this blog

Python - Multithread to read one file

Install Xposed Inspector and Frida on Genymotion

OpenCA tutorial