菜单
Security testing playbook for Django applications covering ORM injection, middleware gaps, auth/session flaws, and template issues
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Authorized AI penetration testing assistant for web applications, APIs, and infrastructure. Performs reconnaissance, vulnerability assessment, PoC validation, exploit chaining, and professional reporting. Use when the user asks for pentest, penetration test, security assessment, vulnerability scan, bug bounty research, authorized hacking, SQLi/XSS/IDOR/SSRF testing, API security audit, or exploit validation.
Authorized AI penetration testing for web apps, APIs, cloud, and infrastructure. Full kill-chain methodology with PoC validation, vulnerability chaining, and professional reporting. Triggers on: pentest, penetration test, security assessment, vuln scan, bug bounty, red team, authorized hack, SQL injection test, XSS test, IDOR, SSRF, API security, exploit validation, security audit.
Authorized AI penetration testing assistant — full-spectrum security testing with deep exploitation skills and integrated tooling. Use for web app pentests, API security, vuln validation, PoC development, bug bounty, and security assessments. Triggers on pentest, penetration test, security audit, exploit, SQLi, XSS, IDOR, SSRF.
API安全测试的专业技能和方法论
JWT and OIDC security testing covering token forgery, algorithm confusion, and claim manipulation
AWS cloud security testing covering IAM misconfigurations, S3 exposure, metadata abuse, and privilege escalation paths
| name | django-security-testing |
| description | Security testing playbook for Django applications covering ORM injection, middleware gaps, auth/session flaws, and template issues |
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
Security testing for Django web applications and Django REST Framework (DRF) APIs. Focus on ORM/raw query misuse, middleware ordering, permission class gaps, and session/auth configuration across views, admin, and channels.
Core Components
urls.py), class-based and function views, middleware stackextra(), RawSQL, annotationsAuthentication
AuthenticationMiddleware, @login_required, DRF permission_classes/admin/), staff/superuser flagsDeployment
DEBUG=True exposure, ALLOWED_HOSTS, SECRET_KEY leakage/admin/ — brute force, credential stuffing, IDOR on admin objectsFileField, ImageField), import/export (django-import-export)filter(), Q objects, or raw SQLFingerprinting
curl -I https://target/ -H "Cookie: sessionid=test"
# X-Frame-Options, Set-Cookie (sessionid, csrftoken), Server header
GET /admin/login/
GET /api/ /api/v1/ /swagger/ /api/schema/
Settings Leakage (when DEBUG=True or misconfigured)
SECRET_KEY, database credentials, installed apps/static/, error pages with stack traces revealing paths and ORM queriesOpenAPI / DRF
GET /api/schema/
GET /swagger.json
Map endpoints, authentication classes, and permission classes per route.
Permission Class Gaps
list protected but retrieve/update missing permission_classes@api_view without explicit permissions inheriting permissive defaultsSession Issues
SESSION_COOKIE_SECURE=False on HTTPS sites; missing HttpOnlySECRET_KEY → forge session cookies (django.contrib.sessions.backends.signed_cookies)JWT (simplejwt)
user_id/token blacklist on logoutORM SQL Injection Vulnerable patterns (more common in legacy code):
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{user_input}'")
User.objects.extra(where=[f"username = '{user_input}'"])
Test: ' OR 1=1 --, time-based payloads, database-specific syntax.
DRF Filter Backends
django-filter with unsafe field exposure: ?username__icontains= on unintended columns?ordering= if field whitelist missingTemplate Injection Django templates auto-escape by default; risk rises with:
mark_safe(user_input)
|safe filter in templates
Template(user_input).render(...) # SSTI if user controls template source
Jinja2 backend without autoescape: {{7*7}}, RCE gadgets if sandbox misconfigured.
@csrf_exempt on state-changing viewsCSRF_USE_SESSIONS, trusted origins misconfiguration)CSRF_TRUSTED_ORIGINS too broadTest: Cross-origin POST with victim session cookie; JSON endpoints with session auth.
DRF Serializers
fields = '__all__' exposing is_staff, is_superuser, role, balanceread_only_fields missing on sensitive ModelSerializer fieldsObject-Level Permissions
get_object() without filtering queryset by request.userqueryset = Model.objects.all() and weak permissionsMEDIA_ROOT served directly in DEBUG or via misconfigured nginxContent-Type that enables XSSrequests.get(user_url) in webhooks, preview, import featuresALLOWED_HOSTS = ['*'] or permissive subdomain patternsHost header → poisoned reset links/admin/ path with weak credentialshas_add_permission / has_change_permission overrides with logic bugsid fields in query and body/api/v1/ vs /api/v2/) with weaker auth on older version7*7 equivalent)queryset.filter(user=request.user) consistently applied including nested routeslist but forget destroy or custom @action routesAPIView subclasses for missing permission_classes — common oversight?format= and browsable API HTML responses for CSRF on session authdjango.contrib.admin uses separate auth — don't assume API auth covers adminStatic analysis is the fastest way to reach the sinks above in white-box scope. The sandbox ships python/pipx, semgrep, bandit, ast-grep, and ripgrep.
mark_safe, extra(), RawSQL, subprocess, weak crypto, hardcoded secrets: bandit -r . -ll.extra(), RawSQL, |safe, csrf_exempt, ALLOWED_HOSTS=['*']): semgrep --config p/django .pipx install pip-audit && pip-audit -r requirements.txtast-grep run -p 'mark_safe($X)' -l pythonFor the SECRET_KEY → signed-cookie/reset-token forgery path noted under Session Issues, Django's own django.core.signing is the "tool": with a leaked key you can mint valid signing.dumps() values (session cookies, password-reset tokens, and PickleSerializer-backed session RCE).
Django's defaults help (CSRF middleware, template auto-escape) but DRF, raw SQL, custom permissions, and deployment settings introduce frequent gaps. Test every endpoint with role-separated principals and verify object-level enforcement on querysets, not just authentication presence.
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
Security testing for Django web applications and Django REST Framework (DRF) APIs. Focus on ORM/raw query misuse, middleware ordering, permission class gaps, and session/auth configuration across views, admin, and channels.
Core Components
urls.py), class-based and function views, middleware stackextra(), RawSQL, annotationsAuthentication
AuthenticationMiddleware, @login_required, DRF permission_classes/admin/), staff/superuser flagsDeployment
DEBUG=True exposure, ALLOWED_HOSTS, SECRET_KEY leakage/admin/ — brute force, credential stuffing, IDOR on admin objectsFileField, ImageField), import/export (django-import-export)filter(), Q objects, or raw SQLFingerprinting
curl -I https://target/ -H "Cookie: sessionid=test"
# X-Frame-Options, Set-Cookie (sessionid, csrftoken), Server header
GET /admin/login/
GET /api/ /api/v1/ /swagger/ /api/schema/
Settings Leakage (when DEBUG=True or misconfigured)
SECRET_KEY, database credentials, installed apps/static/, error pages with stack traces revealing paths and ORM queriesOpenAPI / DRF
GET /api/schema/
GET /swagger.json
Map endpoints, authentication classes, and permission classes per route.
Permission Class Gaps
list protected but retrieve/update missing permission_classes@api_view without explicit permissions inheriting permissive defaultsSession Issues
SESSION_COOKIE_SECURE=False on HTTPS sites; missing HttpOnlySECRET_KEY → forge session cookies (django.contrib.sessions.backends.signed_cookies)JWT (simplejwt)
user_id/token blacklist on logoutORM SQL Injection Vulnerable patterns (more common in legacy code):
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{user_input}'")
User.objects.extra(where=[f"username = '{user_input}'"])
Test: ' OR 1=1 --, time-based payloads, database-specific syntax.
DRF Filter Backends
django-filter with unsafe field exposure: ?username__icontains= on unintended columns?ordering= if field whitelist missingTemplate Injection Django templates auto-escape by default; risk rises with:
mark_safe(user_input)
|safe filter in templates
Template(user_input).render(...) # SSTI if user controls template source
Jinja2 backend without autoescape: {{7*7}}, RCE gadgets if sandbox misconfigured.
@csrf_exempt on state-changing viewsCSRF_USE_SESSIONS, trusted origins misconfiguration)CSRF_TRUSTED_ORIGINS too broadTest: Cross-origin POST with victim session cookie; JSON endpoints with session auth.
DRF Serializers
fields = '__all__' exposing is_staff, is_superuser, role, balanceread_only_fields missing on sensitive ModelSerializer fieldsObject-Level Permissions
get_object() without filtering queryset by request.userqueryset = Model.objects.all() and weak permissionsMEDIA_ROOT served directly in DEBUG or via misconfigured nginxContent-Type that enables XSSrequests.get(user_url) in webhooks, preview, import featuresALLOWED_HOSTS = ['*'] or permissive subdomain patternsHost header → poisoned reset links/admin/ path with weak credentialshas_add_permission / has_change_permission overrides with logic bugsid fields in query and body/api/v1/ vs /api/v2/) with weaker auth on older version7*7 equivalent)queryset.filter(user=request.user) consistently applied including nested routeslist but forget destroy or custom @action routesAPIView subclasses for missing permission_classes — common oversight?format= and browsable API HTML responses for CSRF on session authdjango.contrib.admin uses separate auth — don't assume API auth covers adminStatic analysis is the fastest way to reach the sinks above in white-box scope. The sandbox ships python/pipx, semgrep, bandit, ast-grep, and ripgrep.
mark_safe, extra(), RawSQL, subprocess, weak crypto, hardcoded secrets: bandit -r . -ll.extra(), RawSQL, |safe, csrf_exempt, ALLOWED_HOSTS=['*']): semgrep --config p/django .pipx install pip-audit && pip-audit -r requirements.txtast-grep run -p 'mark_safe($X)' -l pythonFor the SECRET_KEY → signed-cookie/reset-token forgery path noted under Session Issues, Django's own django.core.signing is the "tool": with a leaked key you can mint valid signing.dumps() values (session cookies, password-reset tokens, and PickleSerializer-backed session RCE).
Django's defaults help (CSRF middleware, template auto-escape) but DRF, raw SQL, custom permissions, and deployment settings introduce frequent gaps. Test every endpoint with role-separated principals and verify object-level enforcement on querysets, not just authentication presence.
record_vulnerability when running inside the penkit51 platformrecord_vulnerability when running inside the penkit51 platform