黑客灵魂

这个屌丝很懒，什么也没留下！

热门标签

LLM应用的OWASP Top 10漏洞，【深度思考】_llm漏洞挖掘系统界面展示

作者：黑客灵魂 | 2024-07-20 10:49:51

踩

llm漏洞挖掘系统界面展示

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

1. 监控和警报超过阈值的偏斜响应数量。
2. 使用人工环路审查响应和审计。
3. 实施专用的LLM来benchmark不良结果，并使用强化学习技术对其他LLM进行训练。
4. 在LLM的生命周期的测试阶段执行基于LLM的红队演习或LLM漏洞扫描。
1
2
3
4

4 模型拒绝服务(LLM04: Model Denial of Service)

4.1 概念描述

与网站安全的DDoS攻击类似，攻击模型拒绝服务漏洞也是通过跟LLM进行某种交互并大量消耗资源，从而导致模型降低服务用户的质量。

与DDoS不同的是，针对LLM的DoS攻击还能通过干扰或操纵LLM的上下文窗口来实施。在LLM中，上下文窗口表示模型可以管理的文本的最大长度，包括输入和输出。这是LLM的一个关键特征，因为它决定了模型可以理解的语言模式的复杂性，以及它可以处理的文本大小。上下文窗口的大小由模型的架构定义，不同的模型可能不同。

总之，模型拒绝服务攻击可以通过大量交互访问或者操控上下文窗口使得模型的服务质量下降或者承受高昂的成本。

4.2 攻击举例

攻击者反复向托管模型发送多个复杂和昂贵的请求，导致其他用户服务质量下降，并使主机的资源费用增加。
某个LLM驱动的工具收集信息以响应正常查询。当遇到网页上的某段文本，非预期地导致该工具发出更多的网页请求，从而造成大量的资源消耗。
攻击者持续不断地向LLM发送超过其上下文窗口的输入。攻击者可能使用自动化脚本或工具发送大量输入，压倒LLM的处理能力。结果，LLM消耗了过多的计算资源，导致系统显著减速或完全无响应。
攻击者向LLM发送一系列连续的输入，每个输入都设计为略低于上下文窗口的限制。通过反复提交这些输入，攻击者旨在耗尽可用的上下文窗口容量。这使得LLM在其上下文窗口内处理每个输入都变得困难，进而导致系统资源变得紧张，最终可能导致性能下降或完全拒绝服务。
攻击者利用LLM的递归机制反复触发上下文扩展。通过构造特定输入以利用LLM的递归行为，攻击者迫使模型反复扩展和处理上下文窗口，以此消耗大量的计算资源。这种攻击会对系统造成压力，并可能导致DoS情况，使LLM无响应或导致崩溃。
攻击者向LLM洪水般地发送大量变长输入，精心设计以接近或达到上下文窗口的限制。通过向LLM发送不同长度的输入，攻击者旨在利用任何处理不同长度输入的低效性(缺陷)。这些输入的洪水会对LLM的资源造成过度负载，可能导致性能下降，并妨碍系统响应合法请求。
虽然DoS攻击通常旨在压倒系统资源，但它们也可以利用系统行为的其他方面，比如API限制。例如，在最近的Sourcegraph安全事件中，恶意行为者使用泄露的管理员访问令牌来更改API的速率限制，从而通过启用异常水位的请求量就可能导致服务中断。

4.3 如何防范

对输入内容进行验证和净化，确保用户的输入符合定义好的限制，并过滤掉任何恶意内容。
限制每个请求或步骤的资源使用，使涉及复杂部分的请求执行速度较慢。
强制限制API速率，在特定时间段内限制个人用户或IP地址可以发出的请求数量。
如果某个系统需要针对LLM做出响应，那么就要限制队列中的操作数量以及总的操作数量。
持续监控LLM的资源利用情况，用以识别可能暗示有DoS攻击的异常波动或模式。
对LLM的上下文窗口设置严格的输入限制，以防止过载和资源耗尽。
提高开发人员对LLM中潜在DoS漏洞的意识，并提供安全LLM的实施指南。

5 供应链漏洞(LLM05: Supply Chain Vulnerabilities)

5.1 概念描述

在机器学习领域，LLM可能经常采用一些大公司提供的预训练模型，或者采用第三方的数据进行训练。在这些供应链中可能存在漏洞，影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致偏见的结果、安全漏洞，甚至完全的系统故障。这些漏洞可能来源于过时的软件、受影响的预训练模型、被毒化的训练数据和不安全的插件。

5.2 攻击举例

