大型语言模型(LLM)具有独特的内部攻击面。但与此同时,模型通过应用程序接口(API)和其他界面对用户及其他系统开放时,也会产生传统且不容忽视的漏洞,这些漏洞同样值得我们关注。了解API层的安全是根本的,因为它常是通向模型功能的主要入口。在此语境下,API是一套规则和协议,它允许不同的软件组件进行通信,包括应用程序如何向大型语言模型发送用户查询并接收响应。许多大型语言模型,特别是商业模型或部署在组织内部的模型,无法被直接使用。它们通常被封装在可通过API访问的服务中,这些API常是基于HTTP/S的RESTful API、GraphQL或gRPC。这些接口,连同任何附带的网页门户或管理仪表板,都成为攻击者的直接目标。API或其底层基础设施中的漏洞,可以绕过许多模型特有的防御措施,或为攻击者提供最初的立足点。digraph G { rankdir=TB; node [shape=box, style="filled", color="#495057", fillcolor="#e9ecef", fontname="Arial", fontsize=10]; edge [fontname="Arial", color="#495057", fontsize=9]; attacker [label="攻击者", shape=oval, fillcolor="#ffc9c9", fontsize=10]; user_interface [label="用户界面\n(网页应用, 聊天机器人)", fillcolor="#d0bfff", fontsize=10]; subgraph cluster_system { label = "大型语言模型系统组件"; style="dotted"; color="#adb5bd"; api_layer [label="API层\n(例如, REST, GraphQL)", shape=component, fillcolor="#74c0fc", fontsize=10]; llm_model [label="核心大型语言模型引擎", fillcolor="#96f2d7", fontsize=10]; data_storage [label="数据存储\n(训练数据, 日志, 用户数据)", fillcolor="#ffec99", fontsize=10]; supporting_services [label="支持服务\n(监控, 内容过滤)", fillcolor="#ffd8a8", fontsize=10]; } attacker -> user_interface [label="通过用户界面互动\n(间接API使用)"]; attacker -> api_layer [label="直接API交互\n(本节重点)", color="#f03e3e", penwidth=1.5, fontcolor="#f03e3e"]; user_interface -> api_layer [label="合法\n客户端请求"]; api_layer -> llm_model [label="已处理的\n提示"]; llm_model -> api_layer [label="已生成的\n响应"]; api_layer -> data_storage [label="访问/存储数据", style=dashed]; api_layer -> supporting_services [label="使用服务", style=dashed]; supporting_services -> llm_model [label="影响/监控", style=dashed]; {rank=same; attacker; user_interface;} }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文档,以发现其中一些潜在的弱点。