21 điểm bởi carnoxen 2025-01-21 | 7 bình luận | Chia sẻ qua WhatsApp

Trong bản thân sản phẩm

Ngôn ngữ không an toàn bộ nhớ (C, C++ v.v.)

Nên dùng ngôn ngữ an toàn bộ nhớ bất cứ khi nào có thể, và các chương trình hiện có không đáp ứng điều này cần được thay thế dần trước cuối năm 2025.

Thực thi trực tiếp câu lệnh SQL

Hãy dùng truy vấn tham số hóa, câu lệnh dựng sẵn hoặc ORM.

Thực thi trực tiếp lệnh hệ điều hành

Nội dung người dùng nhập không được là chính câu lệnh. Thay vì chạy lệnh trực tiếp, nên dùng hàm thư viện tích hợp sẵn hoặc chỉ cho phép đầu vào gồm chữ cái tiếng Anh/chữ số/dấu gạch dưới.

Sử dụng mật khẩu quá phổ biến

Cần thiết kế để tránh việc này càng nhiều càng tốt bằng các cách như sau.

  • Cung cấp mật khẩu duy nhất ngay từ đầu.
  • Yêu cầu người dùng tạo mật khẩu mạnh trong quá trình cài đặt.
  • Đặt giới hạn thời gian cho mật khẩu như MFA.
  • Yêu cầu truy cập vật lý để có được thông tin xác thực chắc chắn.
  • Triển khai chiến dịch hoặc chuyển sang phương thức xác thực an toàn hơn hiện tại.

Bỏ mặc lỗ hổng đã biết

Tất cả các lỗ hổng được nêu trên trang đó đều phải được ngăn chặn. Khi có lỗ hổng mới được báo cáo, cần xử lý kịp thời và cảnh báo những người dùng chưa cập nhật lên phiên bản đã được vá.

Thư viện mã nguồn mở có lỗ hổng

Cần có trách nhiệm thông báo và đóng góp cho thư viện đang sử dụng khi có vấn đề liên quan. Điều này cũng bao gồm các biện pháp như sau.

  • Lập SBOM: cho thấy phần mềm sử dụng những thư viện nào.
  • Các việc cần áp dụng với thư viện mã nguồn mở phụ thuộc
    • Thực hiện kiểm tra bảo mật.
    • Chọn các dự án chất lượng tốt, được duy trì liên tục, được bảo vệ tốt và bảo trì tốt. Cũng nên tuân theo các nguyên tắc bảo mật như thế này.
    • Cần thường xuyên kiểm tra xem có lỗ hổng đã biết hay không.
    • Nhà cung cấp nên giữ sẵn bản sao và không nên cập nhật từ nơi chưa được xác minh.
  • Cần tính đến chi phí cập nhật lên phiên bản chính mới hoặc nhận bản vá bảo mật.
    Nếu lỗ hổng không ảnh hưởng đến sản phẩm, cần công khai lý do vì sao lỗ hổng đó không ảnh hưởng.

Thuật toán mã hóa có lỗ hổng hoặc không rõ nguồn gốc (TLS 1.0/1.1, DES, MD5 v.v.)

Phải sử dụng các thuật toán mới nhất. Ngoài ra, cũng cần chuẩn bị cho các thuật toán mật mã hậu lượng tử đã được chuẩn hóa theo hướng dẫn của NIST.

Khóa bí mật nằm trong mã nguồn

Cần dùng Secret Manager để chương trình có thể truy xuất khóa bí mật một cách an toàn. Đồng thời cũng phải kiểm tra xem mã nguồn có chứa khóa bí mật hay không.

Trong các tính năng bảo mật

Không hỗ trợ MFA (bao gồm cả trường hợp chỉ hỗ trợ passkey)

Ngoại trừ những thứ mà độ trễ có thể gây nguy hiểm như thiết bị y tế trong phòng cấp cứu, về nguyên tắc cần tự triển khai MFA hoặc cho phép dùng trình xác thực bên ngoài. Phải yêu cầu điều này với quản trị viên, và quản trị viên phải yêu cầu điều đó với người dùng trong tổ chức.

Không cung cấp dấu vết xâm nhập

  • Là tính năng rất cơ bản, cần tạo log liên quan đến thay đổi hoặc truy vấn cấu hình, lịch sử đăng nhập và truy cập thông tin.
  • Với nhà cung cấp đám mây, cần lưu giữ các log này ít nhất 6 tháng và cho người dùng xem được mà không thu thêm chi phí.

Trong quy trình và chính sách của tổ chức

Không phát hành CVE

Các lỗ hổng nghiêm trọng hoặc có thể gây ảnh hưởng lớn cần được công bố ngay lập tức.

Không công khai cách công bố lỗ hổng (VDP)

Cần công khai các chính sách như sau.

  • Chấp thuận việc kiểm thử của công chúng
  • Cam kết không thực hiện hành động pháp lý đối với những người hành động thiện chí
  • Kênh báo cáo rõ ràng
  • Thực tiễn tốt nhất của CVD(Coordinated Vulnerability Disclosure) và tiêu chuẩn quốc tế
    Các lỗ hổng được báo cáo cần được sửa kịp thời theo thứ tự mức độ rủi ro.

(Trong trường hợp on-premises) thời hạn hỗ trợ không rõ ràng

Cần truyền đạt rõ ràng thời hạn hỗ trợ và cung cấp các bản cập nhật bảo mật trong suốt thời gian đó.


7 bình luận

 
bbulbum 2025-01-21

Bảo mật là kiểu chỉ cần lơ là một khoảnh khắc là toi,,! (hình như tôi đã thấy câu này trong quân đội rồi)

 
yolatengo 2025-01-22

Đừng bao giờ bỏ cuộc!

 
kandk 2025-01-21

Lại rộ lên câu chuyện đừng dùng ORM nữa nhỉ..

 
regentag 2025-01-21

Chỉ cần dùng Prepared Statement thay vì ORM.

 
roxie 2025-01-22

zzz

 
ilikeall 2025-01-21

Dù là gì thì cũng có nguyên tắc, chỉ là khó tuân thủ thôi...

 
felizgeek 2025-01-21

Tôi đồng ý
Yêu cầu người dùng tạo mật khẩu mạnh != bắt buộc phải có ký tự đặc biệt, chữ hoa/chữ thường tiếng Anh và số
Chỉ cần đủ dài một chút thì đó đã là mật khẩu mạnh rồi.