You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by as...@apache.org on 2026/04/21 23:14:22 UTC
(tooling-agents) branch main updated: ASVS L3 audit: 10.4.15 (authentication_and_session)
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 37a4e14 ASVS L3 audit: 10.4.15 (authentication_and_session)
37a4e14 is described below
commit 37a4e1496bc68359667be2bc5b6f594ae973eba8
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Wed Apr 22 01:14:17 2026 +0200
ASVS L3 audit: 10.4.15 (authentication_and_session)
---
.../d0aa7e9/authentication_and_session/10.4.15.md | 274 +++++++++++++++++++++
1 file changed, 274 insertions(+)
diff --git a/repos/apache/ASVS/reports/steve/v3/d0aa7e9/authentication_and_session/10.4.15.md b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/authentication_and_session/10.4.15.md
new file mode 100644
index 0000000..7855efd
--- /dev/null
+++ b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/authentication_and_session/10.4.15.md
@@ -0,0 +1,274 @@
+# ASVS 10.4.15 Security Audit Report
+
+## Executive Summary
+
+**Repository:** apache/steve
+**Audit Date:** Apr 21, 2026
+**Auditor:** Tooling Agents
+**ASVS Requirement:** 10.4.15 — Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR).
+**Level:** 3
+**Section:** OAuth Authorization Server
+
+**Files Analyzed:** 3 relevant out of 3 total, 0 skipped
+
+**Finding Counts:**
+
+| Severity | Count |
+|----------|-------|
+| Critical | 0 |
+| High | 0 |
+| Medium | 1 |
+| Low | 0 |
+| **Total** | **1** |
+
+**Summary:** This application is a server-side OAuth client that delegates authentication to an external authorization server (`oauth.apache.org`). The OAuth integration uses simple browser-redirect-based authorization requests without PAR or JAR, meaning the authorization server cannot verify the integrity of authorization request parameters for this client. While current implementation appears secure for basic OAuth flows, it does not meet ASVS 10.4.15 Level 3 requirements for protecti [...]
+
+---
+
+## Security Controls Inventory
+
+| Control | Defined Location | Applied At | Coverage |
+|---------|-----------------|------------|----------|
+| OAuth URL Template | `main.py:38-42` | `asfquart` framework (callback handling not visible) | Partial — no PAR/JAR |
+| Authentication Decorator | `asfquart.auth.require` | Most endpoints in `pages.py` | Good coverage |
+| Session Management | `asfquart.session.read()` | `pages.py:basic_info()` | Framework-handled |
+| OAuth State Parameter | `main.py:39` (URL template `state=%s`) | Presumably `asfquart.generics` | Framework-handled, not auditable from this code |
+
+---
+
+## Critical File Review
+
+### `v3/server/main.py` — OAuth Configuration
+
+| Line(s) | Content | ASVS 10.4.15 Relevance |
+|----------|---------|------------------------|
+| 38-39 | `OAUTH_URL_INIT` template with `state=%s&redirect_uri=%s` | Authorization parameters pass through browser — no PAR/JAR |
+| 42 | `OAUTH_URL_CALLBACK` template with `code=%s` | Token exchange URL — callback handling not visible |
+| 44 | `asfquart.construct('steve', ...)` | OAuth handling delegated to framework — implementation not auditable |
+
+### `v3/server/pages.py` — Endpoint Authentication
+
+| Endpoint | Auth Requirement | OAuth Role Context |
+|----------|-----------------|-------------------|
+| `POST /do-vote/<eid>` | `R.committer` | User authenticated via OAuth — session from framework |
+| `POST /do-create-election` | `R.pmc_member` | Higher privilege — relies on OAuth-provided identity claims |
+| `GET /do-open/<eid>` | `R.committer` | State-changing via GET — separate concern from 10.4.15 |
+
+---
+
+## Findings
+
+### Medium Severity
+
+#### ASVS-10415-MED-001: Server-Side OAuth Client Does Not Use PAR or JAR for Authorization Requests
+
+**Severity:** MEDIUM
+
+**Location:**
+- **File:** `v3/server/main.py`
+- **Lines:** 38–42
+- **Function:** `create_app()`
+
+**Related Functions Checked:**
+- `asfquart.generics.OAUTH_URL_INIT` (configuration)
+- `asfquart.generics.OAUTH_URL_CALLBACK` (configuration)
+- OAuth flow implementation in `asfquart` framework (not visible in audit scope)
+
+**Description:**
+
+This application is a **server-side client** (runs on the ASF server, not on end-user devices). The OAuth authorization flow uses a simple redirect pattern where all authorization parameters are passed through the user's browser as URL query parameters. ASVS 10.4.15 requires that for server-side clients, the authorization server must be able to ensure that authorization request parameters (particularly `authorization_details`) originate from the client backend without user tampering, typ [...]
+
+The current implementation does not use either PAR (RFC 9126) or JAR (RFC 9101), meaning:
+- All authorization parameters travel through the browser without integrity protection
+- The authorization server cannot cryptographically verify parameter origin
+- Users could potentially intercept and modify authorization request parameters
+- If `authorization_details` (RFC 9396) were added for fine-grained authorization, they would be vulnerable to tampering
+
+**Vulnerable Code:**
+
+```python
+# v3/server/main.py, lines 38-42
+asfquart.generics.OAUTH_URL_INIT = (
+ 'https://oauth.apache.org/auth?state=%s&redirect_uri=%s'
+)
+asfquart.generics.OAUTH_URL_CALLBACK = 'https://oauth.apache.org/token?code=%s'
+```
+
+**Data Flow:**
+
+```
+1. Client Backend (main.py)
+ ↓ [builds URL with parameters]
+2. HTTP Redirect to Browser
+ ↓ [state=%s&redirect_uri=%s in URL]
+3. User's Browser
+ ↓ [user can intercept/modify here]
+4. Authorization Server (oauth.apache.org)
+ ↓ [cannot verify parameter integrity]
+```
+
+**Missing Control:** No PAR or JAR mechanism to ensure authorization request parameters are transmitted directly from client backend to authorization server with integrity protection.
+
+**Proof of Concept:**
+
+An authenticated user could intercept the redirect to `oauth.apache.org` using browser developer tools or a proxy and modify query parameters:
+
+```http
+# Original redirect URL constructed by server:
+https://oauth.apache.org/auth?state=abc123&redirect_uri=https://steve.apache.org/callback
+
+# User-modified URL (redirect_uri changed):
+https://oauth.apache.org/auth?state=abc123&redirect_uri=https://attacker.example.com/steal
+
+# If authorization_details were added in the future:
+# Original:
+https://oauth.apache.org/auth?state=abc123&redirect_uri=...&authorization_details={"type":"election_admin","actions":["manage","tally"]}
+
+# User-modified:
+https://oauth.apache.org/auth?state=abc123&redirect_uri=...&authorization_details={"type":"election_admin","actions":["manage","tally","delete_all"]}
+```
+
+**Impact:**
+
+- **Integrity Risk:** The authorization server cannot distinguish between authorization parameters originating from the client backend vs. those modified by the user during the browser redirect
+- **Future Risk:** If fine-grained authorization requests (`authorization_details`) are introduced for election management features, they would be vulnerable to user tampering
+- **Current Exposure:** Even current OAuth flow parameters (`redirect_uri`, `state`) are exposed to manipulation in transit through the browser, though AS-side validation should mitigate most risks
+- **Compliance:** Does not meet ASVS 10.4.15 Level 3 requirements for server-side clients
+
+**Remediation:**
+
+**Option 1: Implement Pushed Authorization Requests (PAR) per RFC 9126:**
+
+```python
+# main.py - Updated OAuth configuration with PAR support
+import httpx
+
+# PAR endpoint for the authorization server
+OAUTH_PAR_ENDPOINT = 'https://oauth.apache.org/par'
+
+async def initiate_authorization(state, redirect_uri, client_id, client_secret):
+ """Push authorization request directly to AS, get request_uri."""
+ async with httpx.AsyncClient() as client:
+ par_response = await client.post(
+ OAUTH_PAR_ENDPOINT,
+ data={
+ 'client_id': client_id,
+ 'client_secret': client_secret,
+ 'state': state,
+ 'redirect_uri': redirect_uri,
+ 'response_type': 'code',
+ # authorization_details would go here if needed
+ },
+ # Or use mTLS client authentication
+ )
+ par_data = par_response.json()
+ request_uri = par_data['request_uri']
+
+ # Only the opaque request_uri goes through the browser
+ return f'https://oauth.apache.org/auth?client_id={client_id}&request_uri={request_uri}'
+```
+
+**Option 2: Implement JAR (RFC 9101) by signing authorization request parameters:**
+
+```python
+import jwt
+
+def build_jar_request(params, client_private_key, client_id):
+ """Build a JWT-Secured Authorization Request."""
+ signed_request = jwt.encode(
+ {**params, 'iss': client_id, 'aud': 'https://oauth.apache.org'},
+ client_private_key,
+ algorithm='RS256',
+ )
+ return f'https://oauth.apache.org/auth?client_id={client_id}&request={signed_request}'
+```
+
+**Prerequisites:**
+- Coordinate with Apache Infrastructure team to confirm `oauth.apache.org` supports PAR or JAR
+- Obtain client credentials or signing keys as appropriate
+- Update `asfquart` framework to support the chosen mechanism
+
+---
+
+## Positive Security Patterns
+
+1. **HTTPS for OAuth URLs**: Both `OAUTH_URL_INIT` and `OAUTH_URL_CALLBACK` use `https://` scheme, protecting parameters in transit from network-level attackers.
+
+2. **State Parameter Usage**: The `OAUTH_URL_INIT` template includes `state=%s`, indicating CSRF protection is at least structurally present in the OAuth flow (implementation in `asfquart` framework).
+
+3. **Server-side Token Exchange**: The `OAUTH_URL_CALLBACK` pattern (`token?code=%s`) suggests the authorization code is exchanged server-to-server, not in the browser, which is correct for a confidential client.
+
+4. **Role-based Access Control**: The `asfquart.auth.require` decorator with `R.committer` and `R.pmc_member` requirements shows differentiated authorization levels derived from OAuth-provided identity.
+
+5. **Secure LDAP**: `asf-load-ldap.py` uses `ldaps://` (LDAP over TLS) for the connection to the directory server, protecting credential transmission.
+
+6. **Framework-based OAuth**: Delegating OAuth implementation to the `asfquart` framework reduces the risk of custom implementation errors, assuming the framework follows OAuth security best practices.
+
+---
+
+## Architecture Observations
+
+1. **OAuth Client, Not Authorization Server**: This application is an OAuth relying party/client, not an authorization server. The AS is the external `oauth.apache.org`. ASVS 10.4.15 describes AS responsibilities, but the client's architecture determines whether the AS *can* enforce those requirements.
+
+2. **Framework Abstraction**: The actual OAuth flow implementation (redirect construction, callback handling, state validation, token exchange) is encapsulated in the `asfquart` framework, which is not included in the source files under review. A complete audit would require examining `asfquart.generics` and the OAuth callback handler.
+
+3. **Simple OAuth Flow**: The URL template pattern (`state=%s&redirect_uri=%s`) suggests a basic OAuth 2.0 Authorization Code flow without advanced security features (PAR, JAR, PKCE not visible in configuration).
+
+4. **Trust Boundary**: The browser redirect between client and AS is the critical trust boundary for this requirement. All authorization request parameters currently cross this boundary without cryptographic integrity protection from the client.
+
+5. **External Authorization Server**: Remediation depends on capabilities of the external AS (`oauth.apache.org`). Implementation requires coordination with Apache Infrastructure team.
+
+---
+
+## Recommendations Summary
+
+### Immediate Actions
+
+1. **Coordinate with Apache Infrastructure** to determine if `oauth.apache.org` supports PAR (RFC 9126) or JAR (RFC 9101) endpoints
+2. **Document current OAuth flow security controls** implemented in the `asfquart` framework (state validation, redirect_uri validation, PKCE)
+3. **Assess whether `authorization_details`** (RFC 9396) is planned for future use in election management authorization
+
+### Short-term Actions (1-3 months)
+
+1. **Audit `asfquart` framework** OAuth implementation for compliance with OAuth 2.0 Security Best Current Practice (BCP 212)
+2. **Implement PAR** (RFC 9126) if supported by `oauth.apache.org`, ensuring all authorization parameters are transmitted backend-to-backend
+3. **Update OAuth configuration** in `main.py` to use PAR or JAR mechanisms once AS support is confirmed
+
+### Long-term Actions (3-6 months)
+
+1. **Implement JAR** (RFC 9101) as fallback if PAR is not available, providing cryptographic integrity for authorization requests
+2. **Document OAuth security architecture** including trust boundaries, parameter validation points, and security controls
+3. **Establish security review process** for any future additions of `authorization_details` or other authorization parameters
+
+---
+
+## Appendix: Files Analyzed
+
+<details>
+<summary>Click to expand file list (3 files)</summary>
+
+### Relevant Files (3)
+
+1. **`v3/server/bin/asf-load-ldap.py`** (relevance: 10/10)
+ - LDAP integration for user directory
+ - Uses secure `ldaps://` protocol
+
+2. **`v3/server/main.py`** (relevance: 10/10)
+ - OAuth URL configuration (lines 38-42)
+ - Application initialization
+ - Critical for ASVS 10.4.15 assessment
+
+3. **`v3/server/pages.py`** (relevance: 10/10)
+ - Endpoint definitions with OAuth-based authentication
+ - Role-based access control using OAuth identity
+ - Session management
+
+### Skipped Files (0)
+
+None
+
+</details>
+
+---
+
+**End of Report**
\ 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