Những cách làm tệ trong bảo mật sản phẩm
(cisa.gov)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 đó.
- One-click exploit trên KakaoTalk
- GN⁺: NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ) cấm yêu cầu cấu thành ký tự cụ thể trong mật khẩu
- Nhà Trắng kêu gọi các nhà phát triển tránh C và C++, sử dụng ngôn ngữ 'an toàn bộ nhớ'
- Tự hack xe của tôi: Hyundai Ioniq: phát hiện chuỗi mã hóa RSA có thể tìm thấy bằng Google trong mã nguồn
7 bình luận
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)
Đừng bao giờ bỏ cuộc!
Lại rộ lên câu chuyện đừng dùng ORM nữa nhỉ..
Chỉ cần dùng Prepared Statement thay vì ORM.
zzz
Dù là gì thì cũng có nguyên tắc, chỉ là khó tuân thủ thôi...
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.