Cách xóa "Mã ẩn" khỏi ChatGPT và các LLM khác

Khi các mô hình ngôn ngữ lớn (LLM) ngày càng tạo ra mã làm việc và được tích hợp vào các đường ống phát triển và ngăn xếp tác nhân, thì có nguy cơ ngày càng tăng rằng ẩn or độc hại hướng dẫn — cho dù được nhúng trong đầu ra của mô hình, được đưa vào thông qua trang web hoặc plugin của bên thứ ba hoặc được đưa vào trong quá trình đào tạo mô hình — đều có thể gây ra hành vi không an toàn khi mã đó được thực thi.

Theo báo cáo của người dùng lưu hành trong cộng đồng nhà phát triển, một nhà phát triển phần mềm đã gặp phải tình trạng mất dữ liệu thảm khốc — khoảng 800GB tệp đã bị xóa, Bao gồm cả toàn bộ ứng dụng CursorAI — sau khi thực thi mã được tạo ra với sự hỗ trợ từ Gemini 3 trong khi làm việc bên trong IDE CursorAI. Khi các nhà phát triển ngày càng dựa vào LLM để tạo mã, hậu quả của các tập lệnh chưa được xem xét hoặc không an toàn sẽ ngày càng nghiêm trọng hơn.

Do đó, việc biết cách phát hiện và loại bỏ các mã nguy hiểm do LLM tạo ra là rất quan trọng.

“Mã ẩn” trong bối cảnh của ChatGPT và LLM là gì?

Mọi người có ý gì khi nói đến “mã ẩn”?

“Mã ẩn” là thuật ngữ chung mà các nhà phát triển sử dụng để mô tả bất kỳ hướng dẫn nhúng hoặc nội dung thực thi nào trong văn bản (hoặc tệp) mà LLM thu thập hoặc phát ra, bao gồm:

Hướng dẫn theo kiểu nhắc nhở được nhúng bên trong nội dung của người dùng (ví dụ: “Bỏ qua hướng dẫn trước đó…” ẩn trong tệp PDF).
Nhân vật vô hình hoặc khoảng trắng có độ rộng bằng không được sử dụng để ẩn mã thông báo hoặc phá vỡ các giả định về mã thông báo.
Tải trọng được mã hóa (base64, mã hóa URL, nhúng ẩn chữ bên trong hình ảnh hoặc tài liệu).
HTML/JS ẩn hoặc các khối tập lệnh được bao gồm trong nội dung được định dạng có thể được trình kết xuất hạ lưu diễn giải.
Siêu dữ liệu hoặc chú thích (bình luận tệp, lớp ẩn trong PDF) hướng dẫn hệ thống truy xuất hoặc mô hình.
Hành vi ngầm phát sinh từ mã được tạo ra sử dụng API nguy hiểm (ví dụ: eval, exec, subprocesshoặc các cuộc gọi mạng/hệ thống) — ngay cả khi mục đích không rõ ràng là độc hại.
Hướng dẫn được tiêm nhanh khiến mô hình tạo ra mã bao gồm các lệnh ẩn hoặc logic giống như cửa hậu vì kẻ tấn công đã thiết kế lời nhắc hoặc ngữ cảnh.

Các vectơ tấn công này thường được gọi là tiêm nhanh chóng or tiêm gián tiếp khi mục tiêu là thay đổi hành vi của mô hình. Cộng đồng bảo mật hiện coi "chập chờn" là lỗ hổng cốt lõi của LLM và OWASP đã chính thức hóa nó thành một danh mục rủi ro LLM.

Điều này khác với phần mềm độc hại thông thường hoặc XSS như thế nào?

Sự khác biệt là ngữ nghĩa layer: tấn công prompt injection nhắm vào hành vi tuân theo lệnh của mô hình thay vì hệ điều hành máy chủ hoặc công cụ kết xuất trình duyệt. Tuy nhiên, mã HTML hoặc tập lệnh ẩn chạy trong trình kết xuất web vẫn là một cuộc tấn công thực thi (giống như XSS); cả lớp ngữ nghĩa và lớp thực thi đều cần được bảo vệ. Các nhà lãnh đạo và nhà nghiên cứu trong ngành đã gọi prompt injection là một "thách thức an ninh biên giới" và tiếp tục công bố các chiến lược giảm thiểu.

Tại sao LLM có thể tạo ra mã ẩn hoặc mã nguy hiểm?

Mô hình hành vi, dữ liệu đào tạo và bối cảnh hướng dẫn

