机器可以梦见安全代码吗？从AI幻觉到软件漏洞
#javascript #ai #applicationsecurity

随着Generativeai扩大其影响力，软件开发的影响并没有落后。生成模型尤其是语言模型（LMS），例如GPT-3，以及落在大型语言模型（LLMS）的保护下的模型。这包括编写代码。

这种进化预示着软件开发潜力的新时代，在该时代，AI驱动的工具可以简化编码过程，修复错误或可能创建全新的软件。但是，尽管这项创新的好处有望具有变革性，但他们也提出了前所未有的安全挑战。可以操纵Generativeai和LLM的功能，以在现有软件，反向工程专有系统中找到漏洞或生成恶意代码。因此，这些技术先进的机器学习模型的兴起带来了有关软件安全和系统漏洞的巨大潜力和新的问题。

AI幻觉的前奏

什么是AI幻觉？

在大语言模型（LLMS）的背景下，幻觉是指该模型生成其培训数据中未明确存在的信息或数据的实例。可以将其视为AI“想象”事物，提供答案或创建内容，这些内容在接受的学习中没有事实依据或基础。这些幻觉构成了人工智能行为的有趣方面，并提供了引人入胜的可能性，但是它们也引起了许多安全问题。

考虑以下与chatgpt的聊天互动，我指示它生成所需的任何文本，并具有特定的约束 - 生成的文本不得在其中包含英文字母。 P>

失败了：


让我考虑另一个例子。我会要求它解决一个简单的数学问题：


如您所见，我什至尝试通过文本的变化提示它，例如添加相等的符号 - 暗示它是需要解决的数学表达式。这也没有帮助，而216不是正确的答案。

为什么AI和Chatgpt幻觉？

在其核心上，Chatgpt并非终止条件构建，因为您可能会熟悉诸如For-loops之类的编程结构。一般而言，即使它没有意义或完全不正确，它也会始终努力完成接下来的令牌（一个单词）。

安全编码实践，开源软件和LLMS之间的相互作用

在软件开发的核心中，安全编码程序的关键实践不仅是对功能错误的强大，而且对安全威胁的弹性也有弹性。但是，在当今的动态和快节奏的开发环境中，开发人员经常使用诸如Stackoverflow之类的公共论坛中的开源软件和代码片段来加快其编码过程。

尽管这种做法有助于节省时间，但它可能无意间将大量的安全风险引入生产应用程序以及开发人员的日常工作流程，例如编写代码或创建CI/CD为GitHub操作而构建工作流程。开发人员是从Stackoverflow复制代码，GitHub评论还是GitHub Copilot自动完成，盲人信任，以及缺乏对复制代码的正确检查和验证可能会导致软件安全问题。


这种困境的一个值得注意的例子是Snyk发现的ZipSlip vulnerability。这是一个广泛的任意文件覆盖关键的安全漏洞，这意味着攻击者可以使用专门精心设计的档案库来覆盖可执行文件，从而控制受害者的机器。

关于这种情况的眉毛抬起的事情是，发现一个不安全但高度投资的堆叠式答案正在提供这次攻击容易受到攻击的代码，进一步表明未经验证的代码从开放论坛复制的隐藏安全危险。

添加到此汇合处是AI驱动的工具的新兴使用，例如Github副驾驶仪和Chatgpt。 GitHub Copilot是集成在VS代码IDE中的AI助手，并将代码的行或块作为开发人员类型。它的学习输入本质上是GitHub可以访问的所有公共代码存储库。同样，开发人员现在使用chatgpt生成代码段。但是，这些AI工具的广泛采用也提出了新的安全问题。鉴于这些LLM经过公共存储库和其他未经验证的开源代码培训，它可能会传播不安全的编码实践和漏洞。

在LLM生成的代码中导航路径遍历漏洞

我们确定，许多软件开发工具利用了称为大语模型（LLM）的复杂AI系统。这些LLM生成的代码，尽管具有实用性，但偶尔会将安全问题（例如路径遍历漏洞）引入生产软件。

路径遍历漏洞（也称为目录遍历）可以允许攻击者读取服务器文件系统上的任意文件，从而有可能访问敏感信息。假设开发人员要求像chatgpt这样的AI模型创建一个函数，以通过相对路径的目录操作或获取文件，从而处理用户输入。让我们看一下生成的node.js代码的示例：

