大型语言模型（LLM）具有独特的内部攻击面。但与此同时，模型通过应用程序接口（API）和其他界面对用户及其他系统开放时，也会产生传统且不容忽视的漏洞，这些漏洞同样值得我们关注。了解API层的安全是根本的，因为它常是通向模型功能的主要入口。在此语境下，API是一套规则和协议，它允许不同的软件组件进行通信，包括应用程序如何向大型语言模型发送用户查询并接收响应。

许多大型语言模型，特别是商业模型或部署在组织内部的模型，无法被直接使用。它们通常被封装在可通过API访问的服务中，这些API常是基于HTTP/S的RESTful API、GraphQL或gRPC。这些接口，连同任何附带的网页门户或管理仪表板，都成为攻击者的直接目标。API或其底层基础设施中的漏洞，可以绕过许多模型特有的防御措施，或为攻击者提供最初的立足点。

API层是用户/应用程序与核心大型语言模型之间的重要中介，使其成为攻击者的主要目标。

接下来，我们来检查一些大型语言模型API和接口中常见的攻击途径。

身份验证和授权缺陷

身份验证是验证用户或服务的身份，而授权是决定已验证的用户或服务被允许执行什么操作。这些方面的缺陷是典型的安全问题，但对大型语言模型有特定的影响。

认证薄弱或缺失： 如果大型语言模型API端点缺乏强效认证（例如，依赖易于猜测的API密钥，或某些意外暴露的“内部”端点完全没有认证），未经授权的用户就能访问模型。这可能导致未经授权的使用，产生由合法所有者承担的资源消耗费用，或访问潜在的敏感模型输出。
对象级别授权失效（BOLA）/不安全的直接对象引用（IDOR）： 假设一个API端点是/api/v1/models/{model_id}/query。如果攻击者可以修改{model_id}来访问他们未获授权的模型（例如，属于其他用户或组织的专有微调模型），这就是一个授权缺陷。同样地，如果通过操纵API调用中的标识符，可以访问用户特定数据，如聊天记录或微调数据集，则构成严重的数据泄露。
功能级别授权失效： API通常暴露不同的功能（例如，查询、微调、模型管理、用户管理）。如果一个只拥有查询大型语言模型权限的用户，由于不当的检查，能够找到方法调用管理型API功能（例如，/api/v1/admin/delete_model或/api/v1/users/{user_id}/update_permissions），他们可能会造成重大损害或提升自己的权限。

考虑一个使用API密钥进行认证的API。如果API密钥被硬编码在客户端代码中，通过代码库泄漏被发现，或者权限过于宽松，它就变成了一个入口点。

输入和参数验证不当（API层面）

提示注入（在另一节中介绍）处理的是大型语言模型输入的内容，而API本身必须验证所有传入数据的结构和类型，包括控制大型语言模型行为的参数。

无效的参数值： 大型语言模型API常接受max_tokens、temperature、top_p等参数，或特定模型的自定义参数。如果API未能严格验证这些参数（例如，未确保max_tokens是合理范围内的正整数），攻击者可能会：
- 提供意外的数据类型（例如，为max_tokens提供一个字符串）导致错误。
- 请求极高数量的令牌，导致资源过度消耗，可能引发拒绝服务或高昂的运营成本。
- 通过为temperature等采样参数提供超出范围的值，发现大型语言模型行为中的边界情况。
意外的内容类型或结构： 如果API期望JSON但收到XML或格式错误的JSON，它应妥善处理并返回清晰的错误。处理不当可能导致崩溃，甚至更糟的是，解析库中出现安全漏洞。
长度和大小限制： API应限制总请求大小和单个输入字段的长度。攻击者可能尝试发送过大的负载以压垮API服务器或大型语言模型的输入处理能力，导致拒绝服务（DoS）。

例如，如果API端点POST /api/generate期望JSON负载为{"prompt": "text", "length": 100}，但攻击者发送{"prompt": "text...", "length": "one hundred"}，API必须因length的数据类型不正确而拒绝。如果它在没有适当错误处理的情况下尝试将“one hundred”作为数字处理，可能导致不可预测的行为或应用程序错误。

限速和配额管理不足

API，特别是像大型语言模型这样计算密集型服务的API，必须具备限速和配额强制措施。

拒绝服务（DoS/DDoS）： 若无速度限制，攻击者（或甚至是一个有缺陷的脚本）可以向API发送大量请求，使大型语言模型服务不堪重负。这会导致服务对合法用户不可用，并且如果API使用是按量计费的，可能产生巨大的财务成本。
暴力破解攻击： 如果API涉及猜测（例如，弱API密钥、会话标识符），缺乏速度限制会使攻击者在短时间内进行多次尝试。
配额规避： 攻击者可能试图找到规避配额的方法，也许是通过操纵客户端标识符或借助多个免费套餐账户。

