# Defect Point Analysis Task

## Prerequisites

- Code file to be audited (line number range)

## Analysis Steps

! Strictly follow the steps below for analysis; do not skip steps or truncate the process.
! Reason using a state machine in sequence; do not directly analyze and reach a result.
! Follow best practices for analysis.

### Step1 Load Analysis Rules

Load risk analysis rules based on the code language (required):

  - java: `<SKILL root directory>/threat-explore/limits/java.md`
  - python: `<SKILL root directory>/threat-explore/limits/python.md`
  - go: `<SKILL root directory>/threat-explore/limits/go.md`
  - cpp: `<SKILL root directory>/threat-explore/limits/cpp.md`
  - others: `<SKILL root directory>/threat-explore/limits/default.md`

### Step2 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 buffer overflow sensitive operation
- Line xx, xxxx has a xx configuration defect

#### Sink-Type Sensitive Operations

- SQL Injection: Database execution functions or ORM operation functions (e.g., `cursor.execute`, `Session.execute`, `engine.execute`, `mapper.queryXXX`).
- Command Injection: System call functions (e.g., Python's `os.system`, `subprocess.Popen`; Java's `Runtime.exec`; Go's `exec.Command`).
- Path Traversal: File operation functions (e.g., `open`, `os.open`, `os.path.join`, `java.io.FileInputStream`, `fs.readFile`).
- SSRF: Server-side HTTP request functions (e.g., Python's `requests.get`, `urllib.request.urlopen`; Java's `HttpClient.send`; Go's `http.Get`; Node.js's `axios.get`).
- Deserialization: Deserialization functions or certain deserialization library functions with known CVEs (e.g., Python's `pickle.loads`, `yaml.load`; Java's `ObjectInputStream.readObject`, `XMLDecoder.readObject`, `fastjson.parseObject`, `fastjson.parse`; PHP's `unserialize`).
- Code Injection: Code execution functions (e.g., Python's `eval`, `exec`; Java's `ScriptEngine.eval`, `GroovyShell.evaluate`; PHP's `eval`, `create_function`).
- JNDI Injection: Functions that trigger JNDI lookups (e.g., `InitialContext.lookup`, `InitialDirContext.search`, `JndiTemplate.lookup` for explicit JNDI lookups; and `JdbcRowSetImpl.connect`, `JndiObjectFactoryBean.afterPropertiesSet` for implicit internal JNDI lookup behavior).
- Unsafe Reflection: Functions that construct classes or execute code through reflection (e.g., `Class.newInstance`, `Proxy.newProxyInstance`, `Constructor.newInstance`, `URLClassLoader.newInstance`, `Method.invoke`, etc.).
- Expression Injection: Functions that can execute expressions (e.g., `jakarta.el.ELProcessor.eval`, `ValueExpression.getValue`, and functions encapsulated in EL implementations such as JUEL, Tomcat, etc.).
    - SpEL Expressions: Functions that can execute SpEL expressions (e.g., `org.springframework.expression.Expression.getValue` and other Spring framework-encapsulated SpEL expression execution functions).
    - OGNL Expressions: Functions that can execute OGNL expressions (e.g., `TextParseUtil.translateVariables`, `OgnlTextParser.evaluate`, `Ognl.getValue`, etc.).
- Template Injection: Template rendering functions (e.g., `org.thymeleaf.TemplateEngine.process`, `freemarker.template.Template.process`, `org.apache.velocity.Template.evaluate`, etc.).
- LDAP Injection: Functions that can perform LDAP queries (e.g., `InitialLdapContext.search`, `InitialDirContext.search`, etc.).
- Hardcoded Credentials: Assignment code where literals are used as sensitive credentials, or function calls that use literals as keys/passwords in security validation functions.
- Format String Vulnerability: Format output functions (e.g., C/C++'s `printf`, `sprintf`, `fprintf`, `snprintf`; Python's `%` formatting operator).
- Buffer Overflow: Buffer overflow vulnerabilities do not require calling specific standard library functions. As long as the code has semantic behavior that could lead to out-of-bounds memory writes, it should be considered a vulnerability. If memory operation functions are present (e.g., C/C++'s `memcpy`, `strcpy`, `sprintf`, `wcscpy`, `wcscat`, `gets`, `strcat`, etc.), they must be flagged as buffer overflow vulnerabilities.
- NoSQL Injection: Functions that execute NoSQL queries.
- CSV Injection: Functions that parse CSV content.
- XXE Injection: Functions that parse XML content.

### Step3 Analyze Whether Sensitive Operations Can Be Triggered

Analyze each sensitive operation listed in Step2 one by one.

! 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.
! Sensitive operations with uncertain risk due to exceeding the audit scope should be considered at-risk and analyzed by subsequent tasks.

#### External Input Enumeration

Including but not limited to:

- Function parameters
- Request body
- Environment variables
- File content
- URL Query
- Header
- Form
- Middleware (databases, message queues, caches, etc., which may have second-order injection possibilities)
- ...

#### Analysis Output Rules

* Only identify **predefined vulnerability types**; do not report anything else.
* You must **call the vulnerability trigger point** to report; otherwise, even if validation is insufficient, **do not report**.
* If there is only **possible risk/insufficient validation/no filtering** but **no actual call to a trigger point**, do not report.
* If the **external input** is a constant, do not report.
* A risk sensitive operation is only identified when **external input** affects key parameters.
* Do not use the entire function body or only the function definition line/function signature line as the line number range.

### Step4 Organize the Risky Sensitive Operation List

List the sensitive operations that have risks.

### Step5 Review Check and Summary

Review the **Sensitive Operation List** from Step2, 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?

### Step6 Output Final Report

Based on the Step5 check results, organize and output the report results grouped by external input variables and functions.

Output the identified sensitive operation information in the following format:

```markdown
## Sink-Type Sensitive Operations

### Risky Operation 1: xxx
- Function signature
- External input
- Code file path
- Key operation code snippets (with 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.
- Reporting results
  - Bad practice: Output all sensitive operations.
  - Best practice 1: First perform triggerability analysis; only report triggerable vulnerabilities.
  - Best practice 2: When outputting sensitive operations, merge reports for vulnerabilities with the same external input source within the same function.
- Code analysis
  - Bad practice: Perform cross-file taint tracing context analysis.
  - Best practice: Briefly outline the risk context; if there is risk or uncertain risk, report it, and let subsequent tasks perform complex analysis.
