Mã do trợ lý AI viết hay mắc cùng một nhóm lỗi bảo mật: ghép thẳng dữ liệu người dùng vào câu SQL hay lệnh hệ thống, tin đầu vào mà không kiểm, viết cứng khoá bí mật, bỏ quên bước kiểm quyền, nhận tệp tải lên không giới hạn, in lỗi chi tiết ra ngoài, dùng cấu hình mặc định lỏng và kéo về thư viện cũ. Những lỗi này không do AI “cố ý” mà do nó viết thứ chạy được nhanh nhất cho đúng câu bạn hỏi; bảo mật thường không nằm trong câu hỏi.
Bài này cho bạn một bảng tám lỗi kèm dấu hiệu nhận ra ngay khi đọc, cách sửa theo nguyên lý, và một danh sách soi nhanh để dùng mỗi lần rà yêu cầu gộp mã có phần do AI viết. Mọi ví dụ là ví dụ giả định, viết ở mức phòng thủ: nhận ra và vá, không bàn cách khai thác.
Vì sao mã AI viết hay hở cùng một kiểu
Trợ lý viết mã học từ một lượng rất lớn mã công khai. Trong đó có mã tốt, nhưng cũng có rất nhiều bài hướng dẫn cũ, đoạn trả lời diễn đàn viết vội và dự án thử nghiệm không ai định đưa lên thật. Kiểu viết ngắn nhất, dễ hiểu nhất thường là kiểu bỏ qua kiểm tra: lấy giá trị từ biểu mẫu rồi đưa thẳng vào câu truy vấn, để khoá ngay trong tệp cho chạy được luôn. Khi bạn hỏi “viết giúp hàm đăng nhập”, mô hình trả về thứ giống đáp án phổ biến nhất mà nó từng thấy, và đáp án phổ biến không đồng nghĩa với đáp án an toàn.
Lý do thứ hai nằm ở phạm vi câu hỏi. Bạn yêu cầu một hàm, AI chỉ nhìn thấy hàm đó. Nó không biết ứng dụng của bạn có lớp kiểm quyền chung hay không, dữ liệu đi qua những đâu, ai được gọi đường dẫn này. Thiếu bức tranh, nó hoặc bỏ qua bảo mật, hoặc tự chế một lớp bảo vệ riêng không khớp với phần còn lại của hệ thống.
Lý do thứ ba là người đọc. Mã AI viết trông gọn gàng, đặt tên đẹp, có chú thích, nên người rà dễ thả lỏng. Một đoạn mã lộn xộn khiến ta nghi ngờ; một đoạn mã sạch sẽ khiến ta tin. Lỗi bảo mật lại thường nằm ở thứ không có trong mã, như một dòng kiểm quyền bị thiếu, nên đọc lướt rất khó thấy. Vì vậy cách rà hiệu quả là đi theo danh sách những thứ phải có, chứ không chỉ tìm thứ sai.
Tám lỗi hay gặp và dấu hiệu nhận ra khi đọc mã
Bảng dưới xếp theo mức hay gặp trong mã web và công cụ nội bộ. Cột dấu hiệu là thứ bạn nhìn thấy được ngay trên màn hình rà mã, không cần chạy.
| Lỗi | Dấu hiệu khi đọc | Hướng sửa |
|---|---|---|
| 1. Ghép chuỗi vào truy vấn | Câu SQL được nối bằng dấu cộng hay chuỗi định dạng có biến lấy từ yêu cầu | Truy vấn tham số hoá, không bao giờ nối chuỗi |
| 2. Ghép chuỗi vào lệnh hệ thống | Gọi trình chạy lệnh với chuỗi có tên tệp hay giá trị người dùng gửi lên | Truyền đối số dạng danh sách, không qua trình thông dịch lệnh; kiểm giá trị theo danh sách cho phép |
| 3. Tin đầu vào | Đọc tham số rồi dùng ngay, không kiểm kiểu, độ dài, khoảng giá trị | Kiểm ở phía máy chủ theo danh sách cho phép, từ chối thứ không khớp |
| 4. Xuất ra HTML không mã hoá | Chèn biến vào trang bằng cách nối chuỗi hoặc gán thẳng vào nội dung HTML của phần tử | Mã hoá đầu ra theo ngữ cảnh, dùng cơ chế tự mã hoá của khuôn mẫu |
| 5. Khoá viết cứng | Chuỗi dài trông như khoá, mật khẩu cơ sở dữ liệu nằm ngay trong tệp mã | Đọc từ biến môi trường hoặc kho bí mật, thêm quét bí mật trước khi đẩy |
| 6. Thiếu kiểm quyền | Đường dẫn sửa hoặc xoá chỉ kiểm đã đăng nhập, không kiểm bản ghi có thuộc người đó | Kiểm quyền trên từng bản ghi, lọc theo chủ sở hữu ngay trong truy vấn |
| 7. Tải tệp lên lỏng | Lưu tệp theo tên người gửi, không giới hạn loại và dung lượng, lưu trong thư mục chạy được mã | Đặt tên mới, kiểm loại theo nội dung, giới hạn dung lượng, lưu ngoài thư mục web |
| 8. Lộ thông tin qua lỗi và cấu hình | Bật chế độ gỡ lỗi, in nguyên ngăn xếp lời gọi cho người dùng, cho phép mọi nguồn gọi API | Tắt gỡ lỗi khi chạy thật, ghi lỗi vào nhật ký, giới hạn nguồn được gọi |
Ngoài tám lỗi trên còn một nhóm ít thấy hơn nhưng nặng: dùng hàm băm nhanh để lưu mật khẩu thay vì hàm băm chuyên cho mật khẩu, sinh mã xác nhận bằng hàm ngẫu nhiên thường thay vì nguồn ngẫu nhiên an toàn, so sánh mã bí mật bằng phép so sánh chuỗi thông thường. Nếu dự án có phần đăng nhập, đặt lại mật khẩu hay mã một lần, hãy soi riêng ba chỗ này.
Lỗi thứ nhất, thứ ba, thứ tư, thứ năm và phần tải tệp lên có bài riêng đi sâu trong danh mục này. Ở đây chỉ dừng ở mức nhận ra và biết hướng sửa.
Bốn lỗi khó thấy nhất vì chúng là chỗ thiếu
Thiếu kiểm quyền trên bản ghi. Ví dụ giả định: AI viết đường dẫn xoá đơn hàng nhận mã đơn từ tham số, kiểm người dùng đã đăng nhập rồi xoá. Mã chạy đúng trong mọi lần thử của bạn, vì bạn chỉ xoá đơn của chính mình. Nhưng bất kỳ ai đã đăng nhập đều có thể đổi con số trong tham số để xoá đơn người khác. Cách soi: với mỗi thao tác đọc, sửa, xoá, hỏi “mã này kiểm bản ghi thuộc ai ở dòng nào?”. Không chỉ ra được dòng đó là thiếu.
Thiếu giới hạn số lần. Biểu mẫu đăng nhập, gửi mã xác nhận, quên mật khẩu do AI viết hầu như không có giới hạn số lần thử. Đây không phải lỗi cú pháp nên không bộ kiểm thử thông thường nào bắt được. Bạn cần hỏi thẳng: đường dẫn này bị gọi một nghìn lần trong một phút thì chuyện gì xảy ra?
Thiếu chống giả mạo yêu cầu. Ứng dụng web dùng phiên đăng nhập bằng cookie cần mã chống giả mạo yêu cầu cho các thao tác thay đổi dữ liệu. Nhiều khuôn khổ có sẵn cơ chế này nhưng AI hay viết biểu mẫu mới mà quên gắn mã, hoặc tắt luôn cơ chế khi gặp lỗi “mã không hợp lệ” lúc thử.
Thiếu ghi nhật ký cho thao tác nhạy cảm. Đổi mật khẩu, đổi quyền, xuất dữ liệu, xoá hàng loạt nên để lại dấu vết ai làm, lúc nào. AI ít khi tự thêm. Khi có sự cố, không có nhật ký nghĩa là không biết bắt đầu điều tra từ đâu.
Soi nhanh một yêu cầu gộp mã có phần do AI viết
Quy trình dưới mất khoảng mười lăm phút cho một thay đổi cỡ vừa. Không thay được người rà có kinh nghiệm bảo mật, nhưng chặn được phần lớn lỗi phổ biến.
- Liệt kê mọi chỗ dữ liệu từ bên ngoài đi vào: tham số đường dẫn, nội dung biểu mẫu, phần đầu yêu cầu, tệp tải lên, dữ liệu từ dịch vụ khác. Đánh dấu từng chỗ trên bản thay đổi.
- Với mỗi chỗ đó, lần theo xem nó đi đâu: vào câu truy vấn, vào lệnh hệ thống, vào trang HTML, vào đường dẫn tệp. Mỗi điểm đến cần một cách xử lý riêng như bảng ở trên.
- Tìm trong bản thay đổi các chuỗi dài bất thường, tên biến chứa “key”, “secret”, “password”, “token”. Thấy giá trị thật nằm ngay đó là dừng lại.
- Với mỗi đường dẫn mới, viết ra một câu ai được gọi nó, rồi tìm dòng mã thực thi đúng câu đó.
- Xem tệp khai báo phụ thuộc có thêm gói mới không. Có thì kiểm gói đó tồn tại, được duy trì, đúng tên như bài riêng về gói thư viện trong danh mục này hướng dẫn.
- Chạy công cụ quét tĩnh và quét bí mật của dự án nếu có. Kết quả của công cụ là điểm khởi đầu để đọc, không phải giấy chứng nhận sạch.
- Ghi lại những gì đã soi vào phần mô tả yêu cầu gộp, để người rà sau biết phần nào đã được xem.
Nếu nhóm bạn có tệp hướng dẫn dự án cho AI, thêm vào đó vài dòng quy ước bảo mật: luôn dùng truy vấn tham số, không viết khoá vào mã, mọi đường dẫn sửa xoá phải kiểm chủ sở hữu. Trợ lý đọc tệp này ở đầu mỗi phiên nên sẽ ít mắc lại, dù vẫn cần rà.
Nhờ chính AI rà bảo mật: được việc đến đâu
Bạn có thể dán đoạn mã đã viết vào một phiên trò chuyện mới và yêu cầu rà bảo mật. Câu lệnh mẫu: “Rà đoạn mã sau dưới góc bảo mật phòng thủ. Liệt kê từng chỗ dữ liệu từ ngoài đi vào, nó đi đến đâu, và có được kiểm, mã hoá, tham số hoá chưa. Chỉ ra dòng thiếu kiểm quyền. Không viết lại cả đoạn, chỉ nêu vấn đề kèm số dòng và mức nghiêm trọng.” Yêu cầu nêu số dòng giúp bạn kiểm được từng ý thay vì đọc một đoạn văn chung chung.
Cách này bắt được khá nhiều lỗi dạng mẫu như ghép chuỗi SQL hay xuất HTML không mã hoá. Nó yếu ở lỗi phụ thuộc bối cảnh: AI không biết đường dẫn này đã có lớp kiểm quyền chung bọc ngoài hay chưa, nên có khi báo động giả, có khi bỏ sót. Nó cũng có xu hướng liệt kê thêm những đề nghị chung chung để danh sách trông đầy đủ.
Hai điều nên giữ. Một, dùng phiên mới, đừng nhờ đúng phiên vừa viết mã tự rà mình, vì nó dễ bảo vệ cách làm đã chọn. Hai, trước khi dán, thay khoá thật, địa chỉ máy chủ nội bộ, tên khách hàng trong dữ liệu mẫu bằng giá trị giả. Rà bảo mật mà lại làm lộ bí mật thì được một mất mười.
Những thói quen giảm lỗi ngay từ lúc giao việc
Rà sau khi viết là cần, nhưng nói rõ yêu cầu bảo mật ngay trong câu giao việc giúp bản đầu tiên đã tốt hơn nhiều.
- Nêu rõ dữ liệu nào là của người dùng gửi lên và phải coi là không tin cậy.
- Yêu cầu dùng truy vấn tham số và cơ chế tự mã hoá đầu ra của khuôn khổ dự án đang dùng, nêu tên khuôn khổ để AI không tự chế.
- Nói trước quy tắc phân quyền: ai được xem, ai được sửa, bản ghi thuộc về ai.
- Cấm viết khoá vào mã: “mọi giá trị bí mật đọc từ biến môi trường, đặt tên biến theo quy ước của dự án”.
- Yêu cầu AI liệt kê ở cuối câu trả lời những giả định bảo mật nó đã đặt ra, để bạn kiểm từng giả định.
- Với tính năng nhạy cảm như đăng nhập, thanh toán, phân quyền, dùng thư viện đã được kiểm chứng của khuôn khổ thay vì để AI viết từ đầu.
Một câu yêu cầu thêm vài dòng ràng buộc tốn chưa tới một phút, trong khi tìm và vá lỗ hổng sau khi đã đưa lên máy chủ tốn hàng ngày, chưa kể dữ liệu đã lộ thì không thu hồi được.
Danh mục tham chiếu và giới hạn của bài này
Nếu muốn hệ thống hoá hơn, cộng đồng bảo mật ứng dụng web có các danh mục rủi ro phổ biến được cập nhật định kỳ, nổi tiếng nhất là danh sách mười rủi ro hàng đầu của dự án OWASP và các bộ hướng dẫn kiểm tra đi kèm. Tám lỗi trong bài này phần lớn nằm trong những nhóm rủi ro đó. Đọc bản hiện hành của danh sách ấy một lần giúp bạn có từ vựng chung khi trao đổi với người rà hay đội an ninh.
Bài này không thay thế kiểm thử xâm nhập chuyên nghiệp hay đánh giá bảo mật cho hệ thống xử lý tiền, dữ liệu sức khoẻ, dữ liệu cá nhân số lượng lớn. Với các hệ thống đó, mã AI viết cần đi qua đúng quy trình như mã người viết, cộng thêm một lượt rà chú ý vào những chỗ thiếu.
Cuối cùng, đừng đổ lỗi cho công cụ. Mã lên máy chủ mang tên người gộp, không mang tên trợ lý. Coi AI như một đồng nghiệp viết nhanh nhưng mới vào nghề: tin vào tốc độ của nó, còn phần kiểm thì vẫn của bạn.
Câu hỏi thường gặp
Mã AI viết có kém an toàn hơn mã người viết không?
Không có câu trả lời chung cho mọi trường hợp. Điều chắc chắn là AI hay tái tạo những mẫu phổ biến, kể cả mẫu không an toàn, và người rà dễ chủ quan vì mã trông gọn. Rà theo danh sách những thứ phải có giúp bù chỗ đó.
Công cụ quét tĩnh có đủ thay cho rà tay không?
Không đủ. Công cụ quét bắt tốt lỗi dạng mẫu như ghép chuỗi truy vấn, nhưng gần như không bắt được lỗi thiếu kiểm quyền hay sai logic nghiệp vụ. Dùng nó làm lượt lọc đầu, rồi người đọc tiếp những chỗ nó không hiểu được.
Có nên yêu cầu AI luôn viết mã an toàn trong mọi câu lệnh?
Một câu chung như “viết cho an toàn” giúp ít. Hiệu quả hơn là ghi quy ước cụ thể vào tệp hướng dẫn dự án: truy vấn tham số, đọc khoá từ biến môi trường, kiểm chủ sở hữu bản ghi. Quy ước cụ thể thì kiểm được.
Dự án nhỏ, công cụ nội bộ vài người dùng có cần kỹ như vậy không?
Công cụ nội bộ hay bị mở ra ngoài lúc nào không hay, và thường chạm vào dữ liệu thật của công ty. Không cần quy trình nặng, nhưng ít nhất soi ghép chuỗi truy vấn, khoá viết cứng và phân quyền trước khi cho người khác dùng.
Thấy lỗi bảo mật trong mã đã chạy thật thì làm gì trước?
Đánh giá xem lỗi có thể đã bị lợi dụng chưa bằng cách xem nhật ký truy cập, vá ở nhánh riêng, kiểm thử rồi đưa lên sớm. Nếu lỗi dính tới khoá bí mật thì thu hồi và đổi khoá trước khi làm bất cứ việc gì khác. Báo cho người phụ trách theo quy định của công ty.
Có nên dán mã công ty vào chatbot để nhờ rà bảo mật?
Chỉ khi công ty cho phép công cụ đó và bạn đã che khoá, địa chỉ nội bộ, dữ liệu khách. Đoạn mã chứa lỗ hổng chưa vá là thông tin nhạy cảm; nếu không chắc chính sách, hỏi người phụ trách trước khi dán.