(tooling-agents) branch main updated: ASVS audit: 1.2.6.md (redacted)

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 092b554  ASVS audit: 1.2.6.md (redacted)
092b554 is described below

commit 092b554775c13a588aec5924d1766e395a237e54
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:00:19 2026 +0200

    ASVS audit: 1.2.6.md (redacted)
---
 ASVS/reports/steve/v3/d0aa7e9/all/1.2.6.md | 81 ++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/1.2.6.md b/ASVS/reports/steve/v3/d0aa7e9/all/1.2.6.md
new file mode 100644
index 0000000..cc4b34a
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/1.2.6.md
@@ -0,0 +1,81 @@
+# Security Audit Report: ASVS 1.2.6
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 1.2.6 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-1.2.6: LDAP Injection Prevention
+
+### Findings for 1.2.6
+
+No findings detected. No LDAP operations are performed in the audited code.
+
+### Security Controls Inventory for 1.2.6
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| No LDAP libraries imported | Entire codebase | N/A — no LDAP operations present |
+
+**Note**: The `authz` field in the `election` table is documented as potentially mapping to "LDAP group identifiers" (`v3/docs/schema.md`), and `v3/schema.sql` comments mention "which PMC" authorization. However:
+- No `python-ldap`, `ldap3`, or similar LDAP library is imported anywhere
+- The `authz` field is stored as TEXT but never used in any LDAP query in the provided code
+- All `### check authz` comments in `pages.py` are unimplemented TODOs
+- Authentication is handled externally via `asfquart.auth` (Apache-specific SSO)
+
+When LDAP integration is eventually implemented for the `authz` field, LDAP injection controls will need to be verified.
+
+### Positive Patterns for 1.2.6
+
+1. **LDAP operations deferred**: The code stores authorization group names but does not yet perform LDAP queries, eliminating current LDAP injection risk.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Strong parameterization discipline**: The architecture cleanly separates query definitions (YAML) from business logic (Python), ensuring all database access goes through parameterized cursors. This is a well-designed pattern that makes SQL injection structurally difficult.
+
+2. **Minimal attack surface for injection types 1.2.5–1.2.8**: The application is a voting system that primarily interacts with SQLite — it does not invoke OS commands, query LDAP directories, parse XML, or generate LaTeX. This minimizes the injection attack surface.
+
+3. **Authorization gaps are documented but unimplemented**: The `### check authz` comments throughout `pages.py` indicate that fine-grained authorization beyond authentication is planned but not yet enforced. While not an injection concern per se, this could allow unauthorized users to modify election data through endpoints that only check `R.committer` rather than election ownership.
+
+4. **CSRF protection is absent**: `basic.csrf_token = 'placeholder'` with no validation in POST endpoints. While not an injection issue per ASVS 1.2.x, it could enable an attacker to cause actions (vote submission, election creation) through social engineering.
+
+5. **Path traversal mitigation via database validation**: The `/docs/<iid>/<docname>` endpoint validates `iid` against the `mayvote` table before serving files. Since valid IIDs are constrained to 10-char hex by schema CHECK constraints, path traversal via `iid` is prevented by the database lookup failing. The `docname` relies on `send_from_directory`'s built-in protection, though an explicit comment `### verify the propriety of DOCNAME` acknowledges this needs hardening.
+
+## Cross-cutting Recommendations
+
+**Immediate (no vulnerabilities found, but strengthen confidence):**
+- None required for injection prevention — the parameterized query pattern is consistently applied.
+
+**Short-term:**
+1. When implementing the `authz` LDAP integration (referenced in schema docs), ensure LDAP queries use parameterized filters or escape special characters (`*`, `(`, `)`, `\`, `NUL`) per RFC 4515.
+2. Add explicit validation for the `docname` parameter in `serve_doc()` (e.g., reject names containing `..`, `/`, or null bytes) as defense-in-depth beyond `send_from_directory`.
+3. Implement CSRF token generation and validation for all state-changing POST endpoints.
+
+**Long-term:**
+1. Consider adding a linting rule or CI check to ensure no raw SQL string construction (e.g., `f"SELECT..."`) is introduced in future commits.
+2. If LaTeX/PDF export features are ever added for election results, ensure `--shell-escape` is disabled and input is sanitized.
+3. If search functionality with user-supplied patterns is ever added, use `re.escape()` on user input before incorporating into regex patterns.
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org