AI viết mã giỏi ở chỗ làm cho tính năng chạy được, nhưng kém ở chỗ nghĩ đến người dùng xấu: nó hay để lộ khoá bí mật trong mã, quên kiểm ai được xem dữ liệu nào, tin mọi thứ người dùng nhập vào, và đôi khi gợi ý cả thư viện phần mềm không tồn tại. Một trang đặt lịch hay trang bán hàng làm xong trong một buổi tối có thể chạy mượt, đẹp, mà vẫn cho người lạ xem được danh sách khách của bạn.
Bài này viết cho chủ cửa hàng, chủ doanh nghiệp nhỏ đang tự làm ứng dụng nhỏ bằng AI hoặc thuê người làm có dùng AI hỗ trợ. Bạn không cần đọc được mã. Bạn cần biết những lỗ hổng nào hay gặp, hỏi người làm câu gì, và tự kiểm vài điểm đơn giản trước khi đưa trang lên mạng và bắt đầu thu thông tin khách. Bài chỉ nói nguyên lý để phòng, không đi vào cách khai thác.
Vì sao mã chạy được chưa chắc đã an toàn
Khi bạn nhờ AI làm một trang đặt lịch, tiêu chí bạn đặt ra thường là: khách điền được, lịch hiện ra đúng, bạn nhận được thông báo. AI tập trung đáp ứng đúng những tiêu chí đó. Còn chuyện một người không phải khách tìm cách xem lịch của người khác, gửi dữ liệu kỳ lạ vào ô nhập, hay dò địa chỉ trang quản trị, thì bạn không nói và AI không chắc sẽ tự nghĩ tới.
Mô hình học viết mã từ rất nhiều mã nguồn công khai, trong đó có không ít đoạn mã ví dụ được viết cho gọn, bỏ qua kiểm tra an toàn, hoặc theo cách đã lỗi thời. AI cũng không biết bối cảnh của bạn: trang này lưu số điện thoại khách, trang kia kết nối với tài khoản thanh toán. Với nó, mọi dự án đều giống bài tập.
Rủi ro lớn nhất thật ra nằm ở con người. Khi viết mã bằng tay, người viết hiểu từng dòng. Khi AI viết, người làm có thể chỉ kiểm xem chạy được không rồi giao. Nếu sau này có sự cố, không ai hiểu mã đủ để sửa nhanh. Vì thế câu hỏi nghiệm thu quan trọng nhất với người làm thuê không phải dùng công cụ gì, mà là ai hiểu và chịu trách nhiệm phần mã này.
Những lỗ hổng hay gặp, giải thích cho người không viết mã
Bảng dưới mô tả các lỗi thường thấy trong ứng dụng nhỏ do AI hỗ trợ viết, bằng ngôn ngữ đời thường, kèm câu hỏi bạn có thể đặt cho người làm.
| Lỗ hổng | Nói dễ hiểu | Hậu quả | Câu hỏi nghiệm thu |
|---|---|---|---|
| Khoá bí mật nằm trong mã | Mật khẩu cơ sở dữ liệu, khoá dịch vụ AI, khoá cổng thanh toán được viết thẳng vào mã | Ai thấy mã là dùng được tài khoản của bạn, kể cả tiêu tiền dịch vụ | Khoá bí mật được cất ở đâu, có nằm trong mã gửi lên kho lưu trữ không |
| Không kiểm quyền xem | Đổi một con số trên thanh địa chỉ là xem được đơn của người khác | Lộ thông tin khách hàng hàng loạt | Hệ thống kiểm người đang xem có đúng là chủ đơn không |
| Tin mọi dữ liệu nhập vào | Ô nhập tên, ghi chú nhận bất cứ thứ gì và đưa thẳng vào cơ sở dữ liệu hoặc trang | Dữ liệu bị phá, trang bị chèn nội dung lạ | Dữ liệu khách nhập được kiểm và làm sạch thế nào |
| Trang quản trị để ngỏ | Trang quản trị có địa chỉ dễ đoán, mật khẩu mặc định hoặc không có mật khẩu | Người lạ vào sửa, xoá, tải dữ liệu | Trang quản trị bảo vệ bằng gì, có xác thực hai lớp không |
| Mật khẩu khách lưu dạng đọc được | Mật khẩu khách lưu nguyên văn trong cơ sở dữ liệu | Lộ cơ sở dữ liệu là lộ luôn mật khẩu khách dùng ở nơi khác | Mật khẩu được lưu ở dạng băm hay nguyên văn |
| Thông báo lỗi kể quá nhiều | Khi lỗi, trang hiện cả đường dẫn máy chủ, câu truy vấn, phiên bản phần mềm | Người dò có thêm manh mối | Lỗi hiển thị cho khách là gì, chi tiết lỗi ghi ở đâu |
Bạn không cần hiểu kỹ thuật của từng dòng. Chỉ cần hỏi đúng câu và chú ý thái độ trả lời: người làm cẩn thận sẽ giải thích được; người trả lời kiểu chạy được là được thì cần kiểm thêm.
Ba rủi ro riêng của mã do AI hỗ trợ viết
Thư viện không tồn tại hoặc bị mạo danh. Mô hình đôi khi gợi ý cài một thư viện phần mềm có tên nghe hợp lý nhưng không có thật. Kẻ xấu biết điều này và có thể đăng ký trước những cái tên hay bị AI bịa, đặt mã độc vào đó. Người làm cài theo gợi ý là đưa mã độc vào ứng dụng của bạn. Mọi thư viện phải được kiểm là có thật, có người duy trì, có lượng người dùng đáng kể.
Cách viết cũ, thư viện lỗi thời. AI học từ mã của nhiều năm trước, nên có thể dùng phiên bản thư viện đã có lỗ hổng được công bố, hoặc cách làm mà cộng đồng đã khuyên bỏ. Mã chạy tốt, nhưng mang sẵn lỗi đã biết.
Không ai thật sự hiểu mã. Khi ứng dụng được ghép từ hàng trăm đoạn AI viết, người làm có thể không nắm được tổng thể. Lúc có sự cố hay cần vá lỗi gấp, việc sửa chậm và dễ sinh lỗi mới. Đây là rủi ro vận hành, nhưng hậu quả cuối cùng vẫn là bảo mật.
Tự làm ứng dụng nhỏ bằng AI: mức an toàn tối thiểu
Nếu bạn tự dùng AI làm một công cụ nhỏ cho cửa hàng, dưới đây là những việc tối thiểu trước khi cho khách dùng:
- Hỏi AI về an toàn ngay từ đầu. Khi giao việc, nói rõ ứng dụng sẽ lưu thông tin khách và cần chống người lạ xem dữ liệu của người khác. Sau khi có mã, nhờ AI rà lại chính mã đó theo góc bảo mật và giải thích từng rủi ro. Câu lệnh mẫu: hãy rà đoạn mã này như một người kiểm bảo mật, liệt kê chỗ nào có thể làm lộ dữ liệu khách và cách sửa.
- Không dán khoá bí mật thật vào cuộc trò chuyện. Dùng giá trị giả khi nhờ AI viết, rồi tự điền khoá thật vào chỗ cất riêng trên máy chủ. Che luôn dữ liệu khách thật nếu cần dán dữ liệu mẫu.
- Kiểm từng thư viện được gợi ý. Tìm trang chính thức của thư viện, xem có người duy trì, có lượt cài đặt đáng kể, có cập nhật gần đây không.
- Tự thử như người lạ. Mở trang bằng trình duyệt ẩn danh, không đăng nhập, thử vào trang quản trị, thử xem đơn của tài khoản khác bằng tài khoản thử của mình.
- Thu ít dữ liệu nhất có thể. Trang đặt lịch cần tên và số điện thoại, không cần ngày sinh hay số giấy tờ. Dữ liệu không thu thì không thể lộ.
- Bật sao lưu và cập nhật. Đặt lịch sao lưu cơ sở dữ liệu, ghi nhớ cập nhật thư viện mỗi khi có bản vá.
Ví dụ giả định: trang đặt lịch của tiệm làm móng
Chủ một tiệm làm móng nhờ người quen làm trang đặt lịch, người quen dùng AI hỗ trợ và giao trong ba ngày. Trang đẹp, khách đặt dễ, chủ tiệm hài lòng. Mỗi lịch hẹn có một trang xác nhận, địa chỉ trang kết thúc bằng một con số tăng dần.
Một khách tò mò đổi con số đó và thấy lịch hẹn của người khác, có tên, số điện thoại, giờ hẹn. Khách báo lại cho tiệm, may mà là người tử tế. Kiểm tra cho thấy mã không có bước kiểm người xem có phải chủ lịch hẹn không, đúng loại lỗi nằm ở hàng thứ hai của bảng phía trên. Người quen sửa trong một buổi, nhưng không ai biết trước đó đã có ai khác dò hết danh sách hay chưa.
Một câu hỏi nghiệm thu đơn giản lúc giao, kiểu đổi số trên địa chỉ có xem được lịch người khác không, đã phát hiện được lỗi này trong năm phút. Nếu dữ liệu khách đã có khả năng bị lộ, các bước đánh giá và thông báo cho khách thuộc chuyên mục xử lý sự cố.
Câu hỏi nghiệm thu khi thuê người làm
Dù người làm có dùng AI hay không, những câu sau nên có trong buổi nghiệm thu, và câu trả lời nên được ghi lại:
- Ai hiểu toàn bộ mã và chịu trách nhiệm sửa lỗi bảo mật trong thời gian bao lâu sau khi giao.
- Mã nguồn có được giao lại đầy đủ không, khoá bí mật cất ở đâu, đã đổi khoá thử nghiệm sang khoá mới chưa.
- Danh sách thư viện đã dùng, phiên bản, cách cập nhật.
- Tài khoản quản trị được bảo vệ thế nào, đã xoá tài khoản thử nghiệm và tài khoản của người làm chưa.
- Dữ liệu khách lưu ở đâu, sao lưu thế nào, ai truy cập được máy chủ.
- Đã thử trường hợp người lạ cố xem dữ liệu người khác chưa, thử bằng cách nào.
Nếu ngân sách cho phép và ứng dụng lưu nhiều dữ liệu khách hoặc có thanh toán, thuê một bên độc lập kiểm thử bảo mật trước khi mở cho khách là khoản đáng chi.
Khi nào ứng dụng nhỏ cần người kiểm chuyên nghiệp
Không phải công cụ nào cũng cần kiểm thử chuyên nghiệp. Một trang giới thiệu cửa hàng không có đăng nhập, không thu dữ liệu thì rủi ro thấp; một bảng tính tự động hoá dùng nội bộ trong ba người cũng vậy. Mức cần thận trọng tăng dần theo ba yếu tố: ứng dụng có lưu thông tin cá nhân của khách không, có dính đến tiền không, và có bao nhiêu người ngoài truy cập được.
Ứng dụng có cả ba yếu tố, như trang bán hàng có tài khoản khách và thanh toán trực tuyến, nên được người có chuyên môn kiểm trước khi chạy thật và sau mỗi lần thay đổi lớn. Ứng dụng có một hoặc hai yếu tố thì ít nhất làm đủ các bước tự kiểm ở trên và có người hiểu mã sẵn sàng sửa khi có báo lỗi. Cách nghĩ này giúp bạn tiêu tiền bảo mật đúng chỗ thay vì hoặc bỏ mặc, hoặc lo quá mức cho những thứ không đáng.
Câu hỏi thường gặp
Nhờ AI kiểm lại mã do chính AI viết có tác dụng không?
Có tác dụng một phần. Khi được hỏi riêng về bảo mật, AI thường chỉ ra được những lỗi phổ biến mà lúc viết nó bỏ qua. Nhưng đây không phải kiểm thử độc lập; với ứng dụng có dữ liệu khách và thanh toán, vẫn nên có người hiểu biết kiểm thêm.
Thư viện không tồn tại nguy hiểm thế nào?
Nếu AI gợi ý một thư viện không có thật và kẻ xấu đã kịp đăng ký đúng tên đó, người làm cài vào là đưa mã của kẻ xấu vào ứng dụng của bạn. Vì vậy mọi thư viện cần được kiểm là có thật và có người duy trì uy tín.
Có nên dán mã nguồn của cửa hàng vào chatbot để nhờ sửa lỗi không?
Được, nếu đã xoá khoá bí mật, mật khẩu, địa chỉ máy chủ và dữ liệu khách khỏi đoạn mã trước khi dán. Dùng tài khoản có điều khoản dữ liệu phù hợp với công việc, kiểm chính sách hiện hành của dịch vụ.
Làm sao biết khoá bí mật đã bị lộ?
Dấu hiệu thường gặp là hoá đơn dịch vụ tăng bất thường, có hoạt động lạ trong tài khoản dịch vụ, hoặc nhà cung cấp gửi cảnh báo. Khi nghi ngờ, thu hồi khoá cũ và tạo khoá mới ngay, rồi mới tìm hiểu nguyên nhân.
Người làm thuê có cần giao lại mã nguồn không?
Nên có trong hợp đồng. Không có mã nguồn, bạn phụ thuộc hoàn toàn vào một người, và khi có lỗ hổng mà họ không còn hỗ trợ thì không ai sửa được. Kèm theo mã nguồn là tài liệu về cách cài đặt, cập nhật, sao lưu.
Trang chỉ có vài chục khách có cần lo bảo mật không?
Cần, vì công cụ dò lỗ hổng tự động quét mọi trang trên mạng, không phân biệt lớn nhỏ. Vài chục khách vẫn là vài chục người có số điện thoại, địa chỉ có thể bị lộ, và cửa hàng vẫn có trách nhiệm với dữ liệu đó.