fix(analysis): reduce taint false positives

Tighten receiver and setter-style taint propagation to cut noisy sink matches while preserving the JDBC dbtest flow. Reclassify DriverManager connection sinks as JDBC_Driver_RCE and align the architecture and roadmap docs with the current detection policy.

Author: wuerror

ARCHITECTURE.md

@@ -119,14 +119,30 @@ The tool supports two modes to balance precision and performance:
     *   *Reference*: *Lhoták, O., & Hendren, L. (2003). Scaling Java points-to analysis using Spark.*
 
 #### C. Taint Analysis (Vulnerability Detection)
-The engine implements a **Forward Taint Propagation** algorithm.
-1.  **Source Identification**: Based on `api.txt` and `rules.yaml`, mark return values of sources (e.g., `request.getParameter()`) as "Tainted".
-2.  **Propagation**: 
-    *   **Intra-procedural**: Use Soot's `SmartLocalDefs` or `FlowAnalysis` to track taint within a method body via assignments (`y = x` where x is tainted).
-    *   **Inter-procedural**: When a tainted variable is passed as an argument to a method call, query the Call Graph to find callee methods and map the argument to the callee's parameters, continuing the analysis recursively.
-3.  **Sink Matching**: If a tainted variable reaches a sink method (e.g., `Runtime.exec(tainted)`), a vulnerability is flagged.
-
-*Reference*: *Vallée-Rai, R., Co, P., Gagnon, E., Hendren, L., Lam, P., & Sundaresan, V. (1999). Soot - a Java optimization framework.*
+The engine implements a **Forward Taint Propagation** algorithm combining intra- and inter-procedural analysis.
+
+1.  **Source Identification**: Based on `api.txt` and `rules.yaml`, all parameters of API entry-point methods are marked as "Tainted" at method entry.
+2.  **Intra-procedural Propagation** (`IntraTaintAnalysis` — `ForwardBranchedFlowAnalysis<FlowSet<Value>>`):
+    *   **Direct assignment**: `y = x` → `y` tainted if `x` tainted.
+    *   **Binary/cast**: `y = x + z`, `y = (T) x` → `y` tainted if operand tainted.
+    *   **Instance field read**: `y = obj.f` → `y` tainted if `obj` tainted.
+    *   **Static field read**: `y = Cls.f` → `y` tainted if `Cls.f` was previously written with tainted data (tracked in `taintedStaticFields`).
+    *   **Array read**: `y = arr[i]` → `y` tainted if `arr` tainted.
+    *   **Instance field write**: `obj.f = x` → `obj` tainted if `x` tainted.
+    *   **Static field write**: `Cls.f = x` → `Cls.f` added to `taintedStaticFields` if `x` tainted.
+    *   **Method return (instance)**: `y = obj.m(...)` → `y` tainted if `obj` tainted; `arg → return` is additionally applied only to setter-like instance methods to reduce taint explosion.
+    *   **Method return (static/any)**: `y = Cls.m(...)` → `y` tainted if any arg tainted.
+    *   **Setter/constructor receiver**: `obj.set(x)` or `new Obj(x)` → `obj` tainted if any arg tainted, but this receiver-tainting heuristic is restricted to setter-like methods and constructors. This enables the `setter → field → getter → sink` chain without broadly tainting service objects.
+    *   **Path sensitivity**: Null-check branches (`if x == null`) kill taint on the null path.
+3.  **Inter-procedural Propagation** (`WorklistEngine`):
+    *   Tainted arguments are mapped to callee parameter locals before scheduling.
+    *   Tainted receiver (`obj` in `obj.m(...)`) is mapped to callee `this` local.
+    *   `AnalysisState` (method + tainted-param-bitset + `thisTainted`) is used for memoization to avoid redundant re-analysis.
+4.  **Sink Matching**: A vulnerability is flagged when:
+    *   Any **argument** of a sink method call is tainted, OR
+    *   The **receiver** of an instance sink call is tainted for sink categories that enable receiver-based triggering. This receiver-based check is intentionally disabled for `sqli` to avoid false positives on tainted `Statement` / `Connection` objects.
+
+*Reference*: *Vallée-Rai et al. (1999). Soot - a Java optimization framework.*
 
 ### 3.3 Internal Process Flows
 

CHANGELOG.md

@@ -2,6 +2,52 @@
 
 All notable changes to this project will be documented in this file.
 
