Lỗ hổng bảo mật là gì? Nguyên nhân, tác hại và giải pháp bảo mật từ FPT IS

Trong làn sóng chuyển đổi số mạnh mẽ, doanh nghiệp phải đối diện với hàng loạt rủi ro đến từ không gian mạng, đặc biệt là các lỗ hổng bảo mật. Câu hỏi đặt ra là: điều gì khiến những lỗ hổng ấy trở thành mối nguy nghiêm trọng? Và đâu là giải pháp giúp doanh nghiệp chủ động bảo vệ mình trước những thách thức này? Cùng khám phá trong bài viết sau của FPT IS.

1. Lỗ hổng bảo mật là gì?

Lỗ hổng bảo mật (Security Vulnerability) là điểm yếu trong mã phần mềm, cấu hình hệ thống hoặc quy trình vận hành, dễ bị kẻ tấn công khai thác để truy cập trái phép, làm suy giảm tính bảo mật, toàn vẹn và khả dụng của hệ thống. Hệ quả là dịch vụ bị gián đoạn, dữ liệu nhạy cảm bị đánh cắp, gây thiệt hại cho tổ chức lẫn cá nhân.

Một số tác hại chính mà doanh nghiệp phải đối mặt khi lỗ hổng bị khai thác:

• Mất dữ liệu khách hàng, thông tin mật.
• Thiệt hại tài chính và chi phí khắc phục.
• Mất uy tín, giảm niềm tin từ khách hàng/đối tác.
• Rủi ro pháp lý do vi phạm quy định bảo mật dữ liệu.

2. Các loại lỗ hổng bảo mật phổ biến hiện nay

Trong lĩnh vực an toàn thông tin, OWASP (Open Web Application Security Project) được xem là một trong những tổ chức uy tín nhất về nghiên cứu và phát triển tiêu chuẩn bảo mật cho ứng dụng web. Đây là tổ chức phi lợi nhuận toàn cầu, thành lập từ năm 2001, với sứ mệnh nâng cao nhận thức cộng đồng và cải thiện khả năng phòng vệ trước các mối đe dọa mạng.

OWASP cung cấp nhiều tài nguyên cho doanh nghiệp và chuyên gia an ninh mạng trong việc xây dựng, kiểm thử và vận hành phần mềm an toàn, trong đó nổi bật nhất là OWASP Top 10, liệt kê 10 lỗ hổng bảo mật ứng dụng web phổ biến và nguy hiểm nhất (phiên bản mới nhất năm 2021). Đây là chuẩn tham chiếu quan trọng trong ngành, thường dùng để kiểm tra và đánh giá bảo mật ứng dụng web.

1. A01:2021 – Kiểm soát truy cập bị hỏng (Broken Access Control)

Kiểm soát truy cập nhằm đảm bảo người dùng chỉ được thực hiện các hành động trong phạm vi quyền hạn được cấp. Khi cơ chế này bị lỗi, kẻ tấn công có thể truy cập dữ liệu trái phép, chỉnh sửa hoặc xóa thông tin quan trọng, thậm chí chiếm quyền thực hiện các chức năng đặc thù của quản trị viên. Đây là một trong những lỗ hổng bảo mật nghiêm trọng và thường gặp nhất.

Các lỗ hổng phổ biến:

• Vi phạm nguyên tắc đặc quyền tối thiểu hoặc thiếu cơ chế từ chối theo mặc định: quyền truy cập lẽ ra chỉ cấp cho người dùng cụ thể nhưng lại khả dụng cho bất kỳ ai.
• Bỏ qua kiểm soát truy cập bằng cách chỉnh sửa URL, tham số, trạng thái ứng dụng, mã HTML hoặc sử dụng công cụ tấn công API.
• Cho phép người dùng chỉ cần biết mã định danh (ID) của tài khoản là có thể xem hoặc chỉnh sửa thông tin tài khoản của người khác.
• Truy cập API thiếu quyền kiểm soát cho POST, PUT, DELETE.
• Nâng cao đặc quyền, ví dụ: tài khoản thường nhưng thao tác được như quản trị viên.
• Thao túng siêu dữ liệu, chẳng hạn như phát lại hoặc giả mạo mã thông báo kiểm soát truy cập JSON Web Token (JWT) hoặc cookie hoặc trường ẩn bị thao túng để nâng cao đặc quyền hoặc lạm dụng việc vô hiệu hóa JWT.
• Cấu hình CORS sai cho phép truy cập API từ các nguồn không được ủy quyền/không đáng tin cậy.
• Buộc duyệt (forced browsing) đến các trang dành cho người đã xác thực hoặc quản trị bằng tài khoản chưa đủ quyền.