如果系统使用了一个存在漏洞的Python库，攻击者可以利用该库使系统处于危险当中。
攻击者提供了一个恶意的LLM插件来搜索航班，生成导致用户受骗的虚假链接。
攻击者利用PyPi软件包注册表欺骗模型开发者去下载一个受破坏的软件包，并在模型开发环境中窃取数据或提升权限。这是一个真实的攻击案例。
攻击者对某个专门用于经济分析和社会研究的公开可用的预训练模型进行毒化，用于创建后门，生成错误信息和假新闻。然后他们将其部署在一个模型市场上（比如 Hugging Face），供受害者使用。
攻击者毒化公开可用的数据集，用以在微调模型时帮助创建后门。这个后门暗地里偏向于不同市场中的某些公司。
某个违规的供应商员工（外包开发人员、托管公司等）窃取数据、模型或代码，窃取知识产权。

5.3 如何防范

仔细审查数据来源和供应商，包括其条款和隐私政策，只使用可信任的供应商。确保有足够的、独立审计的安全措施，并且模型运营者的政策与您的数据保护政策一致，即您的数据不会用于训练他们的模型；类似的，寻求保证和法律措施，以防止模型维护者使用了受版权保护的材料。
只使用声誉良好的插件，并确保它们已经根据您的应用需求进行了测试。后文漏洞“不安全的插件设计”部分提供了关于不安全插件设计LLM方面的信息，您可以测试用以降低使用第三方插件的风险。
理解并应用“OWASP十大漏洞”中“A06:2021 - 脆弱和过时组件”提到的缓解措施。这包括漏洞扫描、管理和修补组件。对于具有访问敏感数据权限的开发环境，也在这些环境中应用这些控制措施。
使用软件材料清单（SBOM）维护组件的最新清单，以确保您拥有最新的、准确的、经过签名的清单，防止部署软件包被篡改。SBOM可以用于快速检测和提醒新的、0-Day漏洞。
截至本文档编写时，SBOM不包括模型、工件和数据集。如果您的LLM应用使用自己的模型，您应该使用MLOps的最佳实践和平台来提供包含数据、模型和实验跟踪的安全模型仓库。
在使用外部模型和供应商时，还应该使用模型和代码签名。
如前文所述漏洞“训练数据毒化”中所讨论的那样，对提供的模型和数据进行异常检测和对抗鲁棒性测试，可以帮助检测篡改和毒化。理想情况下，这应该是MLOps pipeline的一部分；然而，这些新兴的技术也许作为红队演练的一部分更容易去实施。
实施足够的监控来覆盖组件和环境的漏洞扫描、未经授权的插件使用、以及过时的组件，也包括模型及其工件。
实施补丁政策，用来减轻易受攻击或过时的组件风险。确保应用程序依赖于维护的API版本和底层模型。
定期审查和审核供应商的安全和访问权限，确保其安全态势或条款没有变化。

6 敏感信息泄露(LLM06: Sensitive Information Disclosure)

6.1 概念描述

LLM 应用有可能通过它们的输出透露敏感信息、专有算法或其他机密细节。这可能导致未经授权访问敏感数据、知识产权、隐私侵犯和其他安全漏洞。对于 LLM 应用的消费者来说，重要的是要意识到如何安全地与 LLM 进行交互，识别到无意中输入敏感数据的相关风险，这些数据可能随后会由 LLM 返回在其他地方的输出中。

为了减轻这一风险，LLM 应用应该进行充分的数据清洗，以防止用户数据进入训练模型数据。LLM 应用的所有者还应该制定适当的使用条款政策，让消费者了解他们的数据如何被处理，并有权选择不让他们的数据包含在训练模型中。

消费者与LLM应用之间的交互形成了一个双向的信任边界，我们不能天生信任客户端到LLM的输入或LLM到客户端的输出。需要注意的是某些前提条件，比如威胁建模练习、安全基础设施和充分沙箱，本漏洞假设它们是在考虑范围之外的。在系统提示中添加约束来限制LLM应该返回的数据类型，可以在一定程度上减轻敏感信息的泄露。但是作为LLM的基本特性之一的不可预测性，它意味着这种约束可能并不总是能被遵守，并且可能会通过提示注入或其他途径被规避。

6.2 攻击举例

毫无戒备心理的合法用户A在与LLM应用非恶意地交互时，通过LLM暴露给了某些其他用户数据。
用户A针对LLM发起了一系列精心设计的提示，以绕过LLM的输入过滤器和清洗，导致其透露出应用程序其他用户的敏感信息（PII）。
个人数据（例如PII）通过训练数据泄漏到模型中，原因可能是用户本身的疏忽，也可能是LLM应用的原因。这种情况可能增加了上述两种情况的风险和概率。