+## [1.6.1] - 2026-03-09
+
+### Changed
+- **JDBC Sink Taxonomy**:
+  - Reclassified `java.sql.DriverManager.getConnection(...)` from generic `SSRF` to `JDBC_Driver_RCE` in `default_rules.yaml`.
+  - Scoring now treats `jdbc_driver_rce` as a critical category; exploitability remains a human-triage decision based on actual driver and URL semantics.
+
+### Fixed
+- **False Positive: Taint Explosion via Broad Setter Tainting**:
+  - `IntraTaintAnalysis.flowThrough`: Receiver tainting for `InvokeStmt` is now restricted to **setter-like methods** (`set*`, `add*`, `put*`, `append*`, `insert*`, `with*`, `push*`, `enqueue*`, `load*`, `init*`, `configure*`, `update*`, `register*`) and constructors. Previously, ANY `InstanceInvokeExpr` with a tainted argument would taint the receiver, causing taint to explode through service-layer objects (repositories, HTTP clients, APM agents) and generate hundreds of false positives.
+- **False Positive: `URL.<init>` / `URI.<init>` as SSRF Sinks**:
+  - Removed `<java.net.URL: void <init>(java.lang.String)>` and `<java.net.URI: void <init>(java.lang.String)>` from SSRF sinks in `default_rules.yaml`. Object construction alone does not make a network request; the real sinks (`URL.openStream()`, `URL.openConnection()`) are retained.
+- **False Positive: `ObjectMapper.readValue(String, Class)` as Deserialization Sink**:
+  - Removed `<com.fasterxml.jackson.databind.ObjectMapper: java.lang.Object readValue(java.lang.String,java.lang.Class)>` from deserialization sinks. Jackson's `readValue` with an explicit target class is standard safe JSON parsing, not arbitrary deserialization. Dangerous Jackson deserialization requires `enableDefaultTyping()` + polymorphic type handling, which is not modeled by this sink.
+- **False Positive: Overly Broad Instance-Method Return Value Taint**:
+  - `IntraTaintAnalysis.applyDefinition`: For `InstanceInvokeExpr` (instance method calls whose return value is assigned), `arg tainted → return tainted` is now restricted to **setter-like methods** (same `isSetterLike()` predicate as the receiver-tainting rule). General pass-through instance calls are handled correctly by the inter-procedural scheduler (callee is analyzed with tainted params). The `receiver tainted → return tainted` rule (for getters and chain calls) is unchanged.
+  - Static invocations (`StaticInvokeExpr`) retain full `arg → return` propagation, which is correct for transformation functions (`String.format`, `Paths.get`, etc.).
+- **False Positive: Receiver-Tainted Sink Check for SQL Injection**:
+  - `WorklistEngine.checkSink()` and `InterproceduralTaintAnalysis`: Receiver-based sink triggering (`taintedObj.sinkMethod()`) is now **disabled for the `sqli` category**. SQLi requires a tainted SQL string argument; triggering on a tainted `Statement` or `Connection` receiver generates false positives from taint reaching database objects via field propagation. SSRF, Path_Traversal, RCE, and other categories retain receiver-based detection.
+
+## [1.6.0] - 2026-03-09
+
+### Added
+- **Field Taint Propagation (Phase 8.5)**:
+  - `IntraTaintAnalysis.flowThrough`: Any `InstanceInvokeExpr` (virtual, interface, or special/constructor) with a tainted argument now taints the receiver object. This covers the common setter pattern: `obj.setUrl(tainted)` propagates taint onto `obj` so that subsequent reads (`obj.getUrl()`, `obj.field`) stay tainted through the rest of the method.
+  - `IntraTaintAnalysis`: Added `taintedStaticFields: Set<SootField>` to track writes of the form `SomeClass.field = tainted`. Subsequent reads `x = SomeClass.field` within the same method body are now correctly tainted. The set is monotone (only grows) consistent with MAY-analysis semantics.
+  - `WorklistEngine.checkSink` + `InterproceduralTaintAnalysis`: Sink detection now also fires when the **receiver** of an instance-method sink is tainted (e.g., `taintedStmt.execute()`), in addition to the existing argument check. This closes a class of false negatives for builder/fluent API sink patterns.
+
+### Fixed
+- **False Negatives: Interprocedural Receiver Taint (Phase 8.5 pre-work, commit `1ca012a`)**:
+  - `AnalysisState`: Added `thisTainted` boolean to the memoization key (`equals`/`hashCode`). Previously, a method entered with a tainted receiver and without a tainted receiver mapped to the same state; the second visit was silently skipped, dropping real flows.
+  - `WorklistEngine.scheduleCallee` + `InterproceduralTaintAnalysis`: When an `InstanceInvokeExpr` base object is tainted, the callee's `this` local is now seeded as tainted before scheduling. This enables `source → obj (tainted) → callee(this tainted) → sink` chains.
+  - `IntraTaintAnalysis.applyDefinition`: Constructor calls (`SpecialInvokeExpr.isConstructor()`) with tainted arguments now taint the base object (previously missed, leaving `new Obj(tainted)` chains broken).
+  - `IntraTaintAnalysis.applyDefinition`: Static method calls (`StaticInvokeExpr`) with tainted arguments now taint the return-value local, covering `x = Utils.process(tainted)` chains that were previously dropped.
+- **False Negatives: Missing JDBC URL / Connection Sinks (Phase 8.4, commit `1ca012a`)**:
+  - Added `java.sql.DriverManager.getConnection(String)`, `getConnection(String, Properties)`, and `getConnection(String, String, String)` as SSRF/JDBC-URL-Injection sinks in `default_rules.yaml`.
+- **Config Merge (commit `1ca012a`)**:
+  - `ConfigManager`: When a workspace `rules.yaml` exists, its source/sink rules are now **merged** with the bundled defaults instead of replacing them. Rules present in the workspace file take precedence; rules only in defaults are appended. This prevents sink/source coverage regressions when users customize their rule files.
+- **Graph Stability (commits `b9fc2ef`, `6e8f79b`, `ef8bc48`)**:
+  - Auto-resolve dangling Soot classes during call-graph construction to reduce phantom-class noise.
+  - Bulk resolution pass for recurring dangling packages.
+  - Tightened retry budget for dangling resolution to avoid runaway retries.
+- **JAX-RS Route Extraction**:
+  - `RouteExtractor`: POJO parameters annotated with JAX-RS path/query annotations are now correctly captured in `api.txt`.
+  - Added support for `@Path`, `@GET/@POST/@PUT/@DELETE/@PATCH` on JAX-RS controllers.
+
 ## [1.5.0] - 2026-02-10
 
 ### Added