Cách kiểm tra lỗ hổng bảo mật:

• Ngoại trừ tài nguyên công khai, mọi truy cập đều bị từ chối mặc định.
• Triển khai cơ chế kiểm soát truy cập một lần và tái sử dụng chúng trong toàn bộ ứng dụng, bao gồm giảm thiểu việc sử dụng Chia sẻ tài nguyên nguồn gốc chéo (CORS).
• Kiểm soát truy cập mô hình phải thực thi quyền sở hữu bản ghi thay vì chấp nhận rằng người dùng có thể tạo, đọc, cập nhật hoặc xóa bất kỳ bản ghi nào.
• Các yêu cầu giới hạn kinh doanh ứng dụng duy nhất phải được thực thi theo mô hình miền.
• Vô hiệu hóa danh sách thư mục máy chủ web và đảm bảo siêu dữ liệu tệp (ví dụ: .git) và tệp sao lưu không có trong thư mục gốc của web.
• Ghi lại các lỗi kiểm soát truy cập, cảnh báo người quản trị khi cần thiết (ví dụ: lỗi lặp lại).
• Giới hạn tốc độ truy cập API và bộ điều khiển để giảm thiểu tác hại từ công cụ tấn công tự động.
• Mã định danh phiên có trạng thái nên bị vô hiệu hóa trên máy chủ sau khi đăng xuất. Mã thông báo JWT không trạng thái nên có thời gian tồn tại ngắn để giảm thiểu cơ hội cho kẻ tấn công. Đối với JWT tồn tại lâu hơn, chúng tôi khuyến nghị nên tuân thủ các tiêu chuẩn OAuth để thu hồi quyền truy cập..

2. A02:2021 – Lỗi mã hóa (Cryptographic Failures)

Lỗi mật mã xảy ra khi dữ liệu nhạy cảm (mật khẩu, thẻ tín dụng, hồ sơ sức khỏe, thông tin cá nhân, bí mật kinh doanh…) không được bảo vệ đúng cách trong lưu trữ hoặc truyền tải, đặc biệt trong bối cảnh tuân thủ GDPR, PCI DSS.

Các vấn đề thường gặp:

