Summary
Investigate whether the Rust libinjection crate can provide broader, better-tested SQL injection detection for cpex-sql-sanitizer than the plugin's current custom regex and character-state heuristics.
This is a time-boxed evaluation with a go/no-go recommendation. It must not assume that every current check should be replaced.
Context
PR #133 introduced the Rust-backed SQL sanitizer from #130. Its current detection path includes:
- configurable regexes for blocked statements;
- custom comment stripping, literal masking, and statement splitting;
- custom checks for
DELETE/UPDATE without WHERE;
- heuristics for likely string interpolation.
These checks address both SQL injection and organization policy. libinjection provides SQLi tokenization/fingerprinting, so it may improve injection coverage, but it may not replace explicit policy checks such as blocking DDL or WHERE-less mutations.
Investigation scope
- Add a minimal prototype that calls
libinjection::sqli from the Rust core, without committing to a production migration.
- Compare the prototype with the current detector using:
- all existing
sql_sanitizer regression tests;
- a representative corpus of SQLi payloads, evasions, comments/encodings, and multiple SQL dialects;
- benign parameterized and non-parameterized SQL to measure false positives;
- multi-statement SQL and quoted/commented edge cases.
- Record false positives, false negatives, and cases where the two detectors disagree.
- Determine how a libinjection detection and fingerprint would map to the existing plugin result/metadata contract without emitting raw SQL or other sensitive input.
- Identify which current checks must remain as separate policy controls even if libinjection is adopted.
- Benchmark detection latency and throughput against the current implementation using the existing Criterion benchmark structure.
- Evaluate supply-chain and build implications:
- the crate wraps the C libinjection implementation and uses build-time bindings;
- compatibility with this repository's pure-Rust plugin requirement;
- Linux/macOS and supported wheel/CI targets;
bindgen/libclang or native-toolchain requirements;- license compatibility, upstream maintenance, release cadence, advisories, and
cargo deny/cargo audit results;
- binary size and packaging impact.
- Review the crate's current docs.rs build failure and determine whether it predicts a build or maintenance risk for CPEX.
Deliverables
- A small prototype or documented build blocker.
- A reproducible comparison corpus and results table.
- A concise decision record recommending one of:
- adopt libinjection as the primary SQLi signal while retaining explicit policy checks;
- use libinjection as an additional signal alongside the current detector;
- do not adopt it, with evidence and a better alternative or follow-up direction.
- Follow-up implementation issue(s) if adoption is recommended.
Acceptance criteria
References
Summary
Investigate whether the Rust
libinjectioncrate can provide broader, better-tested SQL injection detection forcpex-sql-sanitizerthan the plugin's current custom regex and character-state heuristics.This is a time-boxed evaluation with a go/no-go recommendation. It must not assume that every current check should be replaced.
Context
PR #133 introduced the Rust-backed SQL sanitizer from #130. Its current detection path includes:
DELETE/UPDATEwithoutWHERE;These checks address both SQL injection and organization policy.
libinjectionprovides SQLi tokenization/fingerprinting, so it may improve injection coverage, but it may not replace explicit policy checks such as blocking DDL or WHERE-less mutations.Investigation scope
libinjection::sqlifrom the Rust core, without committing to a production migration.sql_sanitizerregression tests;bindgen/libclang or native-toolchain requirements;cargo deny/cargo auditresults;Deliverables
Acceptance criteria
References