README.md

@@ -25,6 +25,7 @@
     *   **Worklist Engine**: 迭代式污点分析，避免栈溢出。
     *   **Leaf Optimization**: 智能摘要生成，大幅提升分析速度。
     *   **Strict Isolation**: 严格隔离业务代码与第三方库，防止分析引擎崩溃。
+    *   **Field-Sensitive Propagation**: 支持字段污点传播，覆盖 `setter → field → getter → sink`、`new Obj(tainted)` 和静态字段读写链路；receiver 型 sink 检测按漏洞类别启用，默认不会仅因 tainted `Statement/Connection` 就报 SQLi。
 
 ---
 
@@ -81,6 +82,8 @@ java -jar JByteScanner-1.0-SNAPSHOT.jar -m api --filter-annotation AnonymousVali
 
 对于sink,直接修改生成的rules.yaml。第二次跑，或者再跑全量时会首先加载当前项目目录.jbytescanner下的rules.yaml。也可以通过`-c`选项指定
 
+默认规则里，SSRF 更聚焦真正发起外连的通用 URL/HTTP API，例如 `openConnection`、`openStream`、HTTP client `execute(...)`；而 `DriverManager.getConnection(...)` 会单独归类为 `JDBC_Driver_RCE`，具体是否可利用交由人工判断。`new URL(...)` / `new URI(...)` 这类仅构造对象的调用默认不作为高置信 SSRF sink。
+
 **全量扫描 (漏洞挖掘):**
 
 -m scan或者什么都不带。如果.jbytescanner目录下已经有api.txt那么会跳过phase2
@@ -111,14 +114,19 @@ java -jar target/JByteScanner-1.0-SNAPSHOT-shaded.jar /path/to/app.jar --interac
 - [x] **Phase 1-5**: 基础架构、配置管理、资产发现、Soot 集成、SARIF 报告。
 - [x] **Phase 6**: 性能优化（结构化状态、反向剪枝、强依赖隔离）。
 - [x] **Phase 7**: 高级分析引擎（Worklist 迭代引擎、方法摘要、叶子节点优化）。
-- [x] **Phase 8: 战术情报 (Tactical Intelligence)**: Secret 扫描、漏洞评分、Smart PoC 生成。
+- [x] **Phase 8: 战术情报 (Tactical Intelligence)**:
+  - [x] 8.1 Secret 扫描（配置文件、常量池、Base64 编码）。
+  - [x] 8.2 漏洞评分（R-S-A-C 模型）与认证检测。
+  - [x] 8.3 Smart PoC 生成（Burp Suite 可直接导入）。
+  - [x] 8.4 Sink 覆盖扩展（JDBC URL / DriverManager.getConnection）。
+  - [x] 8.5 字段污点传播（setter 模式、静态字段、sink receiver 检测）。
 
 ### 进行中 (Advanced Exploitation)