LLM được đào tạo để tạo ra những đoạn mã tiếp nối hợp lý dựa trên ngữ cảnh và hướng dẫn. Nếu ngữ cảnh chứa các tín hiệu đối nghịch, hoặc nếu người dùng yêu cầu mô hình mã thực hiện các hành động mạnh mẽ, mô hình có thể xuất ra mã bao gồm hành vi tinh vi hoặc chủ động.

LLM tạo ra mã hợp lý nhưng không an toàn

Các chương trình LLM được tối ưu hóa về tính lưu loát và tính hữu ích, chứ không phải về tính an toàn khi có các tác dụng phụ gây hại. Họ sẽ vui vẻ tạo ra một bài giảng ngắn gọn. rm -rf /path/to/dir or shutil.rmtree() gọi khi được yêu cầu "dọn dẹp" — và vì câu trả lời của họ thường được diễn đạt một cách tự tin, người dùng có thể sao chép và bỏ qua mà không được kiểm tra kỹ lưỡng. Vấn đề "ảo giác tự tin" này là lý do tại sao những yêu cầu tưởng chừng như vô hại lại trở nên nguy hiểm.

Tự động hóa quy trình làm tối nghĩa

Các tác nhân đe dọa hiện đang tự động hóa việc che giấu mã bằng cách kết nối các lệnh gọi LLM: một mô hình tạo ra một payload, một mô hình khác sửa đổi nó để tránh bị phát hiện chữ ký, v.v. Các báo cáo về mối đe dọa trong ngành và phân tích của nhà cung cấp vào năm 2025 ghi nhận "việc che giấu được hỗ trợ bởi AI" này là một kỹ thuật mới nổi.

Làm thế nào để phát hiện mã ẩn bên trong đầu ra của mô hình?

Danh sách kiểm tra phân loại nhanh

Quét Unicode vô hình/bất thường (các ký tự nối có độ rộng bằng không, các khoảng cách có độ rộng bằng không, các dấu thứ tự byte, các ký tự đồng âm không phải ASCII).
Chạy phân tích tĩnh / phân tích cú pháp AST để xác định việc sử dụng các API mạnh mẽ (eval, exec, subprocess, os.system, các cuộc gọi phản chiếu).
Tìm kiếm các tải trọng được mã hóa (base64, blob hex, chuỗi dài lặp lại hoặc nội dung nén).
Kiểm tra các mẫu che giấu (chuỗi nối tạo nên tên API, số học ký tự, chr() chuỗi).
Sử dụng phân tích ngữ nghĩa để xác nhận xem mã có thực sự thực hiện I/O, mạng hoặc đột biến hệ thống tệp hay không.

Phát hiện mẫu tĩnh (nhanh, dòng đầu tiên)

Phân tích cú pháp và kiểm tra lỗi theo ngôn ngữ. Phân tích cú pháp đầu ra được tạo thành các khối mã thay vì văn xuôi ngay lập tức. Chạy các trình định dạng và kiểm tra lỗi (Black/Prettier, pylint, eslint). Các quy tắc kiểm tra lỗi nên đánh dấu việc sử dụng eval, exec, rm -rf, các lệnh gọi tiến trình con thô hoặc các đường ống shell xây dựng các lệnh một cách động.
Máy quét mã thông báo và mẫu chuỗi. Tìm kiếm các mã thông báo và mẫu có rủi ro cao: sudo, đường dẫn tuyệt đối như /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, các khối base64 nội tuyến, các chuỗi dài không thể diễn giải và các lệnh chuyển đổi ngữ cảnh trình thông dịch.
Quét bí mật và kiểm tra nguồn gốc. Phát hiện thông tin xác thực được mã hóa cứng, URL trỏ đến các sổ đăng ký không đáng tin cậy hoặc mã tự động kéo các gói từ các nguồn tùy ý.

Phân tích tĩnh phát hiện nhanh chóng nhiều vấn đề rõ ràng và tiết kiệm chi phí khi chạy như một phần của cổng CI.

Phát hiện ngữ nghĩa và ngữ cảnh (sâu hơn)

