(tooling-agents) branch main updated: ASVS audit: 10.5.3.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[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 1df220d  ASVS audit: 10.5.3.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
1df220d is described below

commit 1df220da96a659be95fbc4638acc18ca3d162d2a
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:51:30 2026 +0200

    ASVS audit: 10.5.3.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/10.5.3.md | 112 ++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/10.5.3.md b/ASVS/reports/steve/v3/d0aa7e9/all/10.5.3.md
new file mode 100644
index 0000000..a1ac803
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/10.5.3.md
@@ -0,0 +1,112 @@
+# Security Audit Report: ASVS 10.5.3
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 10.5.3 |
+| **Files Analyzed** | 3 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-10.5.3: Authorization Server Metadata Issuer Validation
+
+### Findings for 10.5.3
+
+### [MEDIUM]
+
+**Finding ID:** ASVS-1053-MED-001
+
+**Title:** No visible issuer URL validation in OIDC client configuration
+
+**File:** `v3/server/pages.py` (entire OIDC client flow)
+
+**Analysis:** The application uses `asfquart` for authentication, which implies an OIDC flow with the Apache Software Foundation's identity provider. However, the provided code contains:
+
+1. No visible configuration of an expected issuer URL
+2. No visible validation of authorization server metadata
+3. No visible comparison of issuer URL from metadata against a pre-configured value
+
+```python
+# The only authentication-related imports/usage visible:
+import asfquart.session
+from asfquart.auth import Requirements as R
+```
+
+**Impact:** If `asfquart` does not validate the issuer URL in the OpenID Provider metadata against a pre-configured expected value, a malicious server could impersonate the legitimate identity provider through metadata manipulation.
+
+**Note:** MEDIUM severity because this is an audit gap — the control may exist in `asfquart` but cannot be verified from the provided code.
+
+**Remediation:** Verify that the `asfquart` library or application configuration:
+1. Pre-configures the expected issuer URL (e.g., `https://oauth.apache.org/`)
+2. When fetching discovery metadata (`.well-known/openid-configuration`), validates that the `issuer` field in the response exactly matches the pre-configured URL
+3. Rejects metadata where the issuer doesn't match
+
+### Security Controls Inventory for 10.5.3
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Issuer URL pre-configuration | Not visible in provided code | **Audit gap** — likely in `asfquart` config |
+| Metadata issuer validation | Not visible in provided code | **Audit gap** — delegated to `asfquart` |
+| Discovery endpoint | Not visible in provided code | **Audit gap** |
+
+### Positive Patterns for 10.5.3
+
+- The application appears to use a single, dedicated identity provider (ASF), reducing the attack surface for issuer impersonation compared to multi-IdP configurations.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Authentication Delegation Pattern**: The entire OIDC client functionality is delegated to the `asfquart` library. While this is architecturally sound (centralized security controls), it means compliance with ASVS 10.5.x requirements cannot be verified from the application code alone. The security posture depends entirely on the correctness of `asfquart`.
+
+2. **Not an OAuth Authorization Server**: This application is purely an OIDC relying party / OAuth client. Requirements 10.4.8 and 10.4.9 are not applicable to this codebase as it does not issue, manage, or revoke tokens.
+
+3. **Single Identity Provider Architecture**: The application appears to use only the ASF identity provider, which simplifies OIDC security (single issuer, single trust relationship) but the lack of visible configuration makes it impossible to verify that issuer pinning is enforced.
+
+4. **Session-Based Security Model**: After initial OIDC authentication, the application operates on server-side sessions rather than tokens. This means token replay/audience attacks are limited to the initial authentication flow (handled by `asfquart`), not to subsequent requests.
+
+5. **Evolving Authentication**: Comments like `### need general solution` on auth decorators suggest the authentication/authorization system is still under development, which increases risk of security gaps.
+
+## Cross-cutting Recommendations
+
+### Immediate
+1. **Audit `asfquart` Library**: The provided code cannot satisfy ASVS 10.5.x verification without examining the `asfquart` library. Conduct a focused audit of `asfquart.auth` and `asfquart.session` for:
+   - Nonce generation and validation (10.5.1)
+   - `sub` claim usage for user identification (10.5.2)
+   - Issuer URL validation (10.5.3)
+   - Audience claim validation (10.5.4)
+
+2. **Document Security Assumptions**: Create explicit documentation stating which OIDC security controls are expected from `asfquart` vs. implemented in the application.
+
+### Short-term
+3. **Add Integration Tests**: Write tests that verify the OIDC flow end-to-end, including:
+   - Rejection of tokens with incorrect nonce
+   - Rejection of tokens with mismatched audience
+   - Rejection of tokens from unauthorized issuers
+   - Proper mapping of `sub` claim to `uid`/`pid`
+
+4. **Configuration Visibility**: Surface the OIDC client configuration (issuer URL, client_id) in the application configuration rather than burying it in the library, making security audits more straightforward.
+
+### Long-term
+5. **Resolve Auth TODOs**: Address all `### need general solution` and `### check authz` placeholders to ensure the authorization model is complete and enforceable.
+
+6. **Consider Multi-IdP Support**: If the application may support multiple identity providers in the future, implement issuer-scoped user identification (`issuer` + `sub` as the unique key) now to prevent account confusion attacks later.
+        
\ 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