const fs = require('fs');
const path = require('path');

function getFile(fileName) {
    const filePath = path.join(__dirname, fileName);
    return fs.readFileSync(filePath, 'utf-8');
}

以上本质上是在Nuxt和Next.js等框架中使用静态文件的方式，或者您是否正在运行本地Vite服务器，以通过Astro等网络框架使用静态生成的文件。

虽然上述函数getFile可能看起来完全无害，但它实际上隐藏了一个关键的路径遍历脆弱性。如果恶意用户提供了像'../../etc/passwd'这样的文件名，它将允许访问预期目录之外的敏感系统文件 - 路径遍历攻击的经典示例。

考虑以下概念证明：

console.log(getFile('../../etc/passwd'));

AI模型缺乏人类在各种情况下识别安全含义的能力。因此，使用AI生成的代码而无需仔细检查和修改可能会导致软件应用程序中的重要安全风险。正确对用户输入进行清理或使用语言，库或框架提供的安全抽象来防御路径遍历和其他潜在漏洞至关重要。对于我们的node.js示例，可以更安全的方法是：

function getFileSafe(fileName) {
    if (fileName.includes('..')) {
        throw new Error('Security alert: illegal file path');
    }
    const filePath = path.join(__dirname, fileName);
    return fs.readFileSync(filePath, 'utf-8');
}

但是，上述仍然容易受到其他攻击向量的影响。你知道这些可能是什么吗？如果您想知道或想猜测，我们鼓励您在@snyksec上使用您的想法在Twitter上进行Ping。

以下是一个真实示例，我要求chatgpt在Node.js上实现与精美的Fastify Web应用程序框架一起使用静态文件有关的功能。希望在这一点上，当您对路径遍历脆弱性的危险进行教育时，您可以发现其代码建议中包含的安全问题：


为了编写安全的代码，开发人员必须了解AI生成的代码传播漏洞的潜力。尽管LLM等CHATGPT提供了加速发展的希望，但人类的监督对于确保坚固，安全的代码库仍然至关重要。开发人员和工程师越来越责任在采用不受信任来源的代码时了解和管理安全含义。

大型语言模型和确定安全代码的挑战

尽管大语言模型（LLMS）的革命性进步和AI在编码实践中的集成，但重大挑战仍然是“ LLMS无法识别具有固有安全性漏洞的代码。卢克·辛德斯（Luke Hinds）以其对供应链安全性的贡献而闻名，shed light在此问题上以AI模型（例如Chatgpt）的各种代码生成示例，展示了这些模型如何未能涉及不同编程语言和脆弱性类型的潜在安全脆弱性。<

luke Hinds的示例证明了Chatgpt识别和避免其生成的代码中潜在安全陷阱的能力中的差距。无论是Python中的输入验证漏洞，GO中的伪随机数生成器的风险实施，还是在JavaScript代码中缺乏适当的错误处理 - 模型没有捕获这些风险。


例如，当被要求提供有关遭受TOCTOU（检查时间的安全时间安全问题）的代码块的见解时，它完全未能提及它或引起人们对使用操作系统的使用的关注S临时目录在代码中使用，这是实际应用程序中的一个明显的安全问题，这是由于OSS使用的预定义目录路径。这些示例说明了仅依靠AI来生成或识别生产质量代码而不了解全部安全性含义的危险。

核心问题在于AI LLM的训练方式。他们从Internet中吸取了大量数据，其中包括安全和不安全的代码。他们固有地了解其生成的代码的上下文，安全原则或含义。这强调了仔细且有条理的人类审查过程的重要性，无论守则的性质或AI创建的守则的性质如何。

Luke Hinds共享的这些见解引发了对软件开发中使用AI的固有风险的必要聚光灯。虽然AI和LLM提供了史无前例的机会来加速代码创建，甚至是软件开发的自动化方面，但开发人员有责任努力审查，验证并确保所得的代码遵守确保编码指南的遵守。”

AI安全风险和弹性AI系统的途径