• Truyền dữ liệu clear text hoặc qua giao thức lỗi thời (HTTP, FTP, SMTP…).
• Thuật toán/giao thức yếu, lỗi thời (MD5, SHA-1, ECB, PKCS#1 v1.5).
• Quản lý khóa kém an toàn (khóa mặc định, tái sử dụng, lưu trong mã nguồn).
• Thiếu HTTP security headers, chứng chỉ và chuỗi tin cậy không được xác minh.
• IV, randomness, padding, hash không an toàn (dùng lại, yếu, lỗi thời: MD5, SHA1…).
• Không dùng mã hóa kèm xác thực (AE), hoặc lộ thông tin qua lỗi/side-channel.

Biện pháp phòng ngừa:

• Phân loại & giảm lưu trữ dữ liệu nhạy cảm: chỉ giữ khi cần, xóa/cắt bớt sớm.
• Mã hóa khi lưu trữ & truyền tải: dùng thuật toán/giao thức mạnh, TLS (có FS), ưu tiên mã hóa máy chủ, bật HSTS, tránh FTP/SMTP cho dữ liệu nhạy cảm.
• Bảo mật mật khẩu: dùng hàm băm thích ứng có muối (Argon2, bcrypt, scrypt, PBKDF2).
• Quản lý khóa & IV: sinh ngẫu nhiên từ CSPRNG (bộ tạo số giả ngẫu nhiên an toàn về mặt mật mã), không tái sử dụng.
• Mã hóa xác thực (AEAD): thay cho mã hóa thuần.
• Ngẫu nhiên & thuật toán: đảm bảo CSPRNG, tránh thuật toán cũ (MD5, SHA-1…).
• Kiểm tra độc lập: rà soát cấu hình và cài đặt bảo mật.

Xem thêm: PCI DSS là tiêu chuẩn gì?

3. A03:2021 – Tấn công chèn mã độc (Injection)

Ứng dụng dễ bị chèn mã độc khi:

• Dữ liệu đầu vào không được kiểm soát (xác thực, lọc, làm sạch).
• Truy vấn động hoặc lệnh không tham số hóa, dữ liệu đưa thẳng vào trình thông dịch.
• Dữ liệu độc hại được dùng trong tham số ORM để truy xuất dữ liệu nhạy cảm.
• Nối chuỗi trực tiếp với SQL hoặc lệnh hệ điều hành.

Cách phát hiện lỗi tấn công chèn mã độc:

• Kiểm tra mã nguồn là cách hiệu quả nhất.
• Dùng kiểm tra tự động với mọi dữ liệu đầu vào (tham số, header, URL, cookie, JSON, SOAP, XML).
• Tích hợp SAST, DAST, IAST vào CI/CD để phát hiện sớm.

Đánh giá lỗ hổng bảo mât:

• Tách dữ liệu khỏi lệnh/truy vấn: dùng API an toàn hoặc ORM với tham số hóa, tránh đưa trực tiếp vào thông dịch.
• Xác thực đầu vào phía máy chủ: cần thiết nhưng không tuyệt đối (dữ liệu hợp lệ vẫn có thể chứa ký tự đặc biệt).
• Truy vấn động: phải thoát ký tự đặc biệt đúng cú pháp.

4. A04:2021 – Thiết kế không an toàn (Insecure Design)

Thiết kế không an toàn xảy ra khi hệ thống thiếu hoặc có kiểm soát bảo mật kém. Khác với lỗi triển khai:

• Thiết kế an toàn vẫn có thể lỗi khi triển khai.
• Nhưng thiết kế không an toàn thì không thể khắc phục, vì ngay từ đầu đã thiếu biện pháp bảo vệ cần thiết.

Nguyên nhân: thường do không phân tích đầy đủ rủi ro kinh doanh, dẫn đến xác định sai mức độ bảo mật cần thiết.

Một số lỗi tiêu biểu:

• CWE-209: Tạo Thông báo Lỗi Chứa Thông tin Nhạy cảm
• CWE-256: Lưu trữ Thông tin Xác thực Không được Bảo vệ
• CWE-501: Vi phạm Ranh giới Tin cậy
• CWE-522: Thông tin Xác thực Không được Bảo vệ đầy đủ

Phòng ngừa:

• Xây dựng SDL với chuyên gia AppSec, dùng thư viện/thành phần thiết kế an toàn sẵn có.
• Áp dụng mô hình hóa mối đe dọa (threat modeling) cho các quy trình quan trọng (xác thực, phân quyền, logic nghiệp vụ, luồng dữ liệu).
• Tích hợp yêu cầu bảo mật vào user story, thêm plausibility check ở mọi tầng (frontend–backend).
• Viết unit test, integration test để kiểm chứng khả năng kháng cự.
• Xây dựng use-case & misuse-case cho từng tầng.
• Phân tách hệ thống, mạng theo mức độ bảo mật, thiết kế tenant isolation mạnh.
• Giới hạn tài nguyên theo từng người dùng/dịch vụ.

5. A05:2021- Lỗi cấu hình bảo mật (Security Misconfiguration)

Thống kê cho thấy 90% ứng dụng kiểm thử có ít nhất một cấu hình sai, trung bình 4,51% và hơn 208.000 trường hợp CWE liên quan. Nguyên nhân chủ yếu do phần mềm ngày càng nhiều tùy chọn cấu hình phức tạp.

Ứng dụng dễ bị tấn công nếu:

• Thiếu biện pháp tăng cường bảo mật phù hợp.
• Kích hoạt/cài đặt tính năng không cần thiết (ví dụ như cấp các quyền không cần thiết).
• Tài khoản hoặc mật khẩu mặc định khiến tin tặc dễ tấn công.
• Các thông báo lỗi cung cấp quá nhiều thông tin cho tin tặc đoán mật khẩu đăng nhập.
• Nâng cấp bản cập nhật mới nhưng các tính năng bảo mật chưa bật hoặc cấu hình không an toàn.
• Phần mềm lỗi thời dễ bị tấn công.

Phòng ngừa:

• Xây dựng quy trình lặp lại, có thể tự động hóa; cấu hình đồng nhất nhưng thông tin đăng nhập khác nhau.
• Sử dụng nền tảng tối giản, loại bỏ thành phần/tài liệu/mẫu không cần thiết, không sử dụng.
• Xem xét và cập nhật cấu hình phù hợp với tất cả các ghi chú, bản cập nhật và bản vá bảo mật như một phần của quy trình quản lý bản vá.
• Xem xét các quyền lưu trữ đám mây.
• Kiến trúc ứng dụng phân đoạn cung cấp khả năng phân tách hiệu quả và an toàn giữa các thành phần hoặc đối tượng thuê, với phân đoạn, chứa hoặc nhóm bảo mật đám mây (ACL).
• Gửi chỉ thị bảo mật tới máy khách, ví dụ: Tiêu đề bảo mật.
• Tự động kiểm tra hiệu quả cấu hình trên mọi môi trường.

6. A06:2021 – Các thành phần dễ bị tấn công và lỗi thời (Vulnerable and Outdated Components)

Chúng ta dễ gặp phải lỗ hổng bảo mật A06:2021:

• Nếu không biết phiên bản của tất cả các thành phần mình sử dụng (cả phía máy khách và phía máy chủ). Điều này bao gồm các thành phần trực tiếp sử dụng cũng như các phụ thuộc lồng nhau.
• Nếu phần mềm không được nâng cấp hoặc lỗi thời.
• Nếu không thường xuyên đánh giá lỗ hổng bảo mật và đăng ký nhận bản tin bảo mật liên quan đến các thành phần bạn sử dụng.
• Nếu không sửa hoặc nâng cấp nền tảng, khung và các thành phần phụ thuộc cơ bản một cách kịp thời dựa trên rủi ro. Điều này thường xảy ra trong các môi trường mà việc vá lỗi được thực hiện hàng tháng hoặc hàng quý dưới sự kiểm soát thay đổi, khiến tổ chức phải đối mặt với nguy cơ tiếp xúc không cần thiết với các lỗ hổng đã được sửa trong nhiều ngày hoặc nhiều tháng.
• Nếu các nhà phát triển phần mềm không kiểm tra tính tương thích của các thư viện đã cập nhật, nâng cấp hoặc vá lỗi.
• Nếu bạn không bảo mật cấu hình của các thành phần.

Phòng ngừa:

• Loại bỏ các tính năng, thành phần và tài liệu không cần thiết.
• Liên tục kiểm tra phiên bản của cả thành phần phía máy khách và phía máy chủ (ví dụ: framework, thư viện) và các thành phần phụ thuộc của chúng bằng các công cụ như version, OWASP Dependency Check, retire.js,… Liên tục theo dõi các nguồn như Common Vulnerability and Exposures (CVE) và National Vulnerability Database (NVD) để tìm lỗ hổng trong các thành phần. Sử dụng các công cụ phân tích thành phần phần mềm để tự động hóa quy trình. Đăng ký nhận thông báo qua email về các lỗ hổng bảo mật liên quan đến các thành phần bạn sử dụng.
• Chỉ lấy các thành phần từ nguồn chính thức qua các liên kết an toàn. Ưu tiên các gói đã được ký để giảm nguy cơ bao gồm các thành phần độc hại đã bị sửa đổi
• Giám sát các thư viện và thành phần không được bảo trì hoặc không tạo bản vá bảo mật cho các phiên bản cũ hơn. Nếu không thể vá, hãy cân nhắc triển khai bản vá ảo để giám sát, phát hiện hoặc bảo vệ trước sự cố đã phát hiện.

Mỗi tổ chức phải đảm bảo có kế hoạch liên tục để theo dõi, phân loại và áp dụng các bản cập nhật hoặc thay đổi cấu hình trong suốt vòng đời của ứng dụng.

7. A07:2021 – Lỗi nhận dạng và xác thực (Identification and Authentication Failures)

Ứng dụng dễ gặp lỗi nhận dạng và xác thực nếu:

• Cho phép các cuộc tấn công tự động như nhồi nhét thông tin đăng nhập, trong đó kẻ tấn công có danh sách tên người dùng và mật khẩu hợp lệ.
• Cho phép tấn công bằng vũ lực hoặc các hình thức tấn công tự động khác.
• Cho phép sử dụng mật khẩu mặc định, yếu hoặc mật khẩu phổ biến.
• Sử dụng quy trình khôi phục thông tin đăng nhập và quên mật khẩu yếu hoặc không hiệu quả, ví dụ như câu hỏi kiến thức cơ bản “Việt Nam ở châu lục nào”, câu hỏi dễ trả lời không thể đảm bảo an toàn.
• Sử dụng kho dữ liệu mật khẩu dạng văn bản thuần túy.
• Xác thực đa yếu tố bị thiếu hoặc không hiệu quả.
• Hiển thị mã định danh phiên trong URL.
• Sử dụng lại mã định danh phiên sau khi đăng nhập thành công.
• Phiên người dùng hoặc mã xác thực (chủ yếu là mã đăng nhập một lần (SSO)) không bị vô hiệu hóa đúng cách trong quá trình đăng xuất hoặc trong thời gian không hoạt động.

Biện pháp phòng ngừa lỗi nhận dạng và xác thực:

• Hãy triển khai xác thực đa yếu tố để ngăn chặn các cuộc tấn công nhồi nhét thông tin đăng nhập tự động, tấn công bằng vũ lực và tấn công sử dụng lại thông tin đăng nhập bị đánh cắp.
• Không gửi hoặc triển khai bằng bất kỳ thông tin xác thực mặc định nào.
• Thực hiện kiểm tra mật khẩu, so sánh với danh sách 10.000 mật khẩu tệ nhất.
• Căn chỉnh các chính sách về độ dài, độ phức tạp và luân chuyển mật khẩu theo hướng dẫn của Viện.
• Đảm bảo quá trình đăng ký, khôi phục thông tin xác thực và đường dẫn API được tăng cường bảo vệ trước các cuộc tấn công liệt kê tài khoản bằng cách sử dụng cùng một thông báo cho tất cả kết quả.
• Hạn chế trì hoãn các lần đăng nhập không thành công. Ghi lại tất cả các lỗi và cảnh báo cho quản trị viên khi phát hiện hành vi nhồi thông tin đăng nhập, tấn công brute force hoặc các hình thức tấn công khác.
• Sử dụng trình quản lý phiên tích hợp, bảo mật, phía máy chủ, tạo ID phiên ngẫu nhiên mới với độ phức tạp cao sau khi đăng nhập. Mã định danh phiên không được nằm trong URL, được lưu trữ an toàn và bị vô hiệu hóa sau khi đăng xuất và hết thời gian chờ.

8. A08:2021 – Lỗi về tính toàn vẹn của Phần mềm và Dữ liệu (Software and Data Integrity Failures)

Lỗi toàn vẹn phần mềm và dữ liệu thường xuất hiện khi:

• Ứng dụng phụ thuộc plugin, thư viện hoặc module từ nguồn không tin cậy (repo công cộng, CDN…).
• Pipeline CI/CD không an toàn, dễ bị chèn mã độc, truy cập trái phép hoặc chiếm quyền.
• Ứng dụng có cơ chế tự động cập nhật nhưng không kiểm tra chữ ký số hoặc tính toàn vẹn gói, dẫn đến nguy cơ phát tán bản cập nhật độc hại.
• Cho phép serialization/encoding dữ liệu mà attacker có thể quan sát và chỉnh sửa, dẫn đến lỗ hổng insecure deserialization.

Phòng ngừa:

• Sử dụng chữ ký số hoặc cơ chế tương tự để xác minh phần mềm hoặc dữ liệu có đến từ nguồn dự kiến ​​và không bị thay đổi hay không.
• Đảm bảo các thư viện và phần mềm phụ thuộc, chẳng hạn như npm hoặc Maven, đang sử dụng các kho lưu trữ đáng tin cậy. Nếu bạn có hồ sơ rủi ro cao hơn, hãy cân nhắc lưu trữ một kho lưu trữ nội bộ đã được kiểm tra và xác thực.
• Đảm bảo rằng công cụ bảo mật chuỗi cung ứng phần mềm, chẳng hạn như OWASP Dependency Check hoặc OWASP CycloneDX, được sử dụng để xác minh rằng các thành phần không chứa lỗ hổng đã biết
• Đảm bảo có quy trình xem xét các thay đổi về mã và cấu hình để giảm thiểu khả năng mã độc hoặc cấu hình độc hại có thể xâm nhập vào đường ống phần mềm của bạn.
• Đảm bảo rằng quy trình CI/CD của bạn có sự phân tách, cấu hình và kiểm soát truy cập phù hợp để đảm bảo tính toàn vẹn của mã chạy qua các quy trình xây dựng và triển khai.
• Đảm bảo rằng dữ liệu tuần tự hóa chưa được ký hoặc chưa được mã hóa không được gửi đến các máy khách không đáng tin cậy mà không có một số hình thức kiểm tra tính toàn vẹn hoặc chữ ký số để phát hiện hành vi giả mạo hoặc phát lại dữ liệu tuần tự hóa

9. A09:2021 – Lỗi ghi nhật ký và giám sát bảo mật (Security Logging and Monitoring Failures)

Nếu không ghi nhật ký và giám sát, các vi phạm sẽ không thể được phát hiện. Việc ghi nhật ký, phát hiện, giám sát và ứng phó chủ động không đầy đủ có thể xảy ra bất cứ lúc nào:

• Các sự kiện có thể kiểm tra, chẳng hạn như đăng nhập, đăng nhập không thành công và giao dịch có giá trị cao, sẽ không được ghi lại.
• Cảnh báo và lỗi không tạo ra thông báo nhật ký, thông báo không đầy đủ hoặc không rõ ràng.
• Nhật ký của các ứng dụng và API không được theo dõi để phát hiện hoạt động đáng ngờ.
• Nhật ký chỉ được lưu trữ cục bộ.
• Ngưỡng cảnh báo phù hợp và quy trình leo thang phản hồi không được áp dụng hoặc không hiệu quả.
• Kiểm tra xâm nhập và quét bằng các công cụ kiểm tra bảo mật ứng dụng động (DAST) (như OWASP ZAP) không kích hoạt cảnh báo.
• Ứng dụng không thể phát hiện, leo thang hoặc cảnh báo các cuộc tấn công đang diễn ra theo thời gian thực hoặc gần thời gian thực.
• Bạn có nguy cơ bị rò rỉ thông tin khi cho phép người dùng hoặc kẻ tấn công nhìn thấy các sự kiện ghi nhật ký và cảnh báo.
• Bạn có nguy cơ bị tấn công hoặc xâm nhập vào hệ thống ghi nhật ký hoặc giám sát nếu dữ liệu nhật ký không được mã hóa chính xác.

Cách phòng ngừa:

• Đảm bảo tất cả các lỗi đăng nhập, kiểm soát truy cập và xác thực đầu vào phía máy chủ có thể được ghi lại với ngữ cảnh người dùng đầy đủ để xác định các tài khoản đáng ngờ hoặc độc hại và được lưu giữ đủ thời gian để cho phép phân tích pháp y bị trì hoãn.
• Đảm bảo rằng nhật ký được tạo theo định dạng mà các giải pháp quản lý nhật ký có thể dễ dàng sử dụng.
• Đảm bảo dữ liệu nhật ký được mã hóa chính xác để ngăn chặn việc đưa mã độc hoặc tấn công vào hệ thống ghi nhật ký hoặc giám sát.
• Đảm bảo các giao dịch có giá trị cao có dấu vết kiểm toán với các biện pháp kiểm soát tính toàn vẹn để ngăn chặn việc giả mạo hoặc xóa, chẳng hạn như bảng cơ sở dữ liệu chỉ thêm vào hoặc tương tự.
• Các nhóm DevSecOps nên thiết lập hệ thống giám sát và cảnh báo hiệu quả để phát hiện và phản ứng nhanh chóng các hoạt động đáng ngờ.
• Thiết lập hoặc áp dụng kế hoạch ứng phó và phục hồi sự cố, chẳng hạn như Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) 800-61r2 hoặc mới hơn.