Phân tích ý định. Sử dụng một mô hình thứ cấp hoặc một công cụ quy tắc để phân loại mục đích của mã được tạo ra: đó là "đọc", "ghi", "xóa", "mạng", "cài đặt"? Bất kỳ mục đích nào được phân loại là xóa/ghi đều sẽ kích hoạt leo thang.
Phân tích luồng dữ liệu. Phân tích mã để phát hiện xem các đường dẫn chưa được xác thực hoặc do người dùng cung cấp có thể gây hại cho các API hay không. Ví dụ: nếu một biến được lấy từ đầu ra LLM hoặc tệp từ xa sau đó được nối vào lệnh shell, hãy đánh dấu nó.
Sự tương quan về nguồn gốc. Lưu giữ toàn bộ bản ghi cuộc trò chuyện, lời nhắc hệ thống và các trang ngữ cảnh. Nếu kết quả đầu ra đáng ngờ tương quan với một tài liệu bên ngoài hoặc lệnh gọi plugin cụ thể, điều đó có thể cho thấy dấu hiệu bị chèn lời nhắc hoặc ngữ cảnh bị nhiễm độc.

Phát hiện động và hành vi (đáng tin cậy nhất)

Thực hiện thử nghiệm với giám sát. Thực thi mã được tạo trong môi trường tạm thời được giới hạn chặt chẽ, không có mạng, không có máy chủ gắn kết và lọc syscall (seccomp). Giám sát hoạt động của hệ thống tệp, các cuộc gọi mạng đã thử, quá trình sinh ra và I/O bất thường.
Kiểm tra Canary. Trước khi chạy trên dữ liệu thực, hãy chạy mã trên các thư mục tổng hợp có chứa các tệp tin canh gác; theo dõi xem có xóa hoặc ghi đè không.
Phương pháp tìm kiếm hành vi. Tìm kiếm các vòng lặp đi qua các thư mục cha, các thao tác đệ quy không kiểm tra độ sâu hoặc các mẫu đổi tên có thể gây hại cho nhiều tệp (ví dụ: ghi nhiều lần cùng một tên tệp).
Phân tích động là cách duy nhất để phát hiện các tải trọng bị che giấu, trì hoãn hoặc chỉ được kích hoạt khi chạy.

Bạn nên xóa hoặc vô hiệu hóa mã ẩn như thế nào trước khi thực thi đầu ra LLM?

Loại bỏ phòng thủ so với thay đổi ngữ nghĩa

Có hai mục tiêu khi “xóa mã ẩn”:

Vệ sinh — xóa nội dung rõ ràng không phải mã hoặc đáng ngờ (Unicode ẩn, ký tự có độ rộng bằng 0, dữ liệu base64 được thêm vào). Điều này sẽ không làm thay đổi logic lành tính đã định.
Trung hòa — đối với bất kỳ thứ gì thực thi hoặc gọi các dịch vụ bên ngoài, hãy vô hiệu hóa các cuộc gọi đó hoặc biến chúng thành no-op cho đến khi được xác minh.

Luôn luôn thích trung hòa + xem xét lại Thay vì xóa ẩn: việc xóa các phần mã một cách tùy tiện có thể gây ra lỗi hoặc hành vi không mong muốn. Thay vào đó, hãy thay thế các cấu trúc đáng ngờ bằng các stub rõ ràng, đã được ghi lại và có thể lỗi an toàn (nêu ngoại lệ hoặc trả về giá trị mặc định an toàn).

Bước 1 — Xử lý mã được tạo ra như dữ liệu không đáng tin cậy

Không bao giờ thực thi mã trực tiếp từ ChatGPT (hoặc bất kỳ LLM nào) mà không thông qua quy trình gỡ bỏ và củng cố. Quy trình đó cần được thực thi theo chính sách và tự động hóa trong CI/CD.

Bước 2 — Trích xuất và chuẩn hóa mã

Chuẩn hóa văn bản và xóa các ký tự có độ rộng bằng không: Loại bỏ các ký tự như U+200B, U+200C, U+200D, U+FEFF và các điểm mã định dạng/độ rộng bằng không khác. Ghi lại những gì đã bị xóa để kiểm tra. Bước này loại bỏ nhiều mã hóa "ẩn" được sử dụng để tàng hình trực quan.
Loại bỏ tất cả ngữ cảnh không phải mã: xóa phần tường thuật, bình luận ẩn và bất kỳ phần đóng gói HTML/Markdown nào. Chuyển đổi mã sang dạng chuẩn bằng các trình định dạng ngôn ngữ (Black, Prettier) để các khoảng trắng hoặc ký tự điều khiển bị che khuất được chuẩn hóa.
Từ chối hoặc cách ly mã với các cấu trúc này: năng động eval, các cuộc gọi quy trình con thô (os.system, subprocess.Popen), các blob base64 nội tuyến được giải mã thành lệnh thực thi hoặc nhúng #! các chỉ thị cố gắng thay đổi ngữ cảnh của trình thông dịch. Chuẩn hóa văn bản và xóa các ký tự có độ rộng bằng không
Loại bỏ các ký tự như U+200B, U+200C, U+200D, U+FEFF và các điểm mã định dạng/độ rộng bằng không khác. Ghi lại những gì đã bị xóa để kiểm tra. Bước này loại bỏ nhiều mã hóa "ẩn" được sử dụng để tàng hình trực quan.

