Strix 的 Django 框架安全测试 Playbook从攻击面建模到沙箱工具链的完整实战指南【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix本文基于 Strix 开源 AI 渗透测试工具内置的 Django 技能包strix/skills/frameworks/django.md完整讲解如何对 Django Web 应用与 Django REST FrameworkDRFAPI 进行安全测试覆盖 ORM/原生 SQL 滥用、中间件顺序、权限类缺口、会话与认证配置、模板注入、CSRF、IDOR/批量赋值、文件处理、SSRF、Host Header 投毒、Django Admin 以及 Channels/WebSocket 等全部攻击面并给出可复制的重建命令、验证标准与沙箱工具链用法。读完本文你可以掌握一套“按角色矩阵、逐端点验证对象级授权”的 Django 专项测试方法论并理解 Strix Agent 是如何将这类技能动态注入系统提示词来驱动自动化扫描的。一、技能包定位Django 技能在 Strix 技能体系中的角色Strix 将安全知识组织为“Skills技能包”——每个技能是一个带 YAML frontmatter 的 Markdown 文件按需注入 Agent 的系统提示词使其从“泛泛而谈的 LLM”变成针对特定框架/漏洞类型的专家。Django 技能属于frameworks类别与fastapi、nextjs、nestjs并列其 frontmatter 定义了元数据--- name: django description: Security testing playbook for Django applications covering ORM injection, middleware gaps, auth/session flaws, and template issues ---从源码结构看这套机制的实现要点如下均可在当前仓库中查证技能解析与加载strix/skills/init.py 中的load_skills()按strix/skills/category/name.md布局解析技能文件剥离 frontmatter 后返回 Markdown 正文validate_requested_skills()强制“每个 Agent 最多 5 个技能”的约束返回模型可读的错误提示并拒绝未知/歧义技能名。注入系统提示词strix/agents/prompt.py 的_resolve_skills()按固定顺序装配技能列表请求的技能 → 扫描模式 → 浏览器/Python 工具技能 → 证据纪律与严重度校准再由render_system_prompt()渲染进 system_prompt.jinja 模板技能正文进入specialized_knowledge区块其余可用技能列入available_skills。按需拉取当某个 Django 专项 Agent 未被预加载框架技能时可调用load_skill工具strix/tools/load_skill/tool.py把技能正文作为工具结果拉入对话——系统提示词明确要求“在测试某框架/协议/工具之前先 load_skill而不是凭记忆猜 payload”。可扩展性register_skill_dir()支持注册外部技能目录并优先于内置技能同名相对路径可覆盖内置技能测试用例见 tests/test_skill_dir_extension.py。配套文档docs/advanced/skills.mdx 与 strix/skills/README.md 说明了技能的分类体系、结构规范与贡献方式。一个典型的 Django 专项 Agent 创建方式来自技能文档体系中的示例create_agent( taskTest authentication mechanisms in API, nameDjango Auth Specialist, skillsdjango,business_logic )二、攻击面建模核心组件、认证与部署三层Django 技能开篇即给出三层攻击面地图这是后续所有测试步骤的索引。核心组件Core ComponentsURL 路由urls.py、类视图/函数视图、中间件栈middleware stackORMQuerySet 过滤器、原生 SQL、extra()、RawSQL、annotations模板层Django 模板语言若配置了 Jinja2 则为 Jinja2Forms、ModelForms、DRF serializers认证Authentication会话框架、AuthenticationMiddleware、login_required、DRFpermission_classesToken 认证、JWTdjangorestframework-simplejwt、OAuth 集成Django Admin/admin/、staff/superuser 标志位部署DeploymentDEBUGTrue暴露、ALLOWED_HOSTS、SECRET_KEY泄漏静态/媒体文件服务、反向代理、ASGIChannels、Daphne、Uvicorn三、高价值目标清单High-Value Targets技能文档将测试优先级压缩为 7 个“高价值目标”可直接作为扫描任务分发的清单/admin/— 暴力破解、凭证填充、Admin 对象上的 IDOR权限类混用的 API 端点— 同一个 ViewSet 内部分 action 有权限类、部分没有文件上传与导入导出—FileField、ImageField、django-import-export搜索/过滤端点— 使用filter()、Q对象或原生 SQL 的接口密码重置、邮箱验证、邀请 Token流程WebSocket consumersDjango Channels— 认证强度弱于对应 HTTP 接口的实时通道Celery 任务触发器— 接受用户 ID 但不做归属校验的异步任务。四、侦察与指纹识别Reconnaissance4.1 基础指纹curl -I https://target/ -H Cookie: sessionidtest # 观察 X-Frame-Options、Set-Cookiesessionid、csrftoken、Server 头 GET /admin/login/ GET /api/ /api/v1/ /swagger/ /api/schema/Django 指纹的关键信号Set-Cookie中的sessionid与csrftoken、/admin/login/页面的存在性以及 API 文档端点。4.2 配置泄漏DEBUGTrue 或配置错误时黄色调试页yellow debug page会暴露SECRET_KEY、数据库凭据、已安装应用列表/static/目录与携带堆栈跟踪的错误页会泄漏文件路径与 ORM 查询语句。4.3 OpenAPI / DRF 接口映射GET /api/schema/ GET /swagger.json拿到 schema 后为每条路由建立“端点 × 认证类 × 权限类”的映射表——这是后续权限矩阵测试的基础。五、关键漏洞类别详解5.1 认证与授权权限类缺口Permission Class GapsViewSet 的list有保护但retrieve/update漏配permission_classes自定义权限类只校验“已认证”而不校验对象归属IDORapi_view未显式声明权限时继承宽松默认值Admin actions 或自定义管理命令缺少 staff 检查。会话问题Session IssuesHTTPS 站点上SESSION_COOKIE_SECUREFalseCookie 缺HttpOnly登录时会话密钥未轮换 → 会话固定session fixation弱SECRET_KEY或已泄漏 → 可伪造会话 Cookiedjango.contrib.sessions.backends.signed_cookies后端。JWTsimplejwt算法固定配置错误导致的 RS256→HS256 算法混淆登出时缺少user_id/token 黑名单未强制 refresh token 轮换。5.2 注入类漏洞ORM SQL 注入多见于遗留代码User.objects.raw(fSELECT * FROM auth_user WHERE username {user_input}) User.objects.extra(where[fusername {user_input}])测试载荷 OR 11 --、时间盲注 payload、数据库特定语法。DRF Filter Backendsdjango-filter暴露了非预期字段的过滤?username__icontains打到敏感列?ordering缺少字段白名单时的排序注入。模板注入Django 模板默认自动转义风险点在于mark_safe(user_input) # 模板中的 |safe 过滤器 Template(user_input).render(...) # 若用户可控制模板源则为 SSTI配置 Jinja2 后端且未开 autoescape 时{{7*7}}判定模板注入沙箱配置错误时存在 RCE gadget。5.3 CSRF状态变更视图上滥用csrf_exemptDRF 会话认证 不安全方法上未强制 CSRFCSRF Cookie 未正确设置CSRF_USE_SESSIONS、trusted origins 配置错误CSRF_TRUSTED_ORIGINS过宽。验证方法携带受害者会话 Cookie 的跨源 POST会话认证的 JSON 端点重点测。5.4 IDOR 与批量赋值DRF Serializersfields __all__暴露is_staff、is_superuser、role、balance等敏感字段敏感 ModelSerializer 字段漏配read_only_fields嵌套写入跨租户更新外键。对象级权限get_object()未按request.user过滤 queryset通用视图queryset Model.objects.all()叠加弱权限类。5.5 文件处理DEBUG 下或 nginx 配置错误导致MEDIA_ROOT被直接服务自定义文件下载视图使用用户传入路径 → 路径穿越SVG/HTML 上传以可执行 XSS 的Content-Type回显上传缺少文件大小/类型校验。5.6 SSRFwebhook、预览、导入功能中的requests.get(user_url)Celery 任务服务端抓取用户 URL测试回环地址、云元数据 IP169.254.169.254 类地址、重定向链。5.7 Host Header / 密码重置投毒ALLOWED_HOSTS [*]或过宽的子域模式密码重置邮件从Host头构造 → 投毒重置链接account takeover 链;缓存页未按 Host 头 key 化 → 缓存投毒。5.8 Django Admin默认/admin/路径 弱凭据has_add_permission/has_change_permission覆写中的逻辑缺陷ModelAdmin 在list_display或导出中暴露敏感字段。5.9 Channels / WebSocketConsumer 建连时不与 HTTP 端保持会话/认证对等Group 名由用户输入派生 → 可订阅其他用户的频道WebSocket 握手缺少 Origin 校验。六、绕过技术Bypass Techniques技能文档列举的 5 类 Django/DRF 特化绕过手法内容协商JSON 与表单数据命中不同的 parser/权限路径HTTP 方法覆写或尾斜杠路由打到备选视图参数污染query 与 body 中同时出现重复id字段状态迁移竞态优惠券兑换、库存扣减通过并发请求触发版本化 API/api/v1/vs/api/v2/——旧版本认证更弱。七、测试方法论Testing Methodology技能文档定义的 7 步标准流程可逐步执行、逐步留证Map surface— 枚举 URL、DRF schema、admin、static/media 路径Auth matrix— 对每个端点的每种 HTTP 方法分别以未认证/普通用户/staff 三类身份测试Object ownership— 在所有 CRUD 路由上用两个用户账号互换 IDSerializer audit— 识别可写敏感字段与嵌套关系Middleware order— 确认认证先于业务逻辑执行检查会话 API 上的 CSRFChannel parity— WebSocket 动作的授权必须与 REST 等价端点对齐Settings review白盒— DEBUG、ALLOWED_HOSTS、SECRET_KEY、会话/Cookie 标志位。八、验证标准与误报甄别验证Validation——5 条取证要求并排请求side-by-side requests证明未授权访问IDOR、权限提升CSRF PoC以受害者会话执行状态变更针对会话认证端点SQLi/模板注入必须带确定性 oracle报错、时间差或7*7等价判定记录执行失败的具体位置view / serializer / permission class如适用展示从普通用户上下文获得了 admin/staff 能力。误报False Positives——5 条排除条件queryset.filter(userrequest.user)被一致地应用于包括嵌套路由在内的全部路径对象级权限类在所有 action 上正确校验归属已确认DEBUGFalse且为泛化错误页、无配置泄漏mark_safe仅用于服务端生成的可信内容所有会话认证的不安全方法上 CSRF 均正确执行。影响Impact——4 类最终后果会话伪造或密码重置投毒导致的账号接管IDOR 与批量赋值导致的横向/纵向权限提升ORM/SQL 注入或 serializer 字段过度暴露导致的数据泄露SSTI、pickle 缓存若使用或指向内网服务的 SSRF 导致的服务器失陷。实战技巧Pro TipsDRF ViewSets 常保护list却漏掉destroy或自定义action路由检查APIView子类缺permission_classes—— 高频疏漏点测试?format与 browsable API 的 HTML 响应在会话认证下的 CSRF 表现django.contrib.admin使用独立认证体系——不要假设 API 认证覆盖了 admin将 ASGI WebSocket consumer 与同一资源的 REST 权限逐一对比。九、白盒沙箱工具链如何最快触达上述 SinkDjango 技能的 Tooling 一节指出静态分析是白盒范围内触达上述危险点sink的最快方式。Strix 的扫描沙箱基于 Kali 镜像构建见 containers/Dockerfile预装了python/pipx、semgrep、bandit、ast-grep、ripgrep等工具与技能文档声明完全一致RUN pipx install semgrep \ pipx install bandit # 以及npm 全局安装 npm install -g ast-grep/clilatest技能文档给出的 4 个具体用法bandit预装—— Python 安全 lint标记mark_safe、extra()、RawSQL、subprocess、弱加密、硬编码密钥bandit -r . -llsemgrep预装配 Django 规则集——对框架特定 bug.extra()、RawSQL、|safe、csrf_exempt、ALLOWED_HOSTS[*]的信噪比高于 banditsemgrep --config p/django .更完整的 semgrep 沙箱工作流见 strix/skills/tooling/semgrep.md。pip-auditPyPA—— 依赖 CVE 扫描覆盖已知漏洞版本的 Django/DRF/simplejwtpipx install pip-audit pip-audit -r requirements.txtast-grep预装—— 不做完整 SAST 的快速结构化 grepast-grep run -p mark_safe($X) -l python关于“SECRET_KEY → 签名 Cookie/重置 Token 伪造”这一条攻击链技能文档特别指出Django 自带的django.core.signing就是攻击者的“工具”——拿到泄漏的密钥后可以用它生成合法的signing.dumps()值会话 Cookie、密码重置 Token以及基于PickleSerializer的会话 RCE 载体。这与 5.1 节“弱或泄漏 SECRET_KEY → 伪造 signed_cookies 会话 Cookie”的判定标准形成闭环。十、小结Django 的默认配置是“友好”的——CSRF 中间件、模板自动转义——但 DRF 权限类、原生 SQL、自定义权限与部署配置会持续制造缺口。这套 Strix 内置 playbook 的核心结论可归纳为一句话用角色分离的账号未认证/普通用户/staff测试每一个端点并在 queryset 层面而不只是认证存在性层面验证对象级授权白盒场景下优先用 bandit/semgrep/ast-grep 静态触达危险 sink再用黑盒并排请求完成取证最后按 5 条验证标准与 5 条误报排除条件收敛结论。该技能包位于 strix/skills/frameworks/django.md可通过load_skill工具或create_agent(skills[...])在 Strix 扫描流程中按需加载也可以参照 docs/advanced/skills.mdx 的结构规范为其他框架扩展同类技能。【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Strix 的 Django 框架安全测试 Playbook：从攻击面建模到沙箱工具链的完整实战指南
Strix 的 Django 框架安全测试 Playbook从攻击面建模到沙箱工具链的完整实战指南【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix本文基于 Strix 开源 AI 渗透测试工具内置的 Django 技能包strix/skills/frameworks/django.md完整讲解如何对 Django Web 应用与 Django REST FrameworkDRFAPI 进行安全测试覆盖 ORM/原生 SQL 滥用、中间件顺序、权限类缺口、会话与认证配置、模板注入、CSRF、IDOR/批量赋值、文件处理、SSRF、Host Header 投毒、Django Admin 以及 Channels/WebSocket 等全部攻击面并给出可复制的重建命令、验证标准与沙箱工具链用法。读完本文你可以掌握一套“按角色矩阵、逐端点验证对象级授权”的 Django 专项测试方法论并理解 Strix Agent 是如何将这类技能动态注入系统提示词来驱动自动化扫描的。一、技能包定位Django 技能在 Strix 技能体系中的角色Strix 将安全知识组织为“Skills技能包”——每个技能是一个带 YAML frontmatter 的 Markdown 文件按需注入 Agent 的系统提示词使其从“泛泛而谈的 LLM”变成针对特定框架/漏洞类型的专家。Django 技能属于frameworks类别与fastapi、nextjs、nestjs并列其 frontmatter 定义了元数据--- name: django description: Security testing playbook for Django applications covering ORM injection, middleware gaps, auth/session flaws, and template issues ---从源码结构看这套机制的实现要点如下均可在当前仓库中查证技能解析与加载strix/skills/init.py 中的load_skills()按strix/skills/category/name.md布局解析技能文件剥离 frontmatter 后返回 Markdown 正文validate_requested_skills()强制“每个 Agent 最多 5 个技能”的约束返回模型可读的错误提示并拒绝未知/歧义技能名。注入系统提示词strix/agents/prompt.py 的_resolve_skills()按固定顺序装配技能列表请求的技能 → 扫描模式 → 浏览器/Python 工具技能 → 证据纪律与严重度校准再由render_system_prompt()渲染进 system_prompt.jinja 模板技能正文进入specialized_knowledge区块其余可用技能列入available_skills。按需拉取当某个 Django 专项 Agent 未被预加载框架技能时可调用load_skill工具strix/tools/load_skill/tool.py把技能正文作为工具结果拉入对话——系统提示词明确要求“在测试某框架/协议/工具之前先 load_skill而不是凭记忆猜 payload”。可扩展性register_skill_dir()支持注册外部技能目录并优先于内置技能同名相对路径可覆盖内置技能测试用例见 tests/test_skill_dir_extension.py。配套文档docs/advanced/skills.mdx 与 strix/skills/README.md 说明了技能的分类体系、结构规范与贡献方式。一个典型的 Django 专项 Agent 创建方式来自技能文档体系中的示例create_agent( taskTest authentication mechanisms in API, nameDjango Auth Specialist, skillsdjango,business_logic )二、攻击面建模核心组件、认证与部署三层Django 技能开篇即给出三层攻击面地图这是后续所有测试步骤的索引。核心组件Core ComponentsURL 路由urls.py、类视图/函数视图、中间件栈middleware stackORMQuerySet 过滤器、原生 SQL、extra()、RawSQL、annotations模板层Django 模板语言若配置了 Jinja2 则为 Jinja2Forms、ModelForms、DRF serializers认证Authentication会话框架、AuthenticationMiddleware、login_required、DRFpermission_classesToken 认证、JWTdjangorestframework-simplejwt、OAuth 集成Django Admin/admin/、staff/superuser 标志位部署DeploymentDEBUGTrue暴露、ALLOWED_HOSTS、SECRET_KEY泄漏静态/媒体文件服务、反向代理、ASGIChannels、Daphne、Uvicorn三、高价值目标清单High-Value Targets技能文档将测试优先级压缩为 7 个“高价值目标”可直接作为扫描任务分发的清单/admin/— 暴力破解、凭证填充、Admin 对象上的 IDOR权限类混用的 API 端点— 同一个 ViewSet 内部分 action 有权限类、部分没有文件上传与导入导出—FileField、ImageField、django-import-export搜索/过滤端点— 使用filter()、Q对象或原生 SQL 的接口密码重置、邮箱验证、邀请 Token流程WebSocket consumersDjango Channels— 认证强度弱于对应 HTTP 接口的实时通道Celery 任务触发器— 接受用户 ID 但不做归属校验的异步任务。四、侦察与指纹识别Reconnaissance4.1 基础指纹curl -I https://target/ -H Cookie: sessionidtest # 观察 X-Frame-Options、Set-Cookiesessionid、csrftoken、Server 头 GET /admin/login/ GET /api/ /api/v1/ /swagger/ /api/schema/Django 指纹的关键信号Set-Cookie中的sessionid与csrftoken、/admin/login/页面的存在性以及 API 文档端点。4.2 配置泄漏DEBUGTrue 或配置错误时黄色调试页yellow debug page会暴露SECRET_KEY、数据库凭据、已安装应用列表/static/目录与携带堆栈跟踪的错误页会泄漏文件路径与 ORM 查询语句。4.3 OpenAPI / DRF 接口映射GET /api/schema/ GET /swagger.json拿到 schema 后为每条路由建立“端点 × 认证类 × 权限类”的映射表——这是后续权限矩阵测试的基础。五、关键漏洞类别详解5.1 认证与授权权限类缺口Permission Class GapsViewSet 的list有保护但retrieve/update漏配permission_classes自定义权限类只校验“已认证”而不校验对象归属IDORapi_view未显式声明权限时继承宽松默认值Admin actions 或自定义管理命令缺少 staff 检查。会话问题Session IssuesHTTPS 站点上SESSION_COOKIE_SECUREFalseCookie 缺HttpOnly登录时会话密钥未轮换 → 会话固定session fixation弱SECRET_KEY或已泄漏 → 可伪造会话 Cookiedjango.contrib.sessions.backends.signed_cookies后端。JWTsimplejwt算法固定配置错误导致的 RS256→HS256 算法混淆登出时缺少user_id/token 黑名单未强制 refresh token 轮换。5.2 注入类漏洞ORM SQL 注入多见于遗留代码User.objects.raw(fSELECT * FROM auth_user WHERE username {user_input}) User.objects.extra(where[fusername {user_input}])测试载荷 OR 11 --、时间盲注 payload、数据库特定语法。DRF Filter Backendsdjango-filter暴露了非预期字段的过滤?username__icontains打到敏感列?ordering缺少字段白名单时的排序注入。模板注入Django 模板默认自动转义风险点在于mark_safe(user_input) # 模板中的 |safe 过滤器 Template(user_input).render(...) # 若用户可控制模板源则为 SSTI配置 Jinja2 后端且未开 autoescape 时{{7*7}}判定模板注入沙箱配置错误时存在 RCE gadget。5.3 CSRF状态变更视图上滥用csrf_exemptDRF 会话认证 不安全方法上未强制 CSRFCSRF Cookie 未正确设置CSRF_USE_SESSIONS、trusted origins 配置错误CSRF_TRUSTED_ORIGINS过宽。验证方法携带受害者会话 Cookie 的跨源 POST会话认证的 JSON 端点重点测。5.4 IDOR 与批量赋值DRF Serializersfields __all__暴露is_staff、is_superuser、role、balance等敏感字段敏感 ModelSerializer 字段漏配read_only_fields嵌套写入跨租户更新外键。对象级权限get_object()未按request.user过滤 queryset通用视图queryset Model.objects.all()叠加弱权限类。5.5 文件处理DEBUG 下或 nginx 配置错误导致MEDIA_ROOT被直接服务自定义文件下载视图使用用户传入路径 → 路径穿越SVG/HTML 上传以可执行 XSS 的Content-Type回显上传缺少文件大小/类型校验。5.6 SSRFwebhook、预览、导入功能中的requests.get(user_url)Celery 任务服务端抓取用户 URL测试回环地址、云元数据 IP169.254.169.254 类地址、重定向链。5.7 Host Header / 密码重置投毒ALLOWED_HOSTS [*]或过宽的子域模式密码重置邮件从Host头构造 → 投毒重置链接account takeover 链;缓存页未按 Host 头 key 化 → 缓存投毒。5.8 Django Admin默认/admin/路径 弱凭据has_add_permission/has_change_permission覆写中的逻辑缺陷ModelAdmin 在list_display或导出中暴露敏感字段。5.9 Channels / WebSocketConsumer 建连时不与 HTTP 端保持会话/认证对等Group 名由用户输入派生 → 可订阅其他用户的频道WebSocket 握手缺少 Origin 校验。六、绕过技术Bypass Techniques技能文档列举的 5 类 Django/DRF 特化绕过手法内容协商JSON 与表单数据命中不同的 parser/权限路径HTTP 方法覆写或尾斜杠路由打到备选视图参数污染query 与 body 中同时出现重复id字段状态迁移竞态优惠券兑换、库存扣减通过并发请求触发版本化 API/api/v1/vs/api/v2/——旧版本认证更弱。七、测试方法论Testing Methodology技能文档定义的 7 步标准流程可逐步执行、逐步留证Map surface— 枚举 URL、DRF schema、admin、static/media 路径Auth matrix— 对每个端点的每种 HTTP 方法分别以未认证/普通用户/staff 三类身份测试Object ownership— 在所有 CRUD 路由上用两个用户账号互换 IDSerializer audit— 识别可写敏感字段与嵌套关系Middleware order— 确认认证先于业务逻辑执行检查会话 API 上的 CSRFChannel parity— WebSocket 动作的授权必须与 REST 等价端点对齐Settings review白盒— DEBUG、ALLOWED_HOSTS、SECRET_KEY、会话/Cookie 标志位。八、验证标准与误报甄别验证Validation——5 条取证要求并排请求side-by-side requests证明未授权访问IDOR、权限提升CSRF PoC以受害者会话执行状态变更针对会话认证端点SQLi/模板注入必须带确定性 oracle报错、时间差或7*7等价判定记录执行失败的具体位置view / serializer / permission class如适用展示从普通用户上下文获得了 admin/staff 能力。误报False Positives——5 条排除条件queryset.filter(userrequest.user)被一致地应用于包括嵌套路由在内的全部路径对象级权限类在所有 action 上正确校验归属已确认DEBUGFalse且为泛化错误页、无配置泄漏mark_safe仅用于服务端生成的可信内容所有会话认证的不安全方法上 CSRF 均正确执行。影响Impact——4 类最终后果会话伪造或密码重置投毒导致的账号接管IDOR 与批量赋值导致的横向/纵向权限提升ORM/SQL 注入或 serializer 字段过度暴露导致的数据泄露SSTI、pickle 缓存若使用或指向内网服务的 SSRF 导致的服务器失陷。实战技巧Pro TipsDRF ViewSets 常保护list却漏掉destroy或自定义action路由检查APIView子类缺permission_classes—— 高频疏漏点测试?format与 browsable API 的 HTML 响应在会话认证下的 CSRF 表现django.contrib.admin使用独立认证体系——不要假设 API 认证覆盖了 admin将 ASGI WebSocket consumer 与同一资源的 REST 权限逐一对比。九、白盒沙箱工具链如何最快触达上述 SinkDjango 技能的 Tooling 一节指出静态分析是白盒范围内触达上述危险点sink的最快方式。Strix 的扫描沙箱基于 Kali 镜像构建见 containers/Dockerfile预装了python/pipx、semgrep、bandit、ast-grep、ripgrep等工具与技能文档声明完全一致RUN pipx install semgrep \ pipx install bandit # 以及npm 全局安装 npm install -g ast-grep/clilatest技能文档给出的 4 个具体用法bandit预装—— Python 安全 lint标记mark_safe、extra()、RawSQL、subprocess、弱加密、硬编码密钥bandit -r . -llsemgrep预装配 Django 规则集——对框架特定 bug.extra()、RawSQL、|safe、csrf_exempt、ALLOWED_HOSTS[*]的信噪比高于 banditsemgrep --config p/django .更完整的 semgrep 沙箱工作流见 strix/skills/tooling/semgrep.md。pip-auditPyPA—— 依赖 CVE 扫描覆盖已知漏洞版本的 Django/DRF/simplejwtpipx install pip-audit pip-audit -r requirements.txtast-grep预装—— 不做完整 SAST 的快速结构化 grepast-grep run -p mark_safe($X) -l python关于“SECRET_KEY → 签名 Cookie/重置 Token 伪造”这一条攻击链技能文档特别指出Django 自带的django.core.signing就是攻击者的“工具”——拿到泄漏的密钥后可以用它生成合法的signing.dumps()值会话 Cookie、密码重置 Token以及基于PickleSerializer的会话 RCE 载体。这与 5.1 节“弱或泄漏 SECRET_KEY → 伪造 signed_cookies 会话 Cookie”的判定标准形成闭环。十、小结Django 的默认配置是“友好”的——CSRF 中间件、模板自动转义——但 DRF 权限类、原生 SQL、自定义权限与部署配置会持续制造缺口。这套 Strix 内置 playbook 的核心结论可归纳为一句话用角色分离的账号未认证/普通用户/staff测试每一个端点并在 queryset 层面而不只是认证存在性层面验证对象级授权白盒场景下优先用 bandit/semgrep/ast-grep 静态触达危险 sink再用黑盒并排请求完成取证最后按 5 条验证标准与 5 条误报排除条件收敛结论。该技能包位于 strix/skills/frameworks/django.md可通过load_skill工具或create_agent(skills[...])在 Strix 扫描流程中按需加载也可以参照 docs/advanced/skills.mdx 的结构规范为其他框架扩展同类技能。【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
