Quét lỗ hổng website online: đọc kết quả thế nào cho đúng?

Một lượt quét là điểm bắt đầu, không phải giấy chứng nhận

Kết luận ngắn gọn: website đạt điểm cao sau một lượt quét vẫn có thể còn rủi ro. Scanner nhìn hệ thống từ bên ngoài, gửi các yêu cầu đã định trước rồi so phản hồi với mẫu nhận diện. Cách này làm tốt những việc có thể lặp lại như kiểm tra HTTPS, security header, cổng mở, phiên bản phần mềm hoặc một số dấu hiệu lỗ hổng đã biết.

Điểm mù nằm ở ngữ cảnh. Công cụ không tự biết khách hàng A có đọc được đơn hàng của khách hàng B hay không, nhân viên thường có thể đổi quyền quản trị hay luồng hoàn tiền có bị lạm dụng không. OWASP Top 10:2025 xếp lỗi kiểm soát truy cập ở vị trí đầu, trong khi cấu hình bảo mật sai đứng thứ hai. Quét tự động hỗ trợ tốt cho phần cấu hình; kiểm soát truy cập và logic nghiệp vụ thường cần tài khoản thử nghiệm, vai trò so sánh và người đánh giá tác động.

• ✓Dùng scanner để lập đường cơ sở và tìm tín hiệu có thể tự động hóa.
• ✓Không dùng một điểm số duy nhất để khẳng định website an toàn.
• ✓Chỉ quét website bạn sở hữu hoặc đã được cho phép kiểm tra.

Một báo cáo hữu ích không làm bạn sợ bằng số lượng cảnh báo. Nó giúp bạn biết điều gì đúng, điều gì chưa chắc và nên sửa gì trước.

Đừng đọc severity trước khi đọc bằng chứng

Nhãn Critical, High hay Medium giúp sắp xếp màn hình, nhưng chưa đủ để ra quyết định. Hãy mở từng phát hiện và tìm bốn phần: URL hoặc cổng bị ảnh hưởng, điều kiện để lỗi xuất hiện, phản hồi làm căn cứ nhận diện và tác động nếu khai thác thành công. Một cảnh báo không ghi rõ bốn phần này nên được xem là tín hiệu cần xác minh, không phải kết luận cuối cùng.

Nuclei dùng các template chứa logic gửi yêu cầu và nhận diện phản hồi. Tài liệu của ProjectDiscovery nói rõ template cộng đồng vẫn có thể tạo false positive nếu matcher chưa đủ chặt. False positive nghĩa là công cụ báo có vấn đề nhưng khi kiểm tra đúng điều kiện, vấn đề không tồn tại. Vì vậy, hãy thử tái hiện với tác động thấp, so với một phản hồi bình thường và lưu bằng chứng đã lược dữ liệu nhạy cảm trước khi giao việc cho đội phát triển.

• ✓Critical nhưng không tái hiện được: giữ ở trạng thái cần xác minh.
• ✓Medium có thể lộ dữ liệu khách hàng: nâng ưu tiên theo tác động thực tế.
• ✓Thông tin phiên bản đơn thuần: kiểm tra CVE và điều kiện áp dụng trước khi kết luận.

Bốn nhóm kết quả nên đọc theo cách khác nhau

Kết quả hạ tầng cho biết website có truy cập được không, dùng HTTPS ra sao và cổng nào đang mở. Cổng mở không tự động là lỗ hổng; câu hỏi đúng là dịch vụ đó có cần công khai, có được cập nhật và có yêu cầu xác thực phù hợp hay không. Với TLS, ưu tiên chứng chỉ hợp lệ, chuyển hướng HTTP sang HTTPS đúng và cấu hình không để lộ giao thức yếu.

Security header là lớp hướng dẫn trình duyệt. Mozilla HTTP Observatory kiểm tra những kiểm soát như HSTS, Content-Security-Policy và X-Content-Type-Options; đồng thời lưu ý kết quả cho API có thể không phản ánh đầy đủ tư thế bảo mật của API. Nhóm công nghệ và CVE cần đối chiếu phiên bản thật. Nhóm mẫu tấn công như injection, XSS hoặc file phơi lộ cần bằng chứng tối thiểu và không nên gửi payload nguy hiểm trên production chỉ để chứng minh một cảnh báo.

• ✓Hạ tầng: dịch vụ nào đang lộ ra Internet và có thực sự cần thiết?
• ✓HTTP/TLS: trình duyệt có được buộc dùng kết nối an toàn và chính sách phòng vệ phù hợp?
• ✓Công nghệ/CVE: phiên bản quan sát được có thực sự nằm trong phạm vi ảnh hưởng?
• ✓Mẫu lỗ hổng: có yêu cầu, phản hồi và đối chứng đủ để tái hiện an toàn hay chưa?

Ưu tiên việc sửa bằng rủi ro, không bằng số lượng cảnh báo

Trong 30 phút đầu, xác nhận đúng tài sản và đóng các phát hiện rõ ràng có hậu quả cao: dịch vụ quản trị mở công khai, tệp bí mật bị lộ, dependency có lỗ hổng đang bị khai thác hoặc chứng chỉ hết hạn. Trong ngày, gán người xử lý, ghi điều kiện tái hiện và giữ lại phản hồi trước khi thay đổi. Đừng sửa hàng loạt header mà không biết ứng dụng đang dùng iframe, CDN hoặc script bên thứ ba nào.

Trong tuần, gom cảnh báo theo nguyên nhân gốc. Nhiều phát hiện có thể cùng biến mất sau một thay đổi cấu hình, nâng phiên bản hoặc đóng dịch vụ không dùng. Sau khi sửa, chạy lại đúng phép kiểm tra và thêm một đối chứng âm: yêu cầu tương tự nhưng không mang điều kiện gây lỗi phải cho kết quả bình thường. Cách này giúp phân biệt sửa thật với việc chỉ làm scanner ngừng báo.

• ✓Ưu tiên: tác động lớn, dễ khai thác, tài sản công khai và chưa có lớp giảm thiểu.
• ✓Gộp phát hiện theo nguyên nhân gốc thay vì tạo một ticket cho mỗi dòng cảnh báo.
• ✓Retest sau sửa và ghi ngày, phiên bản cùng bằng chứng mới.

Khi nào cần kiểm tra sâu hơn scanner?

Hãy chuyển sang security review có phạm vi khi website có đăng nhập, nhiều vai trò, thanh toán, upload, dữ liệu khách hàng, trang quản trị hoặc API. Đây là các vùng mà người kiểm tra cần hiểu đối tượng được bảo vệ, trạng thái bình thường và ranh giới quyền hạn. Một scanner từ bên ngoài không thể tự tạo đủ bối cảnh để kết luận nhân viên, khách hàng và quản trị viên đang được tách quyền đúng.

Một đợt kiểm tra sâu nên thống nhất domain, tài khoản, luồng quan trọng, dữ liệu thử, hành động bị cấm và cách phối hợp nếu có sự cố. Đầu ra cần có bằng chứng tối thiểu, ảnh hưởng, hướng sửa và retest. Quét tự động vẫn hữu ích trong quy trình này, nhưng là một lớp thu thập tín hiệu bên cạnh review cấu hình, so sánh vai trò, kiểm tra thủ công và trao đổi với đội phát triển.

• ✓Trước khi ra mắt hoặc sau thay đổi lớn về đăng nhập, thanh toán và API.
• ✓Khi scanner báo lỗi nghiêm trọng nhưng chưa đủ bằng chứng để kết luận.
• ✓Khi khách hàng, đối tác hoặc quản lý cần báo cáo có phạm vi và người chịu trách nhiệm.