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 19:19:32 UTC
(tooling-agents) branch main updated: ASVS L3 audit: 12.3.2 (tls_and_transport_security)
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 06a4dd5 ASVS L3 audit: 12.3.2 (tls_and_transport_security)
06a4dd5 is described below
commit 06a4dd5e73a0616a894f7332a863d91f889be48e
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue Apr 21 21:19:27 2026 +0200
ASVS L3 audit: 12.3.2 (tls_and_transport_security)
---
.../d0aa7e9/tls_and_transport_security/12.3.2.md | 257 +++++++++++++++++++++
1 file changed, 257 insertions(+)
diff --git a/repos/apache/ASVS/reports/steve/v3/d0aa7e9/tls_and_transport_security/12.3.2.md b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/tls_and_transport_security/12.3.2.md
new file mode 100644
index 0000000..d9f9ef8
--- /dev/null
+++ b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/tls_and_transport_security/12.3.2.md
@@ -0,0 +1,257 @@
+# ASVS 12.3.2 Security Audit Report
+
+## Executive Summary
+
+- **Repository:** apache/steve
+- **Audit Date:** Apr 21, 2026
+- **Auditor:** Tooling Agents
+- **ASVS Requirement:** 12.3.2 — Verify that TLS clients validate certificates received before communicating with a TLS server.
+ - **Level:** 2
+ - **Section:** General Service to Service Communication Security
+ - **Section Description:** Server communications (both internal and external) involve more than just HTTP. Connections to and from other systems must also be secure, ideally using TLS.
+ - **Chapter:** Secure Communication
+ - **Control Objective:** This chapter includes requirements related to the specific mechanisms that should be in place to protect data in transit, both between an end-user client and a backend service, as well as between internal and backend services.
+- **Files Analyzed:** 2 relevant out of 2 total, 0 skipped
+
+### Finding Summary
+
+| Severity | Count |
+|----------|-------|
+| Critical | 0 |
+| High | 0 |
+| Medium | 2 |
+| Low | 0 |
+| **Total** | **2** |
+
+### Audit Scope
+
+This audit examines the application's behavior when it acts as a **TLS client** making outbound connections. The primary outbound TLS connections are OAuth token exchanges with `oauth.apache.org`. The audit identified that no explicit TLS certificate validation configuration exists for these outbound connections, relying entirely on implicit library defaults.
+
+---
+
+## Security Controls Inventory
+
+| Control | Defined | Location | Applied To | Coverage |
+|---------|---------|----------|------------|----------|
+| Server TLS (certfile/keyfile) | Yes | `main.py:76-78`, `config.yaml.example:11-12` | Inbound connections (server mode) | Partial (optional) |
+| OAuth HTTPS URLs | Yes | `main.py:38-41` | Outbound OAuth connections | URLs are HTTPS |
+| SSL Context for outbound connections | **Not Found** | N/A | N/A | **NONE** |
+| CA bundle / trust store config | **Not Found** | N/A | N/A | **NONE** |
+| TLS version enforcement (client-side) | **Not Found** | N/A | N/A | **NONE** |
+| Certificate pinning for OAuth | **Not Found** | N/A | N/A | **NONE** |
+
+---
+
+## Critical File Review
+
+### `main.py` — TLS Client Operations
+
+| Line(s) | Operation | TLS Client Validation | Status |
+|----------|-----------|----------------------|--------|
+| 38-39 | OAuth Auth URL (redirect, browser-initiated) | N/A (browser handles) | OK |
+| 41 | OAuth Token URL (server-to-server HTTPS) | No explicit validation | ⚠️ MEDIUM |
+| 76-78 | Server TLS cert loading | N/A (server-side) | Informational |
+
+### `config.yaml.example` — TLS Configuration
+
+| Setting | Value | Security Implication |
+|---------|-------|---------------------|
+| `server.certfile` | `localhost.apache.org+3.pem` | Development cert (mkcert); example only |
+| `server.keyfile` | `localhost.apache.org+3-key.pem` | Development key; example only |
+| TLS optional | "leave blank for plain HTTP" | No enforcement of TLS in config |
+| Client CA bundle | Not configurable | No trust store control |
+
+---
+
+## Findings
+
+### Medium Severity
+
+#### ASVS-1232-MED-001: No Explicit TLS Certificate Validation for OAuth Token Exchange
+
+**Severity:** MEDIUM
+**Gap Type:** Type A — Entry point with NO explicit control
+**File:** `v3/server/main.py`
+**Function:** `create_app()`
+**Lines:** 38–41
+
+**Description:**
+
+The application makes outbound HTTPS requests to `oauth.apache.org` for authentication token exchange. While the configured URLs correctly use the `https://` scheme, there is no explicit SSL context creation, certificate verification enforcement, or CA trust store configuration anywhere in the application code. The application delegates all TLS client behavior to the `asfquart` framework with no verification that certificate validation is active.
+
+**Vulnerable Code:**
+
+```python
+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:**
+
+```
+User completes OAuth login → Application receives auth code →
+Application acts as TLS CLIENT to oauth.apache.org:443 →
+NO explicit ssl_context with verify_mode=CERT_REQUIRED →
+Relies on implicit library defaults for certificate validation →
+Receives OAuth token (authentication credential)
+```
+
+**What's Missing:**
+
+No code in the audited files creates an `ssl.SSLContext` with `verify_mode = ssl.CERT_REQUIRED`, configures a CA bundle path, or passes a `verify=True` / `ssl` parameter to the HTTP client making the outbound OAuth request. If the underlying `asfquart` or its HTTP client library were ever configured (or defaulted) to skip verification, the application would silently accept fraudulent certificates, enabling man-in-the-middle attacks on the OAuth token exchange.
+
+**Proof of Concept:**
+
+An attacker performing a network-level MITM (e.g., DNS poisoning or ARP spoofing on the same network segment) could present a self-signed certificate for `oauth.apache.org`. Without explicit certificate validation enforcement, if the underlying library has verification disabled or improperly configured, the application would:
+
+1. Accept the fraudulent certificate
+2. Send the OAuth authorization code to the attacker's server
+3. The attacker could exchange the code for a valid token or harvest credentials
+
+**Impact:**
+
+If certificate validation is not enforced by the underlying library, an attacker could intercept OAuth token exchanges, hijack authentication sessions, and impersonate legitimate voters in the election system.
+
+**Remediation:**
+
+Create and pass an explicit SSL context for all outbound connections:
+
+```python
+import ssl
+
+def create_oauth_ssl_context():
+ """Create a strict SSL context for outbound OAuth connections."""
+ ctx = ssl.create_default_context() # Loads system CA certificates
+ ctx.minimum_version = ssl.TLSVersion.TLSv1_2
+ ctx.verify_mode = ssl.CERT_REQUIRED
+ ctx.check_hostname = True
+ return ctx
+
+# In create_app() or asfquart configuration:
+oauth_ssl_context = create_oauth_ssl_context()
+# Pass to HTTP client used for OAuth token exchange, e.g.:
+# async with aiohttp.ClientSession() as session:
+# async with session.get(url, ssl=oauth_ssl_context) as resp:
+```
+
+Additionally, configure the `asfquart` framework to accept and use an explicit SSL context for its OAuth HTTP client operations.
+
+---
+
+#### ASVS-1232-MED-002: No Explicit SSL Context for Server-Side TLS Configuration
+
+**Severity:** MEDIUM
+**Gap Type:** Type A — No control present
+**File:** `v3/server/main.py`
+**Function:** `run_standalone()`
+**Lines:** 76–78
+
+**Description:**
+
+The server-side TLS configuration passes raw `certfile` and `keyfile` paths directly to `app.runx()` without constructing an `ssl.SSLContext`. This means there is no enforcement of minimum TLS protocol version, cipher suite selection, or other security parameters for inbound connections. While this is server-side TLS rather than client certificate validation, the pattern demonstrates the broader absence of explicit TLS configuration discipline, which extends to the client-side finding above.
+
+**Vulnerable Code:**
+
+```python
+kwargs = {}
+if app.cfg.server.certfile:
+ kwargs['certfile'] = CERTS_DIR / app.cfg.server.certfile
+ kwargs['keyfile'] = CERTS_DIR / app.cfg.server.keyfile
+ extra_files.update((kwargs['certfile'], kwargs['keyfile']))
+
+# Spool up the app!
+app.runx(port=app.cfg.server.port, extra_files=extra_files, **kwargs)
+```
+
+**What's Missing:**
+
+No `ssl.SSLContext` is created with protocol version restrictions (`minimum_version = TLSv1_2`), cipher suite configuration, or client certificate verification settings. The underlying framework decides all TLS parameters.
+
+**Impact:**
+
+Without explicit SSL context configuration, the server may accept deprecated TLS versions (TLS 1.0, 1.1) or weak cipher suites depending on the framework and Python version defaults. This contributes to a pattern where TLS security is entirely implicit rather than explicitly enforced.
+
+**Remediation:**
+
+```python
+import ssl
+
+def create_server_ssl_context(certfile, keyfile):
+ ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
+ ctx.minimum_version = ssl.TLSVersion.TLSv1_2
+ ctx.load_cert_chain(certfile=certfile, keyfile=keyfile)
+ # Optionally restrict cipher suites
+ ctx.set_ciphers('ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20')
+ return ctx
+
+# In run_standalone():
+if app.cfg.server.certfile:
+ certpath = CERTS_DIR / app.cfg.server.certfile
+ keypath = CERTS_DIR / app.cfg.server.keyfile
+ ssl_ctx = create_server_ssl_context(certpath, keypath)
+ kwargs['ssl'] = ssl_ctx
+```
+
+---
+
+## Positive Security Patterns
+
+1. **HTTPS OAuth URLs**: Both OAuth endpoints are hardcoded to `https://`, preventing accidental use of plain HTTP for authentication flows.
+2. **TLS Support Built-in**: The server does support TLS configuration through certificate/key files, showing awareness of transport security.
+3. **Certificate Path Resolution**: Certificate files are resolved relative to a `certs/` subdirectory, providing organized key material storage.
+4. **Static Folder Disabled**: `static_folder=None` reduces attack surface.
+
+---
+
+## Architecture Observations
+
+1. **Framework Delegation**: The application heavily delegates TLS handling to the `asfquart` framework. The audited code contains no direct HTTP client calls — the actual OAuth HTTP request implementation is within the framework. A complete audit requires reviewing `asfquart`'s HTTP client configuration.
+
+2. **Two Deployment Modes**: The application supports standalone (`app.runx()`) and ASGI (Hypercorn) modes. In ASGI mode, TLS is configured entirely through Hypercorn's external configuration, meaning the application code has zero control over TLS parameters.
+
+3. **No LDAP Code Visible**: The domain context mentions LDAP connections, but no LDAP client code is present in the audited files. If LDAP is used elsewhere, those connections must also validate TLS certificates (LDAPS).
+
+4. **Single External Dependency**: The only outbound TLS connection visible is to `oauth.apache.org`. This is a high-value target for MITM since it handles authentication.
+
+---
+
+## Recommendations Summary
+
+### Immediate Actions (Priority 1)
+
+| Priority | Action | Finding | Effort |
+|----------|--------|---------|--------|
+| 1 | Create explicit `ssl.SSLContext` with `CERT_REQUIRED` and `check_hostname=True` for OAuth outbound requests | ASVS-1232-MED-001 | Low |
+| 2 | Create explicit server-side `ssl.SSLContext` with TLS 1.2+ minimum and strong cipher suites | ASVS-1232-MED-002 | Low |
+
+### Short-term Actions (Priority 2-3)
+
+| Priority | Action | Finding | Effort |
+|----------|--------|---------|--------|
+| 3 | Add configuration option for CA bundle path for outbound connections | Both findings | Low |
+| 4 | Audit `asfquart` framework's HTTP client to confirm default certificate validation behavior | ASVS-1232-MED-001 | Medium |
+
+### Long-term Actions (Priority 4-6)
+
+| Priority | Action | Finding | Effort |
+|----------|--------|---------|--------|
+| 5 | If LDAP is used, verify LDAPS connections validate certificates | Domain Context | Medium |
+| 6 | Consider certificate pinning for the `oauth.apache.org` endpoint | Defense in depth | Medium |
+
+---
+
+## Appendix: Files Analyzed
+
+<details>
+<summary>Click to expand file list (2 files)</summary>
+
+1. `v3/server/config.yaml.example` (relevance: 10)
+2. `v3/server/main.py` (relevance: 10)
+
+</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