php-yii-audit

PHP Yii (Yii2) framework security audit (php-yii-audit)

Analyze the framework mechanisms and configuration pitfalls of Yii2 projects, focusing on:

• Access control:AccessControl filter、roles rules, use of matchCallback
• RBAC：user->can/can() Authentication completeness of paths
• CSRF：enableCsrfValidation and cookie validation
• Output encoding: whether views use Html::encode、HtmlPurifier, as well as dangerous raw output
• URL and redirection: whether redirect/Url generation is controlled by trusted input
• Input parameter filtering:rules()、safeAttributes(), whether scenarios (scenario) lead to Mass Assignment

Input

User-provided:

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

Output directory

Output to:

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

Framework identification (required)

Evidence points for identifying Yii must be provided (no unsubstantiated assertions allowed):

• Dependency evidence:composer.json contains yiisoft/yii2 or related components
• Entry evidence:web/index.php or yii entry script
• Application directory:controllers/、models/、views/

Risk type mapping (required)

Every finding must state:

• General type code:AUTH / CSRF / XSS / CFG / LOGIC , etc.
• Mapping reason

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

1) Correctness of AccessControl authentication rules (AUTH)

Must locate and output:

• behaviors() in AccessControl configuration:rules、roles、matchCallback and action coverage
• Whether there is a loose mode that relies only on matchCallback
• Whether there is custom authentication logic that does not fall into a unified filter

Decision rules:

• If there is a path that can bypass AccessControl or rules are too broad, output an AUTH risk

2) Completeness of RBAC/permission checks (AUTH/LOGIC)

Must locate and output:

• The controller/service layer's user->can({value})、can() or equivalent permission check
• Object ownership check: whether owner_id/user_id or the resource ownership relationship is also verified

Decision rules:

• If only "the user has the permission type" is checked, but object ownership is not verified, output an AUTH or LOGIC risk

3) CSRF（CSRF）

Must locate and output:

• enableCsrfValidation and cookie validation settings
• Token receiving field and handling method on validation failure (whether it returns early)

4) Output encoding and XSS (XSS)

Must locate and output:

• Whether raw output exists in views:Html::encode cases where it is bypassed, or use of raw type mechanisms
• Whether user input is directly concatenated into HTML attributes/JS/URL in templates

5) Input filtering and Mass Assignment (LOGIC)

Must locate and output:

• Model rules()、safeAttributes()、scenarios() configuration
• Whether there is load($request->post()) followed by direct saving, while sensitive fields are not prohibited

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

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

• AUTH: For suspected protected actions, request with a low-privilege user and observe response differences or business side effects
• CSRF: For suspected protected state-changing POST requests, omit the CSRF token and observe the error and whether execution still succeeds

PoC output requirements:

• Must include the controller/action route and parameter fields
• Must explain the HTTP status code and business result you want to observe

Output completeness check (mandatory)

• Output includes: AccessControl/RBAC/CSRF/output encoding/Input filtering check results
• Each risk includes: mapped type code + location evidence + observable verification framework + remediation recommendations