10. A10:2021 – Giả mạo yêu cầu từ phía máy chủ (Server-Side Request Forgery)

Lỗ hổng SSRF xảy ra bất cứ khi nào một ứng dụng web truy xuất tài nguyên từ xa mà không xác thực URL do người dùng cung cấp. Nó cho phép kẻ tấn công ép buộc ứng dụng gửi một yêu cầu được tạo sẵn đến một đích đến không mong muốn, ngay cả khi được bảo vệ bởi tường lửa, VPN hoặc một loại danh sách kiểm soát truy cập mạng (ACL) khác.

Khi các ứng dụng web hiện đại cung cấp cho người dùng cuối các tính năng tiện lợi, việc truy xuất URL trở nên phổ biến. Do đó, tỷ lệ SSRF ngày càng tăng. Ngoài ra, mức độ nghiêm trọng của SSRF cũng ngày càng cao do các dịch vụ đám mây và kiến ​​trúc phức tạp.

Cách phòng ngừa:

1. Tầng mạng (Network layer)

• Phân đoạn chức năng truy cập tài nguyên từ xa trong các mạng riêng biệt để giảm tác động của SSRF
• Áp dụng chính sách tường lửa “từ chối theo mặc định” hoặc quy tắc kiểm soát truy cập mạng để chặn tất cả lưu lượng mạng nội bộ trừ những lưu lượng cần thiết.