+- [ ] **Phase 8.6**: Summary 完善（`param→this`、`this→return` 摘要生成与消费）。
 - [ ] **Phase 9: 深度利用链**
   - [ ] **Auth Bypass**: 鉴权绕过检测（Config vs Code）。
   - [ ] **Gadget Miner**: 反序列化利用链挖掘。
 
 - [ ] **Phase 10: 交互与 SCA**
   - [ ] **Offensive SCA**: 攻击型组件指纹识别。
   - [ ] **Interactive Shell**: 内存调用图查询 REPL。
-

ROADMAP.md

@@ -46,18 +46,21 @@ This document tracks the evolution of JByteScanner into a specialized Red Team t
 
 ### Current Known Gaps
 - [ ] **False Negative: JDBC URL / Connection Sinks**:
-  - Case study: `GET /setup/dbtest` in the Qiyuesuo target is reachable from `com.qiyuesuo.setup.SetupController.dbtest(...)` to `java.sql.DriverManager.getConnection(...)`, but the engine reports 0 findings.
+  - Case study: `GET /setup/dbtest` in a target application is reachable from `com.example.setup.SetupController.dbtest(...)` to `java.sql.DriverManager.getConnection(...)`, but the engine reports 0 findings.
   - Root cause 1: `default_rules.yaml` models SQL execution sinks such as `Statement.execute*` and `JdbcTemplate.execute/query`, but does not model JDBC connection-establishment sinks such as `DriverManager.getConnection(...)` or URL-setting APIs on common `DataSource` implementations.
   - Root cause 2: the current worklist engine only propagates taint through callee parameters and does not propagate taint into instance receivers (`this`), constructors, object fields, or return values, so flows like `param -> field -> this.method() -> sink` are dropped.
   - Root cause 3: method summaries define placeholders for `paramsToThis` and `thisToReturn`, but the summary generator and worklist engine do not yet produce and consume these facts.
 
 ### Planned Fix Plan
-- [ ] **8.4 Sink Coverage Expansion**:
+- [x] **8.4 Sink Coverage Expansion** [COMPLETED]:
   - Add JDBC URL / connection sinks to `default_rules.yaml`, starting with `java.sql.DriverManager.getConnection(...)` and common `DataSource` URL setters.
-  - Revisit sink taxonomy so JDBC URL control can be scored as SSRF / JDBC URL injection / connection abuse instead of being limited to SQL execution only.
-- [ ] **8.5 Receiver/Object Taint Propagation**:
-  - Extend `WorklistEngine.scheduleCallee()` to propagate tainted instance receivers into callee `this` for `InstanceInvokeExpr`.
-  - Add constructor and field-backed object flow support for chains like `source -> new Obj(tainted) -> this.field -> sink`.
+  - Revisit sink taxonomy so JDBC URL control is reported as `JDBC_Driver_RCE`, with exploitability left to analyst validation rather than downgraded into generic SSRF.
+  - Keep SSRF focused on connection-establishing APIs such as `openConnection()`, HTTP client `execute(...)`, `openStream()`, and JDBC `DriverManager.getConnection(...)`; `URL(String)` / `URI(String)` constructors are intentionally not treated as high-confidence SSRF sinks because they create excessive noise.
+- [x] **8.5 Receiver/Object Taint Propagation** [COMPLETED]:
+  - `IntraTaintAnalysis.flowThrough`: tainted arg to any `InstanceInvokeExpr` (setter/constructor) now taints the receiver (`obj.setUrl(t)` → `obj` tainted).
+  - `IntraTaintAnalysis.applyDefinition`: added `StaticFieldRef` read/write tracking via `taintedStaticFields` (`StaticClass.f = t` → field remembered; `x = StaticClass.f` → `x` tainted).
+  - `WorklistEngine.checkSink` + `InterproceduralTaintAnalysis`: sink check can fire when the receiver itself is tainted, but this receiver-based trigger is now disabled for `sqli` sinks to avoid false positives on tainted `Statement` / `Connection` objects.
+  - Covers chains: `param → setter(param) → obj tainted → obj.get() → sink` and `param → static field → read → sink`.
 - [ ] **8.6 Summary Completion**:
   - Implement `param -> this`, `this -> return`, and return-value propagation in `SummaryGenerator` and `WorklistEngine`.
   - Upgrade memoization state to capture object/receiver taint facts in addition to tainted parameter indices.