Bước 3 — Phân tích thành AST và thay thế các nút rủi ro

Với mã được phân tích thành AST, hãy tìm các nút gọi thực thi động (ví dụ: exec), hoặc xây dựng tên hàm theo chương trình. Thay thế chúng bằng các stub an toàn, tạo ra ngoại lệ được kiểm soát, cho biết "hành vi động không an toàn đã bị chặn". Tạo một bản sao đã được khử trùng của mã nguồn được AST hỗ trợ để xem xét. Chạy kiểm tra mẫu bảo mật (quy tắc semgrep tùy chỉnh cho môi trường của bạn). Khi tìm thấy kết quả trùng khớp, hãy đánh dấu và vô hiệu hóa chúng.

Bước 4 — Làm cứng tĩnh và viết lại

Viết lại tự động: truyền mã qua bộ khử trùng tự động thay thế các lệnh gọi nguy hiểm bằng các trình bao bọc an toàn — ví dụ: thay thế os.system() / subprocess với trình thực thi hộp cát được phê duyệt có chức năng thực thi thời gian chờ và chặn mạng.
Cổng năng lực: sửa đổi hoặc xóa khóa API, mã thông báo hoặc lệnh gọi đến các điểm cuối đặc quyền; thay thế chúng bằng bộ điều hợp giả để thử nghiệm cục bộ. Ngăn chặn việc vô tình đưa vào các bí mật hoặc URL.
Viết lại sự phụ thuộc: khối động pip / npm cài đặt được tạo bởi mã. Yêu cầu các phụ thuộc phải được khai báo và phê duyệt thông qua sổ đăng ký của bạn.

Bước 5 — Chạy bên trong hộp cát hung hãn

Container tạm thời / microVM: thực thi mã trong một container/VM không có mạng, không có quyền truy cập vào thông tin đăng nhập máy chủ và quyền truy cập hệ thống tệp bị hạn chế. Các công nghệ như gVisor, Firecracker hoặc các dịch vụ thực thi tạm thời chuyên dụng là phù hợp. Nếu mã phải truy cập I/O, hãy sử dụng proxy để thực thi chính sách.
Bộ lọc gọi hệ thống & seccomp: giới hạn số lệnh gọi hệ thống được phép. Việc ghi tệp bên ngoài thư mục tạm thời phải bị chặn.
Giới hạn tài nguyên/thời gian: thiết lập giới hạn CPU/bộ nhớ/thời gian để ngay cả bom logic cũng không thể chạy vô thời hạn.

Việc thực thi sandbox cộng với giám sát thường phát hiện ra các payload mà kiểm tra tĩnh bỏ sót. Hướng dẫn của ngành và các báo cáo gần đây khuyến nghị sử dụng sandbox như một biện pháp giảm thiểu cốt lõi.

Những công cụ và quy tắc tự động nào nên có trong quy trình của bạn?

Các thành phần chuỗi công cụ được đề xuất

Mô-đun vệ sinh Unicode (thư viện tùy chỉnh hoặc thư viện hiện có). Phải ghi lại các ký tự đã chuẩn hóa.
Bộ phân tích cú pháp + AST cho mỗi ngôn ngữ đích (Python ast, typed-ast, trình phân tích cú pháp JavaScript, trình phân tích cú pháp Java).
Máy phân tích tĩnh / SAST: Bandit (Python), Semgrep (nhiều ngôn ngữ, có thể tùy chỉnh), ESLint với các plugin bảo mật.
Entropy và thuật toán giải mã: phát hiện base64/hex/gzip và định tuyến để kiểm tra.
Thời gian chạy hộp cát: container tối thiểu với cấu hình seccomp/AppArmor nghiêm ngặt hoặc trình thông dịch cấp ngôn ngữ với các lệnh gọi hệ thống bị vô hiệu hóa.
Người thực thi chính sách: một thành phần quyết định các mô-đun được phép, các điểm cuối được phép và các trình bao bọc API an toàn.
Đường mòn kiểm toán: nhật ký không thay đổi ghi lại đầu ra ban đầu, đầu ra đã được khử trùng, sự khác biệt và các quyết định.