人工智能（AI）一直在改变我们的运作方式，但是与任何技术进步一样，它遇到了自己的安全挑战。在他们的启发文件“ Securing the Future of AI and Machine Learning”中，Microsoft阐明了其中一些风险，并为致力于弹性AI系统提供了宝贵的见解。

让我们探索有关这些AI安全风险的三种观点：

  • 他们提出的一个令人着迷的点是攻击者在AI和机器学习（ML）中使用的数据集的开放性质所带来的脆弱性。攻击者无需妥协数据集，而是可以直接为它们做出贡献。随着时间的流逝，恶意数据（如果巧妙地伪装和结构正确）可以从低信心数据过渡到高信任，值得信赖的数据。这种固有的风险在确保数据驱动的AI开发方面构成了重大挑战。
  • 在深度学习模型中隐藏的分类器混淆。由于ML模型是臭名昭著的“黑匣子”，因此他们无法解释其推理过程阻碍了在审查时捍卫AI/ML发现的能力。 AI系统的这种特征，通常被称为缺乏解释性，引发了信任和接受的问题，尤其是在高风险领域中。
  • 此外，当前AI/ML框架中缺乏适当的取证报告功能加剧了这个问题。在法律情况和公众舆论法院，无需支持他们的证据，在法律情况和公众舆论中，都很难捍卫AI/ML模型的发现。这凸显了对AI系统中强大的审核和报告机制的需求。

Microsoft建议，要应对与AI，ML和Generativeai相关的这些固有的安全风险，将“弹性”纳入AI系统的特征至关重要。这些系统应旨在抵制与当地法律，道德相冲突的投入，并重视社区和创造者所拥有的，增强其安全性和可信赖性。

降低AI声明开发格局中的安全风险

当我们深入研究AI，LLM和GenerativeAi工具成为我们的编码实践和软件开发过程不可或缺的未来时，我们必须确保我们的创新热情不会掩盖维持强大安全实践的重要性。

为了最大程度地减少与安全编码和Generativeai工具相关的安全风险，一个强有力的建议将是实施严格的代码审查。无论该代码是由AI自动生成的还是由人类撰写的，它都应进行严格的质量检查和熟练的开发人员或代码审阅者的批判性评估。这不仅可以帮助捕获传统的编码错误，还可以识别AI模型可能未发现的安全漏洞。

此外，集成用于静态应用程序安全测试（SAST）的工具可以大大帮助减轻LLMS引入的潜在安全威胁。 SAST可以从内部进行审查，而无需执行该代码并在开发周期的早期阶段确定潜在的漏洞。在代码管道中自动化此类测试工具可以进一步增强安全漏洞的识别和缓解。

Snyk的深编码AI是为了利用多个AI模型而构建的，对特定于安全性的数据进行了培训，并且全部由顶级安全研究人员策划，以为开发人员提供实时安全的编码修复程序和INSECURE代码检测，并在编码时为开发人员提供实时安全的编码修复程序和Insecure Code检测。在他们的IDE中。

以下是Node.js Express Web应用程序的真实示例，该应用程序使用具有不安全的SQL代码的数据库后端，该代码易受SQL注入攻击。 VS代码中的Snyk IDE扩展名将不安全的代码视为JavaScript Linter Red凸出，提示开发人员的意识，更好的是建议解决问题的方法。


最后，也许最重要的措施之一是促进了开发团队中持续学习和适应的环境。创建一种文化，鼓励知识分享有关安全编码实践，潜在漏洞及其对策的最新趋势，可以很长的路要走。

关于AI安全的关闭思想

LLM和Generativeai模型等AI工具的敏捷掺入有望成为快速，优化软件开发的未来。

最终，生产安全，可靠和健壮的软件的责任仍然很大程度上在于人类开发人员。 AI代码生成工具（例如ChatGpt）应被视为需要人类指导来生成真正安全的生产质量代码的支持工具。

当我们进一步进入AI辅助时代时，关键是很明显的，这一点至关重要，我们对这种创新的热情与谨慎和警惕之间的热情保持了平衡。安全编码必须仍然是不可谈判的标准，无论代码是直接来自人类还是由AI建议。

。

当我们乘坐AI创新浪潮时，让我们努力维护无可挑剔的安全标准，保护我们的软件，系统以及最终依靠我们的用户。