2. Tầng ứng dụng (Application layer)

• Khử trùng và xác thực tất cả dữ liệu đầu vào do khách hàng cung cấp.
• Thực thi lược đồ URL, cổng và đích bằng danh sách cho phép tích cực.
• Không gửi phản hồi thô cho khách hàng.
• Vô hiệu hóa chuyển hướng HTTP.
• Hãy lưu ý đến tính nhất quán của URL để tránh các cuộc tấn công như liên kết lại DNS và tình trạng chạy đua “thời điểm kiểm tra, thời điểm sử dụng” (TOCTOU)

3. Bộ giải pháp bảo mật toàn diện FPT.EagleEye cho doanh nghiệp từ FPT IS

Với năng lực công nghệ và kinh nghiệm triển khai bảo mật cho nhiều tập đoàn hàng đầu, các giải pháp chuyên sâu từ FPT IS đóng vai trò hỗ trợ doanh nghiệp xây dựng một hạ tầng số an toàn, ổn định và thích ứng linh hoạt trước sự biến đổi phức tạp của không gian mạng.

3.1. FPT.EagleEye VA & FPT.EagleEye Pentest – Kiểm thử, đánh giá lỗ hổng bảo mật

Việc đánh giá, kiểm thử lỗ hổng bảo mật giúp doanh nghiệp nhận diện điểm yếu, đánh giá khả năng phòng thủ và chuẩn bị sẵn sàng trước các cuộc tấn công thực tế:

