# Defect Point Analysis Task

## Task Items

1. **Read through the code** and identify all sensitive operations in a single file that may have defects.
2. Distinguish the triggerability and risk level of sensitive operations.
3. Merge and output the triggerable risky sensitive operation items.

! You must read through the code to complete the audit; do not take shortcuts by only analyzing code matching specific Grep patterns (after Grep locates something, you must review the surrounding context).

## Prerequisites

- Code file to be audited (line number range)

## Predefined Vulnerability Types (only detect the following types)

* `AUTHENTICATION_BYPASS`
* `PRIVILEGE_ESCALATION`
* `UNAUTHORIZED_ACCESS`
* `SESSION_MANAGEMENT_FLAWS`
* `JWT_TOKEN_VULNERABILITY`
* `AUTHORIZATION_LOGIC_BYPASS`
* `INSECURE_DIRECT_OBJECT_REFERENCE`
* `HARD_CODED_CREDENIAL`
* `WEAK_ENCRYPTION_ALGORITHM`
* `USE_OF_INSECURE_RANDOM`
* `SENSITIVE_DATA_EXPOSURE`
* `SMS_LOGIC_FLAW`
* `EMAIL_LOGIC_FLAW`

## Analysis Steps

! Strictly follow the steps below for analysis; do not skip steps or truncate the process.

### Step1 Preliminary Analysis of What Types of Sensitive Operations the Code Involves

Step output: **Sensitive Operation List**
Output example:
- Lines xx-xx, function xx contains a data modification sensitive operation
- Line xx, xxxx has a xx configuration defect

#### Business Logic-Type Sensitive Operations

- Data Modification (HIGH)
    - Identification features: POST/PUT/DELETE
    - Typical examples: Create/Modify/Delete
- Data Access (MEDIUM)
    - Identification features: GET + ID parameter
    - Typical examples: /user/{id}
- Batch Operations (HIGH)
    - Identification features: export/download/batch
    - Typical examples: Export/Batch delete
- Permission Changes (CRITICAL)
    - Identification features: role/permission/grant
    - Typical examples: Role/Permission assignment
- Financial Operations (CRITICAL)
    - Identification features: transfer/pay/refund
    - Typical examples: Transfer/Payment/Refund
- Authentication Operations (CRITICAL)
    - Identification features: login/password/token/jwt/validate
    - Typical examples: Login/Password reset/Token validation
- SMS/Email Operations
    - sms/email
    - Typical examples: Verification code sending/Password reset email
- Verification Code Validation Operations
    - captcha/verification_code/validate
    - Typical examples: Comparing cached and submitted verification codes for consistency

#### Configuration-Type Defects

- Weak Encryption Algorithm: Use of deprecated or weak encryption algorithms (e.g., MD5, SHA1, DES, etc.).
- Insecure Random Number Usage: Use of insecure random number generators.
- Sensitive Data Exposure: Sensitive data logging or storage, PII handling violations, API endpoint data leakage, debug information leakage, etc.; synthetic passwords, credentials, personal information, etc. appearing in log output or error stack traces.

### Step2 Load Rules and Analyze Whether Sensitive Operations Can Be Triggered

Analyze each sensitive operation listed in Step1 one by one, and load the corresponding trigger check rules from `threat-explore/operations` based on the operation type.

Operation-Rule List:

- Authentication operations: `threat-explore/operations/auth.md`
- SMS operations: `threat-explore/operations/sms.md`
- Email operations: `threat-explore/operations/email.md`
- Verification code validation operations: `threat-explore/operations/verification_code.md`
- Others: `threat-explore/operations/default.md` plus business-based triggerability and risk analysis.

! You must load the trigger check rules from `threat-explore/operations` for triggerability analysis.
! If a sensitive operation cannot be triggered or has no risk, it does not need to be reported.
! The analysis scope is limited to the file path being audited. Broader context analysis is handled by other tasks and is not within the scope of this task.

#### External Input Enumeration

Including but not limited to:

- Function parameters
- Request body
- Environment variables
- File content
- URL Query
- Header
- Form
- ...

#### Analysis Output Rules

* Only identify **predefined vulnerability types**; do not report anything else.
* Do not use the entire function body or only the function definition line/function signature line as the line number range.

### Step3 Organize the Risky Sensitive Operation List

List the sensitive operations that have risks.

### Step4 Review Check and Summary

Review the **Sensitive Operation List** from Step1, summarize the risk situation, and complete the following check:

- Check 1: Are there any missed sensitive operation risks that were not output or not analyzed?

### Step5 Output Final Report

Based on the Step4 check results, organize and output the report.

Output the identified sensitive operation information in the following format:

```markdown
## Business Logic-Type Sensitive Operations

### Sensitive Operation 1: xxx
- Code file path
- Key operation code snippets listed (with path + line number range)
- Sensitive operation description + potential impact

## Configuration-Type Defects

### Defect 1: xxx
- Code file path
- Key operation code snippets listed (with path + line number range)
- Sensitive operation description + potential impact
```

## Best Practices

- Code search
  - Bad practice: After Grep finds the sensitive operation code line, analyze directly based on the search content.
  - Best practice: After Grep finds the line, read the surrounding code context and clarify the functional logic.