6.3 如何防范

集成充分的数据清洗和擦除技术，防止用户数据成为进入训练模型的数据。
实施强大的输入验证和清洗方法，以识别和过滤潜在的恶意输入，防止模型被毒化。
当使用数据来丰富模型或微调模型时（即在部署之前或期间输入到模型中的数据）：
1. 在微调数据中任何被视为敏感的信息都有可能被透露给用户。因此，应用最小权限原则，不要让模型在最高权限用户可以访问但可能显示给较低权限用户的信息上进行训练。
2. 对外部数据源的访问（在运行时进行数据编排）应受到限制。
3. 对外部数据源使用严格的访问控制方法，并采取严格的方法来维护安全的供应链。

7 不安全的插件设计(LLM07: Insecure Plugin Design)

7.1 概念描述

LLM插件是一种扩展，当启用时，模型在用户交互期间会自动调用它们。模型集成平台驱动它们，且应用程序可能无法控制它的执行，特别是当模型由另一方托管时。此外，插件可能会实现来自模型的自由文本输入，而没有进行验证或类型检查来处理上下文大小限制。这使得潜在的攻击者可以构造一个恶意请求发送到插件，并可能导致一系列不期望的行为，甚至包括远程代码执行。

恶意输入的危害往往取决于不充分的访问控制以及插件之间失败的授权跟踪。不充分的访问控制允许插件盲目地信任其他插件，并假设最终用户提供的输入。这种不足的访问控制可能使恶意输入产生从数据外泄、远程代码执行到权限提升等有害后果。

本条目聚焦于创建LLM插件而不是使用第三方插件，因为在LLM“供应链漏洞”部分涵盖了它。

7.2 攻击举例

某插件接受一个基本URL，并指示LLM将URL与查询组合以获取天气预报，这些预报包含在处理用户请求中。恶意用户可以构造一个请求，使URL指向他们控制的域，从而允许他们通过自己的域注入内容到LLM系统中。
某插件接受自由形式的输入到某一字段中，但未做验证。于是攻击者输入精心构造的负载，并检测错误消息获取更多可能被利用的信息。然后利用已知的第三方漏洞来执行代码以实施数据外泄或权限提升。
某插件用于从向量存储(vector store)中检索嵌入(embedding)，并接受配置参数作为连接字符串，但没进行任何验证。这使得攻击者可以通过更改名称或主机参数来试验并访问其他向量存储，并窃取他们不应该访问的嵌入。
某插件接受SQL WHERE子句作为高级过滤器，然后将其附加到过滤SQL中。这使得攻击者可以发动SQL攻击。
攻击者使用间接提示注入来利用一个不安全的代码管理插件，该插件没有输入验证且访问控制薄弱，以转移代码仓库所有权并锁定用户使得他们无法访问自己的代码仓库。

7.3 如何防范

插件应尽可能强制执行严格的参数化输入，并对输入进行类型和范围检查。当这不可行时，则引入额外的类型化调用验证层，解析请求并应用验证和净化。当由于应用语义而必须接受自由形式输入时，应仔细检查以确保没有调用任何潜在有害的方法。
插件开发人员应根据OWASP在ASVS（Application Security Verification Strandard 应用程序安全性验证标准）中提供的建议来进行适当的输入验证和清理。
应彻底检查和测试插件，以确保充足的验证。在开发管道pipeline中使用静态应用程序安全性测试（Static Application Security Testing, SAST）扫描和动态交互式应用程序测试（Dynamic and Interactive application testing, DAST，IAST）。
插件应遵循OWASP ASVS访问控制指南(ASVS Access Control Guidelines)，设计为最小化任何利用不安全输入参数所带来的影响。这包括最小特权访问控制，在执行所需功能的同时尽可能暴露少的功能。
插件应使用适当的身份验证标识，例如OAuth2，以应用有效的授权和访问控制。此外，API密钥应该用于提供自定义授权决策的上下文，该上下文反应的是插件路由而不是默认的交互用户。
对于敏感插件采取的任何操作，都要求用户手动授权和确认。
插件通常是REST API，因此开发人员应该采用OWASP Top 10 API安全风险 - 2023(OWASP Top 10 API Security Risks – 2023)中的建议，用以最小化通用漏洞。

8 过度代理(LLM08: Excessive Agency)

8.1 概念描述