• Penetration Testing (Pentest): Kiểm thử xâm nhập theo chuẩn quốc tế (CREST), giúp doanh nghiệp thấy rõ cách hệ thống có thể bị khai thác.
• Vulnerability Assessment: Dò quét và đánh giá điểm yếu trên ứng dụng, cơ sở dữ liệu, hạ tầng và mạng.
• Red Team Operation: Mô phỏng tấn công thực tế để kiểm tra khả năng phòng thủ.
• Threat Assessment: Xác định các mối nguy đang hoạt động trên mạng, máy chủ và máy trạm.

3.2. FPT.EagleEye mSOC & FPT.EagleEye MDR – Giám sát và xử lý sự cố 24/7

Doanh nghiệp cần giám sát và xử lý sự cố an ninh để phát hiện sớm, giảm thiểu thiệt hại và duy trì vận hành liên tục. Trung tâm an ninh mạng FPT vận hành dựa trên công nghệ hàng đầu (IBM QRadar, Splunk).

Khả năng nổi bật:

• Tự động hóa vận hành (ChatOps), 20.000 luật phát hiện tấn công theo MITRE ATT&CK.
• 0% dữ liệu bị gửi ra ngoài trung tâm dữ liệu.
• Giám sát, phân tích toàn bộ cảnh báo và phát hiện xâm nhập dựa trên hành vi.
• Báo cáo tự động, định kỳ và quản lý điểm yếu bảo mật.
• Điều tra số, phân tích sự cố theo mức độ nghiêm trọng.
• Cập nhật thông tin tình báo từ bên thứ ba, phát hiện sớm và xử lý kịp thời mối nguy.

