Khi AI tự viết code bảo mật: Bài học đắt giá về sự nhầm lẫn giữa chức năng và niềm tin

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• AI đã tạo ra các thành phần bảo mật đầy đủ cho một ứng dụng onboarding, nhưng lại mắc sai lầm nghiêm trọng trong logic xác thực.
• GUID (Globally Unique Identifier) bị biến thành một loại 'bearer secret', cho phép bất kỳ ai có GUID đều có thể truy cập dữ liệu cá nhân của người khác.
• Lỗ hổng không nằm ở thiếu sót kỹ thuật mà ở kiến trúc niềm tin (trust boundary) bị thiết lập sai ngay từ đầu.

Trong kỷ nguyên mà việc sử dụng AI để tăng tốc độ phát triển phần mềm trở thành tiêu chuẩn, chúng ta đang đối mặt với một nghịch lý nguy hiểm: code chạy tốt không đồng nghĩa với code an toàn. Một cuộc kiểm thử thâm nhập gần đây tại một công ty dịch vụ tài chính đã chứng minh rằng, dù AI có thể viết ra những đoạn mã tuân thủ mọi tiêu chuẩn bảo mật, nó vẫn có thể bỏ qua những câu hỏi cốt lõi về logic kinh doanh, biến hệ thống thành một 'cánh cửa mở' cho những kẻ tấn công.

Khi các kiểm soát bảo mật trở nên vô nghĩa

Sygnia, một công ty phản ứng sự cố hàng đầu, đã thực hiện đánh giá một ứng dụng onboarding khách hàng được xây dựng chủ yếu bằng Claude. Ứng dụng này xử lý các thông tin nhạy cảm như định danh chính phủ, dữ liệu xác minh danh tính, thông tin thanh toán và số An sinh xã hội. Vấn đề nảy sinh khi hệ thống cần khôi phục tiến trình đăng ký cho người dùng mà không yêu cầu mật khẩu.

Claude đã tạo ra một mô hình truy cập tạm thời, nhưng lỗ hổng nằm ở cách hệ thống quyết định ai xứng đáng nhận token. Thay vì xác thực danh tính, hệ thống chỉ cần người dùng sở hữu GUID (Globally Unique Identifier) của ứng dụng đó. Về bản chất, GUID đã trở thành một loại 'bearer secret' (bí mật mang theo). Nếu bạn có GUID của người khác, bạn có toàn quyền truy cập vào dữ liệu của họ.

Sự khác biệt giữa code chạy được và code an toàn

Điều đáng ngạc nhiên là ứng dụng này không hề thiếu các biện pháp kiểm soát bảo mật. Sygnia ghi nhận rằng hệ thống đã có đầy đủ các thành phần sau:

Lưu ý: Các công cụ quét bảo mật tĩnh (SAST) thường tìm kiếm các mẫu code không an toàn hoặc luồng dữ liệu lỗi. Tuy nhiên, trong trường hợp này, lỗ hổng nằm ở kiến trúc (architectural flaw) và giả định về niềm tin, thứ mà các công cụ tự động hiện nay rất khó phát hiện.

Việc hiểu rõ kiến trúc hệ thống là chìa khóa. Nếu bạn đang xây dựng các hệ thống phức tạp, hãy tham khảo thêm về khi AI Agents thay đổi tư duy về kiến trúc Vertical Slices trong phát triển phần mềm để đảm bảo các ranh giới niềm tin được thiết lập ngay từ khâu thiết kế.

Tại sao AI lại thất bại trong tư duy logic?

Zach Mead, chuyên gia kiểm thử thâm nhập tại Sygnia, nhấn mạnh rằng AI có thể biên dịch, tuân thủ các quy ước quen thuộc và vượt qua các bài kiểm tra cơ bản, nhưng nó lại tạo ra những giả định sai lầm về ranh giới niềm tin (trust boundaries). Đây là lý do tại sao chúng ta không nên quá phụ thuộc vào các công cụ tự động mà thiếu đi sự giám sát của con người.

Nếu bạn đang sử dụng các công cụ hỗ trợ AI, hãy đảm bảo rằng bạn đã có quy trình kiểm soát chặt chẽ. Đừng quên rằng ngừng viết quy tắc cho AI Coding Agents: Tại sao CI mới là trọng tài cuối cùng là một chiến lược cần thiết để giữ cho hệ thống của bạn luôn trong tầm kiểm soát.

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một Tech Lead, tôi nhận thấy đây là một bài học đắt giá về việc sử dụng AI trong phát triển phần mềm:

• Ưu điểm: AI giúp tăng tốc độ viết code, tạo khung (boilerplate) nhanh chóng và hỗ trợ viết tài liệu.
• Nhược điểm: AI thiếu khả năng hiểu ngữ cảnh kinh doanh sâu sắc và các giả định về bảo mật trong các hệ thống phân tán.
• Phạm vi ứng dụng: Chỉ nên sử dụng AI cho các tác vụ lặp đi lặp lại, code logic thuần túy hoặc các phần không liên quan đến bảo mật nhạy cảm.
• Lưu ý cho Production: Luôn coi code do AI tạo ra là code 'không đáng tin cậy'. Mọi PR (Pull Request) có sự tham gia của AI cần được gắn nhãn và kiểm tra kỹ lưỡng bởi con người, đặc biệt là các phần liên quan đến xác thực (authentication) và dữ liệu người dùng.

Để tránh những sai lầm tương tự, bạn nên tìm hiểu thêm về cách quản lý quy trình phát triển hiện đại tại chuyển đổi từ Monorepo sang Multi-repo: Bài học từ thực tế phát triển phần mềm để tối ưu hóa việc kiểm soát mã nguồn.

Câu hỏi thường gặp (FAQ)

Tại sao các công cụ quét bảo mật không phát hiện ra lỗi này?

Các công cụ quét bảo mật tĩnh (SAST) thường tập trung vào các mẫu code lỗi (vulnerable patterns). Lỗi này nằm ở logic kinh doanh và kiến trúc, nơi mà code trông có vẻ 'sạch' và hợp lệ theo cú pháp, nên các công cụ này không thể nhận diện được sai lầm về mặt ngữ nghĩa.

Làm thế nào để viết prompt an toàn hơn cho AI?

Thay vì chỉ yêu cầu chức năng, hãy yêu cầu AI xác định rõ các ranh giới niềm tin. Ví dụ: 'Hãy tạo logic cấp token, trong đó token chỉ được cấp sau khi xác thực danh tính qua số điện thoại, không được dựa trên GUID'.

Có nên cấm hoàn toàn việc sử dụng AI trong coding?

Không. Cấm đoán chỉ khiến lập trình viên sử dụng AI qua tài khoản cá nhân, nơi không ai kiểm soát được. Thay vào đó, hãy thiết lập quy trình kiểm duyệt (code review) nghiêm ngặt cho mọi đoạn code do AI tạo ra.

Kết luận

Sự cố tại Sygnia là một lời nhắc nhở mạnh mẽ rằng AI là một công cụ hỗ trợ, không phải là một kỹ sư thay thế. Việc hiểu rõ kiến trúc và các giả định bảo mật vẫn là trách nhiệm của con người. Hãy tiếp tục cập nhật các kiến thức về bảo mật và quy trình phát triển tại hi_dev để không bị bỏ lại phía sau trong kỷ nguyên AI. Nếu bạn có kinh nghiệm về việc kiểm soát code do AI tạo ra, hãy để lại bình luận phía dưới để chúng ta cùng thảo luận sâu hơn.