通常开发者会授予基于LLM的系统一定程度的代理能力，以使其能与其他系统进行交互，并根据提示来执行某些操作。甚至决定调用哪些功能也可能是委托给LLM的“代理人(agent)”，去根据输入提示或LLM输出来动态确定。

过度代理是这么一种漏洞，能在LLM产生意外/模糊输出时执行破坏性操作（无论是什么原因导致LLM发生故障，是幻觉/虚构、直接/间接提示注入、恶意插件、设计不佳的提示，还是仅仅因为模型性能较差）。过度代理典型的根本原因有以下一个或多个：功能过度、权限过度或自治权过度。与“不安全的输出处理”漏洞不同，后者关注的是对LLM输出的审查不足。

过度代理可能会导致在机密性、完整性和可用性范围内产生广泛的影响，这取决于LLM应用能够与哪些系统进行交互。

8.2 攻击举例

基于LLM的个人助手应用程序通过插件获得了访问个人邮箱的权限，以便总结收件箱中的内容。为了实现这一功能，电子邮件插件需要读取消息的能力，但系统开发者选择使用的这个插件还包含发送消息的功能。当LLM存在间接提示注入攻击的漏洞时，通过传入恶意制作的电子邮件，欺骗LLM命令电子邮件插件调用“发送消息”功能，从用户的邮箱发送垃圾邮件。

8.3 如何防范

以下操作可以防止过度代理：

限制LLM代理所允许调用的插件和工具，只使用最小的必要功能。例如，如果基于LLM的系统不需要获取URL的内容，则不应将此类插件提供给LLM代理。
限制LLM插件和工具实现的功能，只实现最小的必要功能。例如，用于访问用户邮箱以总结电子邮件的插件可能仅需要读取邮件的能力，因此插件不应包含删除或发送邮件等其他功能。
尽可能避免开放式功能（例如运行shell命令、获取URL等），并使用具有更细粒度功能的插件/工具。例如，基于LLM的应用程序可能需要将一些输出写入文件。如果使用插件来运行shell函数实现此目的，则不良操作的范围非常大（可以执行任何其他shell命令）。更安全的替代方案是构建一个只支持特定功能的文件写入插件。
访问其他系统的LLM插件及工具，授予它们的权限需要被限制为最小必要的权限，以限制不良操作的范围。例如，LLM代理使用产品数据库向客户提供购买建议，可能它只需要对“产品”表具有读取权限；它不应该访问其他表，也不应该具有插入、更新或删除记录的能力。这通过给标识采用合适的数据库权限来实施，该标识是LLM插件用来链接数据库的。
跟踪用户授权和安全的范围，以确保在下游系统中代表用户执行的的操作是在该特定用户的上下文中，并且授予的是最小的必要权限。例如，读取用户代码仓库的LLM插件应要求用户通过OAuth进行身份验证，并且权限范围最小。
利用人工控制授权，要求执行所有操作之前需要得到人的批准。这可以在下游系统（LLM应用程序范围之外）或LLM插件和工具本身中实施。例如，代表用户创建并发布社交媒体内容的基于LLM的应用程序应在“发布”操作的插件/工具/API中包含用户批准流程。
在下游系统中实施授权，而不是依赖LLM来决定是否允许执行操作。在实现工具或插件时强制实施完全中介原则，所以通过插件和工具对下游系统发出的所有请求都根据安全策略进行了验证。

以下选项不会防止过度代理，但可以限制造成的损害程度：

记录并监视LLM插件/工具和下游系统的活动，以确定不良操作发生的位置，并相应地做出响应。
实施速率限制，以减少在给定时间段内可能发生的不良操作数量，增加通过监视发现不良操作的机会，以在发生重大损害之前发现它们。

9 过度依赖(LLM09: Overreliance)

9.1 概念描述

过度依赖可能发生在大型语言模型（LLM）产生错误信息并以权威的方式提供它的情况下。虽然LLM可以生成富有创意和信息性的内容，但它们也可能产生事实不正确、不适当或不安全的内容，这被称为幻觉或臆断。当人们或系统在没有监督或确认的情况下信任这些信息时，可能会导致安全漏洞、错误信息、沟通不畅、法律问题和声誉损害。

LLM生成的源代码可能引入未被注意到的安全漏洞，这对应用程序的操作安全和安全性构成了重大风险。

9.2 攻击举例