3.3. FPT.EagleEye malBot – Tự động phát hiện & ngăn chặn thiết bị vi phạm

Bot tự động duy nhất tại Việt Nam có khả năng không chỉ cảnh báo mà còn ngăn chặn ngay lập tức thiết bị vi phạm.

Ưu điểm:

• Tự động hóa quy trình phát hiện – xử lý, rút ngắn thời gian xử lý (tiết kiệm ~60 ngày/năm).
• Ngăn chặn thiết bị vi phạm mà vẫn đảm bảo hệ thống còn lại hoạt động bình thường.
• Thông báo chính xác qua nhiều kênh (email, SMS…).
• Giảm chi phí còn 1/3 so với cách truyền thống, nâng hiệu suất gấp 3 lần.
• Xuất báo cáo định kỳ, hỗ trợ quản trị viên và CISO đưa ra quyết định kịp thời để giảm rủi ro toàn hệ thống.

3.4. Dịch vụ tư vấn và đánh giá chứng chỉ PCI DSS

PCI DSS (Payment Card Industry Data Security Standard – Tiêu chuẩn Bảo mật Dữ liệu Ngành Thẻ Thanh toán) là bộ tiêu chuẩn thiết lập nhằm nâng cao an toàn cho các giao dịch thẻ tín dụng, thẻ ghi nợ và thẻ trả trước, đồng thời bảo vệ thông tin cá nhân của chủ thẻ.