有效的请求速度限制应针对每个用户、每个IP地址，并可能全局实施，以防滥用。这不仅是为了阻止恶意行为者，也是为了确保公平使用和服务的稳定。

通过API响应的信息泄露

API可能会在响应中，特别是在错误消息或元数据中，不经意地泄露敏感信息。

详细的错误消息： 包含堆栈跟踪、内部服务器路径、数据库查询细节或特定软件版本的错误消息，可以为攻击者提供有关系统架构和潜在漏洞的有价值情报。例如，一个错误信息显示“ psycopg2.OperationalError: FATAL: password authentication failed for user 'llm_service_user' ”，会告诉攻击者数据库类型（PostgreSQL）和用户名。
配置或模型细节的暴露： 如果设计不慎，API端点可能无意中显露大型语言模型的配置部分、内部模型名称，甚至训练数据的统计属性。例如，在生产环境中仍保持活跃的调试端点，可能成为此类信息泄露的源头。
API行为不一致： 有时，API对有效和无效输入的响应方式可能泄露信息。例如，查询一个不存在的user_id得到“user not found”错误，而查询一个存在的但你无权访问的user_id得到“access denied”错误，这确认了该用户ID的存在。

安全最佳实践规定，面向公众的API的错误消息应通用化，详细日志应安全保存在服务器端以供诊断。

API层面的注入漏洞

这些与提示注入攻击不同，提示注入攻击针对的是大型语言模型对自然语言的解释。API层面的注入漏洞发生在用户提供给API端点的数据，在与大型语言模型交互之前或之外，被不安全地用于构建其他后端系统的命令、查询或文件路径时。

SQL注入（SQLi）： 如果API参数直接用于对后端数据库的SQL查询（例如，在查询大型语言模型之前获取用户偏好或模型配置），它可能容易受到SQL注入攻击。
命令注入： 如果API调用触发了一个服务器端脚本，该脚本使用输入参数来构建shell命令，攻击者可能能够注入恶意命令。
LDAP注入、NoSQL注入等： 根据API基础设施所使用的后端技术，可能存在其他类型的注入攻击。

尽管大型语言模型本身可能不直接处理这些注入的命令，但围绕它的API基础设施却可能受到影响。例如，如果API端点/api/v1/models/{model_name}/load使用model_name参数来构建文件路径，如/mnt/models/{model_name}.bin，而没有进行适当的净化处理，攻击者就可以使用路径遍历（../../..）来尝试加载任意文件。

API设计中的业务逻辑缺陷

有时，API根据其规范按设计运行，但设计本身包含可被利用的缺陷。这些缺陷常需要对应用程序的目的和工作流程有更透彻的理解。

利用预设功能： API可能提供一个功能，当以非预期顺序或特定输入使用时，会导致安全问题。例如，一个密码重置API未能妥善作废旧的重置链接，或者一个微调API如果范围界定不慎，允许覆盖基础模型。
竞态条件： 如果多个API调用可以同时与同一资源交互，可能发生竞态条件，潜在导致状态不一致或安全绕过。例如，两个请求同时尝试更新用户的配额。

识别业务逻辑缺陷通常需要超出自动化扫描的范围；它需要像攻击者一样思考系统功能如何被滥用。

不安全的API基础设施和配置错误

API的安全也依赖于其底层的基础设施：

API网关漏洞： 许多系统使用API网关（如Amazon API Gateway、Apigee、Kong）来管理、保护和开放API。这些网关本身可能存在漏洞或配置错误（例如，缓存敏感数据、不当的路由规则）。
过时的软件组件： 如果API所使用的Web服务器、操作系统、库乃至编程语言运行时未能及时更新，都可能存在已知漏洞。
不必要的端点或方法： OPTIONS、HEAD或TRACE等HTTP方法可能在不需要它们的API端点上启用，这可能显露信息或带来自身安全隐患。同样，调试或测试端点可能在生产环境中无意中暴露。

OWASP API安全十大项目是一个出色的资源，它列出了API最显著的安全风险，这些漏洞很多都直接适用于大型语言模型API。作为红队成员，您将经常使用标准的Web应用程序和API测试工具及方法（例如，使用Burp Suite或Postman等工具探测端点、模糊测试输入并分析响应）来发现这些类型的漏洞。

认识这些API层面的攻击途径是根本的一步。在许多情况下，通过API漏洞进行攻击是攻击者获得所需访问或信息的初步手段，之后可对大型语言模型本身发起更具针对性的攻击，例如复杂的提示注入或尝试提取模型处理的敏感数据。您在本课程后期的实践练习将包括分析大型语言模型API文档，以发现其中一些潜在的弱点。

这部分内容有帮助吗？