某新闻机构大量使用LLM生成新闻文章。恶意行为者利用这种过度依赖，向LLM提供误导性信息，导致虚假信息的传播。
人工智能无意中窃取了相关内容，导致版权问题并降低了组织的信任度。
某软件开发团队利用LLM系统加速编码过程。过度依赖AI的建议导致应用程序中出现安全漏洞，可能是由于不安全的默认设置或给出的建议与安全编码实践不一致。
某软件开发公司使用LLM来协助开发人员。LLM 建议了一个不存在的代码库或包，开发人员信任人工智能，不知不觉地将恶意包集成到公司的软件中。这也突显了交叉检查LLM建议的重要性，尤其是涉及第三方代码或库时。

9.3 如何防范

定期监控和审查LLM的输出。使用自洽性或投票技术来过滤不一致的文本。对于单个提示，比较多个模型响应可以更好地评估输出的质量和一致性。
与可信的外部来源交叉检查LLM的输出。这种额外的验证层可以帮助确保模型提供的信息准确可靠。
通过精调或嵌入来增强模型以改善输出质量。与特定领域中调整过的模型相比，通用的预训练模型更容易产生不准确的信息。可以采用提示工程、PET(parameter efficient tuning)、全模型调整和思维链提示等技术来实现这一目的。
实施自动验证机制，可以将生成的输出与已知事实或数据进行交叉验证。这可以提供额外的安全层，并减轻与幻觉相关的风险。
将复杂任务分解为可管理的子任务，并将它们分配给不同的代理。这不仅有助于管理复杂性，还减少了幻觉的可能性，因为每个代理可以负责一个较小的任务。
清楚地传达使用LLM时的风险和限制。这包括信息不准确性的潜在风险和其他风险。有效的风险沟通可以使用户为潜在问题做好准备，并帮助他们做出明智的决策。
构建API和用户界面以促进负责任地和安全地使用LLM。这包括内容过滤器、有关潜在不准确性的用户警告和AI生成内容的清晰标记。
在开发环境中使用LLM时，建立安全的编码实践和指南，以防止可能集成漏洞。

10 模型盗窃(LLM10: Model Theft)

10.1 概念描述

这个条目涉及恶意行为者或APT攻击者未经授权访问和外泄LLM模型的情况。这种情况发生在专有的LLM模型（作为有价值的知识产权）被破坏、物理上被盗窃、复制或权重和参数被提取以创建一个功能上等价的模型的情况。LLM模型被盗窃的影响可能包括经济和品牌声誉损失、竞争优势的侵蚀、模型的未经授权使用或未经授权访问模型内部包含的敏感信息。

因为语言模型变得越来越强大和普及，LLM盗窃也成为了一个重大的安全问题。组织和研究人员必须优先考虑采取强大的安全措施来保护他们的LLM模型，确保其知识产权的保密性和完整性。对于减轻与LLM模型盗窃相关的风险、保护依赖LLM的个人和组织的利益，采用包括访问控制、加密和持续监控等手段在内的综合安全框架至关重要。

10.2 攻击举例

攻击者利用公司基础设施的漏洞未经授权地访问了他们的LLM模型仓库。攻击者进而窃取有价值的LLM模型，并使用它们启动了一个竞争性的语言处理服务或者提取了敏感信息，给原始公司造成了重大的财务损失。
一名不满的员工泄露了模型或相关的资产。这种情景的公开曝光增加了攻击者进行灰盒对抗性攻击的知识或者直接窃取可用财产的可能性。
攻击者通过精心选择的输入查询API，并收集足够数量的输出以创建一个影子模型。
在供应链中存在失败的安全控制，导致专有模型信息的数据泄露。
恶意攻击者绕过LLM的输入过滤技术和序文，进行侧信道攻击(side-channel attacks)，并将模型信息检索到他们控制的远程资源中。
最近公布的一篇论文，感兴趣的可以翻阅：Stealing Part of a Production Language Model

10.3 如何防范

实施强访问控制（例如: Role-based Access Control(RBAC) 和最小权限原则）和强身份验证机制，限制对LLM模型仓库和训练环境的未经授权访问。因为内部威胁、配置错误和/或对承载LLM模型、权重和架构这些基础设施的弱安全控制，恶意行为者可能会从内部或外部渗透。供应商管理跟踪、验证和依赖性漏洞是防止供应链攻击利用的重要关注点。
限制LLM对网络资源、内部服务和API的访问。这种限制可能是防止侧信道攻击(side-channel attacks)的一种机制或预防步骤。
定期监控和审计与LLM模型仓库相关的访问日志和活动，及时检测和应对任何可疑或未经授权的行为。
使用治理、跟踪和审批工作流的自动化MLOps部署，以加强基础设施内的访问和部署控制。