(tooling-agents) branch main updated: ASVS audit: 10.1.1.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 12619b2  ASVS audit: 10.1.1.md (redacted)
12619b2 is described below

commit 12619b28bf3c5110dfe0b31be173a5f7d15dc5c1
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:00:57 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/10.1.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/10.1.1.md
new file mode 100644
index 0000000..c71bac7
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/10.1.1.md
@@ -0,0 +1,122 @@
+# Security Audit Report: ASVS 10.1.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 10.1.1 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-10.1.1: Token Restriction to Required Components
+
+### Findings for 10.1.1
+
+#### [MEDIUM]
+**Finding ID:** ASVS-1011-MED-001
+
+**File:** `v3/server/pages.py`, function `basic_info()`, lines 58-84
+
+**Observation:** The application uses session-based authentication via `asfquart.session.read()`. Session data containing `uid`, `fullname`, and `email` is passed to EZT templates for rendering. However, the OAuth/OIDC token handling itself is abstracted within the `asfquart` library, which is not provided for review.
+
+```python
+s = await asfquart.session.read()
+if s:
+    basic.update(
+        uid=s['uid'],
+        name=s['fullname'],
+        email=s['email'],
+    )
+```
+
+**Assessment:** The application does NOT appear to expose access tokens or refresh tokens to the browser. The session is read server-side and only user-facing attributes (uid, name, email) are passed to templates. The templates do not reference any OAuth tokens. The backend appears to act as a BFF pattern where token handling is server-side only.
+
+**Potential Gap (Type B):** The `asfquart` session mechanism is not inspectable in this code. If the session cookie itself contains embedded tokens (e.g., JWT session), or if the session store leaks token values, this cannot be verified from the provided code.
+
+**Data flow:** `asfquart.session.read()` → `basic_info()` → template rendering → HTML response to browser
+
+**Impact:** Cannot confirm full compliance without inspecting `asfquart` library internals. However, no token leakage is visible in this codebase.
+
+**Remediation:** Verify that the `asfquart` session mechanism does not expose raw OAuth tokens in cookies or responses. Ensure session cookies are `HttpOnly`, `Secure`, and `SameSite`.
+
+### Security Controls Inventory for 10.1.1
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Server-side session read | `pages.py:68` | ✅ Applied - only extracts user attributes |
+| No token in template variables | All `.ezt` templates | ✅ Applied - no `access_token` or `refresh_token` vars |
+| OAuth token handling | `asfquart` library (external) | ⚠️ Not inspectable |
+| Sensitive query exclusions | `queries.yaml:q_open_to_me`, `q_owned` | ✅ Explicitly exclude `salt` and `opened_key` |
+
+### Positive Patterns for 10.1.1
+
+1. **Server-side only token handling**: The application reads session server-side and only passes display-safe attributes to templates. No access/refresh tokens are visible in frontend code.
+2. **Metadata filtering**: `get_metadata()` in `election.py` (line 144) explicitly excludes `salt` and `opened_key` from returned data.
+3. **Query-level protection**: SQL queries for external-facing data (`q_open_to_me`, `q_owned`, `q_upcoming_to_me`) explicitly select only safe columns, excluding cryptographic secrets.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **OAuth/OIDC Implementation is External**: The actual OAuth/OIDC client implementation (token handling, authorization code flow, PKCE, state parameter) is entirely within the `asfquart` library, which is not provided for review. This limits the ability to fully assess requirements 10.1.1, 10.1.2, 10.2.1, 10.2.2, 10.2.3, and 10.3.1.
+
+2. **Session-Based Architecture**: The application uses a server-side session pattern where OAuth tokens are exchanged for a session. This is architecturally sound for 10.1.1 (tokens stay server-side) but shifts the security burden to session management.
+
+3. **CSRF Protection is Entirely Missing**: The most critical cross-cutting issue is the complete absence of CSRF protection. The placeholder token creates a false sense of security in the codebase. This affects requirements 10.1.2 and 10.2.1 directly.
+
+4. **State-Changing GET Requests**: The `/do-open/<eid>` and `/do-close/<eid>` endpoints perform irreversible operations via GET requests, violating HTTP semantics and creating trivially exploitable CSRF vulnerabilities.
+
+5. **Authorization Gaps**: Multiple `### check authz` placeholder comments indicate that ownership/permission validation is not implemented. Any authenticated committer can manage any election, regardless of ownership. This is a broader security issue that compounds with the CSRF vulnerabilities.
+
+6. **Acknowledged Issues**: The `TODO.md` file demonstrates awareness of the CSRF and authorization issues, indicating these are known technical debt rather than unknown vulnerabilities.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (P0 — Deploy blockers)
+
+1. **Implement real CSRF tokens**: Generate per-session cryptographic tokens using `secrets.token_hex(32)`, store in session, validate on all POST/state-changing endpoints. Estimated effort: 2-4 hours.
+
+2. **Convert GET state-changes to POST**: Change `/do-open/<eid>` and `/do-close/<eid>` from GET to POST, update templates to use form submissions with CSRF tokens. Estimated effort: 1 hour.
+
+3. **Implement ownership authorization**: Add checks that verify the authenticated user owns or has permission to manage an election before allowing open/close/edit/delete operations. Estimated effort: 4-8 hours.
+
+### Short-term (P1 — Next sprint)
+
+4. **Audit `asfquart` library**: Review the `asfquart` library's OAuth implementation to verify:
+   - PKCE or state parameter usage in authorization code flow
+   - Token audience validation
+   - Token storage security (HttpOnly, Secure cookies)
+   - Session fixation protection
+
+5. **Add SameSite cookie attributes**: Ensure session cookies use `SameSite=Lax` or `SameSite=Strict` as an additional CSRF defense layer.
+
+6. **Validate `docname` in `serve_doc()`**: While not OAuth-related, the path traversal risk in document serving should be addressed alongside authentication improvements.
+
+### Long-term (P2 — Architecture improvements)
+
+7. **Consider token-bound sessions**: If the infrastructure supports it, implement sender-constrained tokens (DPoP or mTLS) to prevent token theft/replay.
+
+8. **Implement rate limiting**: Add rate limiting on authentication-dependent endpoints to prevent brute-force attacks on election IDs.
+
+9. **Add security headers**: Implement `Content-Security-Policy`, `X-Content-Type-Options`, `X-Frame-Options` headers to complement the OAuth security posture.
+        
\ 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