php-thinkphp-audit

PHP ThinkPHP framework security audit (php-thinkphp-audit)

Analyze the "framework feature security mechanisms" and typical pitfall patterns in ThinkPHP project source code, with key coverage of:

• Authentication/access control (auth module, controller/middleware gate)
• CSRF token mechanism and skip paths
• The ThinkPHP template engine's automatic escaping and raw output risks
• Mass Assignment caused by the ORM/Model layer write chain (allowField/scenario validation)
• Native database expressions/raw SQL injection entry points (mapped to the general SQL risk category)
• debug/exception output and security configuration switches (mapped to CFG)

Input

User provides:

• source_path: ThinkPHP project root directory Optional:
• output_path: output directory path (default {source_path}_audit）

Output directory

Output to:

{output_path}/framework_audit/
  thinkphp_{timestamp}.md

Framework identification (required)

Evidence points must be given to prove it is identified as ThinkPHP:

• Dependency evidence:composer.json contains topthink/think-* or thinkphp/think-* related dependency
• Entry evidence:public/index.php or an equivalent front-end entry point
• Configuration evidence:config/ The directory contains ThinkPHP configuration files (such as app.php、database.php、middleware.php , etc., according to the actual project)
• Runtime directory evidence:runtime/ directory structure (if present)

Risk type mapping (required)

Each finding must clearly state:

• General type code:AUTH / CSRF / XSS / TPL / LOGIC / CFG / SESS / SQL , etc. (choose from your unified type codes)
• Mapping reason: why it falls under that type code (explain the mapping logic in one sentence)

Required audit checklist (required: check item by item and output results)

1) Authentication and access control (AUTH)

Must locate and output:

• Authentication entry points: controller middleware/filters, base class Controller/Behavior, route-layer permission middleware
• auth module usage: whether ThinkPHP's auth-related capabilities are used (such as Auth/RBAC/role permission check functions or equivalent wrappers)
• Parameter sources for permission checks: where the resource ID/user ID comes from (route parameter/request body/session), and whether ownership checks are performed

Decision rules:

• If "only login state is checked but resource ownership/role subdivision is missing" is found, output an AUTH risk
• If "permission checks are missing in some branches/bypassed after an exception" is found, output an AUTH or LOGIC risk

2) CSRF protection (CSRF)

Must locate and output:

• Where the CSRF token is enabled: configuration item/middleware/form generation logic
• Token receiving field: which field from body/header (according to the actual project)
• Token validation logic: validation function/middleware entry point and failure handling (whether it returns/throws and blocks state changes)
• Skip rules: which routes, which request methods, or which scenarios skip CSRF validation

Decision rules:

• If skip rules exist but cover state-changing interfaces => CSRF risk
• Token validation fails but business logic still executes (e.g., exception is swallowed) => CSRF risk

3) Template engine escaping and raw output (XSS/TPL)

Must locate and output:

• Template auto-escaping strategy: whether template syntax escapes by default, whether it is globally disabled
• Raw output/skip-escaping syntax: for example, presence of raw/|raw or equivalent mechanism in templates (according to the project's actual template engine version and usage)
• User input entering template variables: where the variables come from (request/session/db), and whether they are directly concatenated into HTML/JS/attribute contexts

Decision rules:

• If a raw output variable is controllable and unescaped => map to XSS or TPL (if it involves an expression/execution chain)

4) ORM write path (LOGIC: Mass Assignment)

Must locate and output:

• Input acquisition: whether request->param() / request->all() / $this->request->post() / equivalent structure is passed as a whole into model writes
• Model write points:Model::create/save/update、$model->save($data), batch assignment behavior
• Allowed field policy: whether allowField/field/ scenario or an equivalent whitelist mechanism is configured

Decision rules:

• Input written as a whole and the model lacks sensitive-field deny/allow constraints => LOGIC risk
• An allowed-field whitelist exists but still includes high-risk fields => LOGIC risk

5) Database native expression/raw SQL risks (SQL)

Must locate and output:

• Raw SQL entry points:Db::query($sql)、Db::execute($sql)、whereRaw、orderRaw、buildExpression , etc. (according to the project's actual usage)
• Evidence of user input entering native expressions: concatenation, template replacement, string assembly points
• Whether parameterization/binding strategies exist:->bind/placeholder/prepare , etc. (according to the project's actual usage)

Decision rules:

• User input entering a raw SQL expression via string concatenation => SQL risk

6) Security configuration and debug exposure (CFG/SESS)

Must locate and output:

• debug/exception output:app_debug、trace, error page output strategy, log level (according to the project's actual usage)
• cookie/session security parameters: if the project configuration file is visible (HttpOnly/Secure/SameSite, etc.), output the SESS/CFG risk mapping

Decision rules:

• Production debug enabled/stack trace echoed => CFG risk

Observable PoC (mandatory: framework-specific observable verification framework)

Provide at least one of the following two categories and clearly state the observation points:

• AUTH: Use a low-privilege user to request a suspected protected action, and observe whether access succeeds / whether business side effects occur
• CSRF: Construct a request to a state-changing route with a missing or incorrect CSRF token, and observe whether blocking is returned and whether the business logic still executes

PoC output requirements:

• Must include the real route/controller action (extracted from your route mapping or code entry evidence)
• Must include the token field name/fields required for validation (output according to the project's actual field names)
• Must explain the observation points (HTTP status code, response content characteristics, whether business side effects occur)

Output completeness check (mandatory)

• Output includes: ThinkPHP identification evidence + six major block check results: AUTH/CSRF/template output/ORM write/database native entry/debug configuration
• Each risk has: mapping type code + location evidence + observable verification framework + remediation suggestions