安全研究人员发现，由大语言模型（LLM）生成的代码存在重大漏洞。研究表明，借助人工智能助手进行 “氛围式编码”（vibe coding，指依赖 AI 生成代码时侧重实现效果、忽视底层安全逻辑的编码方式），可能会给生产环境中的应用程序引入严重安全缺陷。
一项新研究指出，LLM 生成的代码往往优先考虑功能实现而非安全性，由此产生的攻击向量，只需通过简单的 curl 命令即可利用。
- LLM 生成的代码会继承不安全的代码模式，为实现功能而牺牲安全性。
- 暴露的端点（endpoint）使得攻击者可通过简单的 curl 命令轻松发起攻击。
- 人为监督（包括威胁建模、代码审查和安全扫描）至关重要。
希曼舒・阿南德（Himanshu Anand）指出，根本问题在于 LLM 的训练数据源自互联网爬取，而这些数据中的大多数代码示例仅以演示功能为目的，并未遵循安全最佳实践。
当开发人员过度依赖 AI 生成的代码，且未进行充分的安全审查时，这些不安全的代码模式会大规模渗透到生产系统中。
研究显示，LLM 无法理解业务风险，也缺乏进行合理威胁建模所需的上下文感知能力。
其训练数据中天然包含大量来自在线教程、Stack Overflow 问答和文档示例的易受攻击代码模式 —— 这些代码模式均以快速实现功能为首要目标，而非采用安全的设计思路。
一个尤为值得警惕的案例是：某款部署在 Railway [.] com 平台上的 JavaScript 应用，其整个邮件 API 架构均暴露在客户端。该易受攻击的代码包含以下问题（原文未列出具体代码，此处为案例背景说明）：
该研究包含一项概念验证攻击，展示了暴露的客户端 API 如何被利用：
这一简单命令（原文未列出具体命令，此处为攻击原理说明）揭示了三个关键攻击向量：
- 针对任意邮箱地址的垃圾邮件攻击
- 利用逼真的机构名义信息冒充客户
- 通过伪造可信发件人地址滥用内部系统
该漏洞使攻击者能够完全绕过预期的 Web 界面，在无需身份验证、不受频率限制的情况下，直接向后端服务发送无限量请求。
研究强调，尽管 LLM 可作为强大的编码助手，但在安全层面仍需人工监督。
企业不应将 AI 生成的代码直接部署到生产环境，而必须实施规范的威胁建模、安全审查和纵深防御策略。
安全团队应重点制定安全编码指南，对 LLM 生成的代码实施自动化安全扫描，并在安全审查流程中保留人工专业判断环节 —— 以防止这类漏洞被系统性地引入系统。
红客联盟·免责声明
1. 本版块文章内容及资料部分来源于网络，不代表本站观点，不对其真实性负责，也不构成任何建议。
2. 部分内容由网友自主投稿、编辑整理上传，本站仅提供交流平台，不为该类内容的版权负责。
3. 本版块提供的信息仅作参考，不保证信息的准确性、有效性、及时性和完整性。
4. 若您发现本版块有侵犯您知识产权的内容，请及时与我们联系，我们会尽快修改或删除。
5. 使用者违规、不可抗力（如黑客攻击）或第三方擅自转载引发的争议，联盟不承担责任。
6. 联盟可修订本声明，官网发布即生效，继续使用视为接受新条款。
联系我们：admin@chnhonker.com
