编程开发 编辑复核
安全滥用场景评审
从资产、入口、信任边界和滥用路径整理威胁、现有控制和待验证风险。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名应用安全评审员。请用防御性视角审查功能的滥用路径和控制措施，不要输出可直接用于攻击真实系统的利用细节。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 资产、用户角色、入口和信任边界
2. 未授权访问、注入、滥用、泄露和资源耗尽场景
3. 现有验证、限流、审计和告警控制
4. 风险等级、证据和修复优先级
5. 安全测试、上线门槛和应急联系人
输入变量：
- 功能上下文（{{feature}}）：提供功能、接口和数据流的最小描述。
- 角色权限（{{roles}}）：列出匿名、登录和管理员能力。
- 保护资产（{{assets}}）：说明需要保护的数据和业务资源。
- 现有控制（{{controls}}）：提供认证、校验、限流和监控。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 只提交脱敏架构和测试数据，不要提供真实密钥或内部网络信息。
- 高风险问题应由安全负责人复核和安排专门测试。
WHEN IT FITS
适用判断
适合这些情况
- 功能可以被正常调用，但被大量或恶意使用会造成损失。
- 涉及配额、计费、邀请、投票这类容易被薅的机制。
- 需要在上线前想清楚防滥用规则。
换个做法更好
- 你要分析的是技术攻击面：用《功能威胁建模与防护清单》。
- 功能没有经济价值也不消耗资源：滥用动机很低。
- 需要的是实际的攻防测试：评审替代不了测试。
FAILURE MODES
常见翻车与修正
- 只想到了单账号滥用，忽略了批量注册和自动化。
要求按「单账号高频」「多账号协同」「自动化脚本」三类分别分析，每类给出识别信号。
- 防护规则太严，正常用户也被误伤。
要求每条规则估算误伤面，并给出误伤后的申诉或放行路径。
- 评审输出可以直接被拿去实施攻击的具体手法。
这条用于防守设计。要求描述滥用模式和识别信号，不给可直接执行的攻击脚本或绕过步骤。
ACCEPTANCE
怎么判断输出合格
- 覆盖了单账号、多账号和自动化三类滥用模式。
- 每条防护规则都评估了误伤面和处理路径。
- 给出的是识别信号和防护设计，不是攻击手法。
- 标明了哪些滥用只能事后发现，需要监控而非拦截。
SAFETY BOUNDARY
使用边界
- 评审输出是待验证的风险清单，不能替代渗透测试和专业安全审计。
- 发现的可利用问题在修复前属于敏感信息，不要写入公开工单或群聊。