FPT IS là đơn vị QSA (Qualified Security Assessor) được công nhận bởi Hội đồng PCI SSC, đủ điều kiện cung cấp dịch vụ tư vấn và cấp chứng chỉ PCI DSS 4.0 (Level 1) – phiên bản mới nhất với các yêu cầu bảo mật nâng cao, giúp giảm thiểu nguy cơ gian lận trong giao dịch trực tuyến và tại điểm bán.

Dịch vụ tư vấn và tuân thủ FPT.EagleEye PCI DSS gồm:

• Xác định phạm vi và khảo sát hiện trạng.
• Tư vấn khắc phục điểm chưa tuân thủ.
• Đánh giá chứng nhận tuân thủ PCI DSS.
• Báo cáo và Tuyên bố Tuân thủ.

Dịch vụ duy trì và tái đánh giá PCI DSS hàng năm gồm:

• Triển khai chương trình duy trì tuân thủ hàng năm.
• Đánh giá hiện trạng và khả năng đáp ứng duy trì (HealthCheck Assessment).
• Tư vấn khắc phục điểm chưa tuân thủ.
• Tái đánh giá chứng nhận tuân thủ PCI DSS.

Có thể thấy, lỗ hổng bảo mật là vấn đề mang tính hệ thống, bắt nguồn từ nhiều nguyên nhân khác nhau như lỗi thiết kế, sai sót lập trình hay cấu hình chưa phù hợp. Khi không được phát hiện và xử lý kịp thời, chúng có thể trở thành điểm yếu để tin tặc khai thác, gây ra hậu quả nghiêm trọng về dữ liệu, tài chính và uy tín tổ chức.

Việc quét và kiểm tra lỗ hổng bảo mật định kỳ là một trong những biện pháp quan trọng nhằm duy trì mức độ an toàn thông tin bền vững. Ứng dụng công nghệ hiện đại, kết hợp cùng đội ngũ chuyên gia có kinh nghiệm, sẽ giúp doanh nghiệp không chỉ phát hiện sớm các rủi ro tiềm ẩn mà còn triển khai được những giải pháp khắc phục phù hợp, đáp ứng yêu cầu tuân thủ và chuẩn mực quốc tế.

Nếu Quý doanh nghiệp cần tư vấn thêm về các giải pháp AI, vui lòng để lại thông tin liên hệ TẠI ĐÂY, đội ngũ chuyên gia FPT IS sẽ chủ động kết nối trong thời gian sớm nhất.