Ví dụ về các mẫu semgrep (khái niệm)

Sử dụng các quy tắc ngắn gọn, thận trọng để đánh dấu việc sử dụng các hàm nguy hiểm. Ví dụ:

Flag eval, exec, Function hàm tạo (JS), hàm nhập động hoặc tên API được xây dựng theo chuỗi.
Đánh dấu các cuộc gọi mạng nằm ngoài danh sách cho phép (ví dụ: requests.get đến các máy chủ không xác định).
Cờ ghi vào các đường dẫn nhạy cảm (/etc, thư mục hệ thống) hoặc tạo ra các tiến trình.

(Giữ những mục này như các mục cấu hình cho mỗi tổ chức và thắt chặt chúng theo thời gian.)

Đoạn trích khử trùng thực tế là gì (ví dụ an toàn)?

Dưới đây là những ví dụ phòng thủ không nguy hiểm mà bạn có thể áp dụng. Chúng là vệ sinh và phát hiện đoạn trích — không phải hướng dẫn khai thác.

Ví dụ: xóa các ký tự có độ rộng bằng không (Python, phòng thủ)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

Thao tác này sẽ xóa các ký tự mà kẻ tấn công thường sử dụng để ẩn mã trong văn bản dễ nhìn thấy. Luôn ghi lại những gì đã bị xóa và coi việc xóa này là một phần của quá trình kiểm tra.

Ví dụ: phân tích và kiểm tra AST (Python, khái niệm)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec trả về True, không chạy mã; thay vào đó hãy thay thế nút động bằng một đoạn mã stub an toàn và yêu cầu xem xét.

Lưu ý: những ví dụ này mang tính chất phòng thủ. Không xóa nhật ký, kiểm tra hoặc đánh giá thủ công khỏi quy trình của bạn.

Suy nghĩ kết thúc: hãy luôn coi đầu ra của LLM như mã không đáng tin cậy

LM là những công cụ năng suất mạnh mẽ — chúng có thể tạo ra mã nguồn tinh tế, đẩy nhanh quá trình soạn thảo và tự động hóa các công việc thường lệ. Nhưng khi chúng được triển khai, các quy tắc bảo mật sẽ thay đổi: đầu ra của mô hình phải được coi là hiện vật không đáng tin cậySự kết hợp giữa việc tiêm thuốc kịp thời, nghiên cứu cửa sau và tiết lộ lỗ hổng bảo mật thực tế trong 18–30 tháng qua cho thấy một điểm rõ ràng: bề mặt rủi ro đã phát triển và sẽ tiếp tục phát triển.

Các biện pháp phòng thủ thực tế kết hợp phân tích cú pháp, phân tích tĩnh, kiểm thử động trong môi trường sandbox, quản trị và nhóm đỏ liên tục sẽ ngăn chặn hầu hết các cuộc tấn công. Tuy nhiên, các nhóm cũng phải đầu tư vào các biện pháp kiểm soát tổ chức: đặc quyền tối thiểu, nguồn gốc và văn hóa coi đầu ra LLM cần được xác minh. Ngành công nghiệp đang xây dựng các công cụ và khuôn khổ để giúp các mô hình này dễ dàng hơn; đồng thời, việc áp dụng danh sách kiểm tra ở trên sẽ giảm thiểu khả năng một tải trọng ẩn bị lọt ra ngoài.

Các nhà phát triển có thể truy cập API LLM mới nhất như Claude Sonnet 4.5 API và Xem trước Gemini 3 Pro v.v. thông qua CometAPI, phiên bản mẫu mới nhất luôn được cập nhật trên trang web chính thức. Để bắt đầu, hãy khám phá các khả năng của mô hình trong Sân chơi và tham khảo ý kiến Hướng dẫn API để biết hướng dẫn chi tiết. Trước khi truy cập, vui lòng đảm bảo bạn đã đăng nhập vào CometAPI và lấy được khóa API. Sao chổiAPI cung cấp mức giá thấp hơn nhiều so với giá chính thức để giúp bạn tích hợp.

Sẵn sàng chưa?→ Đăng ký CometAPI ngay hôm nay !

Nếu bạn muốn biết thêm mẹo, hướng dẫn và tin tức về AI, hãy theo dõi chúng tôi trên VK, X và Discord!