feat: add CSRF protection middleware

[deacon-mp]

Summary

• Adds csrf_protect_middleware_factory to app/api/v2/security.py that protects all state-modifying HTTP methods (POST/PUT/PATCH/DELETE) against CSRF attacks for session-authenticated users
• Safe methods (GET/HEAD/OPTIONS) and API-key-authenticated requests are exempt from CSRF checks
• On successful login, a per-session csrf_token is generated and stored in the server-side session; the token is also exposed as a readable XSRF-TOKEN cookie so client-side JavaScript can read it for double-submit validation
• Cookie security hardened in auth_svc.py: EncryptedCookieStorage now sets secure=True, httponly=True, max_age=86400, and samesite='Strict'
• Middleware wired into app/api/v2/__init__.py after authentication middleware

Notes

• The base_world fixture in tests/api/v2/test_security.py does not yet include the apply_hash=True parameter added to master in hash passwords and API keys in main config #3257 — a minor rebase/fixup will be needed before this merges
• Test file includes a TODO comment acknowledging that the API key skip check should use a valid API key (not just any KEY header) — tracked for follow-up

Test plan

• Review CSRF middleware logic in app/api/v2/security.py
• Run pytest tests/api/v2/test_security.py after rebasing onto current master (to pick up apply_hash=True fixture change)
• Verify that POST requests without X-CSRF-Token header return 403 for session-authenticated users
• Verify that POST requests with a valid X-CSRF-Token header return 200
• Verify that API-key-authenticated requests bypass CSRF checks
• Confirm cookie attributes (secure, httponly, samesite=Strict) are set correctly

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
22305803	Triggered	Generic Password	83ffce0	tests/api/v2/test_security.py	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[fionamccrae]

Want to remove plugins and conf from this PR - not relevant to changes

[Copilot]

Pull request overview

Adds CSRF protection for the API v2 layer, generating a per-session CSRF token on login and enforcing token validation for unsafe HTTP methods while exempting safe methods and API-key-authenticated requests.

Changes:

• Introduces csrf_protect_middleware_factory and wires it into the API v2 middleware stack.
• Hardens session cookie settings in AuthService and sets an XSRF-TOKEN cookie on successful login.
• Adds/updates tests covering CSRF enforcement and cookie-forwarding behavior in aiohttp test clients.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
tests/api/v2/test_security.py	Updates session-cookie auth tests to handle Secure cookies in the test client.
tests/api/v2/test_csrf_operations.py	Adds new CSRF behavior tests and some timing-based checks.
app/service/auth_svc.py	Hardens session cookie config and sets a CSRF token + XSRF-TOKEN cookie on login.
app/api/v2/security.py	Adds CSRF protection middleware for unsafe methods.
app/api/v2/init.py	Wires CSRF middleware into the API v2 app and adjusts upload max size parsing.

Comments suppressed due to low confidence (1)

app/api/v2/init.py:18

• max_size parsing/validation is duplicated twice back-to-back. This is redundant and makes future changes error-prone; remove the duplicate block and keep a single source of truth for the upload limit fallback behavior.

    try:
        max_size = int(upload_max_size_mb)
        max_size = max_size if max_size > 0 else 100
    except (TypeError, ValueError):
        max_size = 100

    try:
        max_size = int(upload_max_size_mb)
        max_size = max_size if max_size > 0 else 100
    except (TypeError, ValueError):
        max_size = 100

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

File has a syntax error: iimport pytest should be import pytest. As-is, the test module will fail to import and the entire test run will error out.

Suggested change

	iimport pytest
	import pytest

[Copilot]

api_v2_client_with_csrf mutates global BaseWorld config (apply_config on main/payloads/agents) but never restores/clears it. This can leak configuration into later tests and cause order-dependent failures; please add cleanup (e.g., BaseWorld.clear_config() in a finally/teardown) or reuse the existing base_world fixture pattern that yields and clears.

[Copilot]

The login handler in this fixture is marked @authentication_exempt, and the CSRF middleware also skips exempt handlers, so the login POST should consistently return the redirect (302). Allowing 200/403 here makes the test less strict and can mask regressions; assert the expected status and that the session cookie/token are present before testing CSRF behavior on /private.

Suggested change

	# The login POST may be denied by CSRF middleware unless we explicitly forward
	# the session cookie returned by the server (EncryptedCookieStorage uses secure=True).
	assert login_response.status in (200, 302, 403)
	# Forward session cookie explicitly when making subsequent requests
	cookies = dict(login_response.cookies)
	# The login handler is authentication-exempt, so CSRF middleware should not block it.
	# A successful login should consistently return a redirect.
	assert login_response.status == 302
	# Forward session cookie explicitly when making subsequent requests
	cookies = dict(login_response.cookies)
	# Ensure a session cookie/token was actually issued as part of login
	assert cookies

[Copilot]

Same issue as above: because /login is authentication-exempt and CSRF middleware skips exempt handlers, this login request should deterministically succeed (302). If login fails, the subsequent assertion post_resp.status == 200 becomes misleading; please assert login success and required cookies first.

[Copilot]

This test can pass an empty CSRF header when XSRF-TOKEN is missing (headers={}) but still asserts a 200. Since the CSRF token is required for unsafe session-authenticated requests, the test should assert token_cookie is present (and non-empty) and always send the header; otherwise a missing cookie would yield a false-positive or confusing failure mode.

Suggested change

	token = token_cookie.value if token_cookie is not None else None
	# Forward session cookie explicitly when making subsequent requests and include token
	post_resp = await client.post('/private', cookies=cookies, headers={'X-CSRF-Token': token} if token else {})
	assert token_cookie is not None
	token = token_cookie.value
	assert token
	# Forward session cookie explicitly when making subsequent requests and include token
	post_resp = await client.post('/private', cookies=cookies, headers={'X-CSRF-Token': token})

[Copilot]

These timing-based assertions (abs(mean_valid - mean_invalid) < 0.05) are likely to be flaky across CI runners and under load, since they measure end-to-end request latency rather than just the comparison routine. Consider removing this test, marking it as a non-default/slow benchmark, or testing constant-time behavior at the function level (e.g., unit test compare_digest usage) instead of wall-clock network timing.

Suggested change

	count = 25
	mean_valid = await _measure_request_mean(client, 'get', '/private', count=count, headers={HEADER_API_KEY: 'abc123'})
	mean_invalid = await _measure_request_mean(client, 'get', '/private', count=count, headers={HEADER_API_KEY: 'INVALID_KEY'})
	assert abs(mean_valid - mean_invalid) < 0.05
	# Check that a valid API key grants access
	valid_resp = await client.get('/private', headers={HEADER_API_KEY: 'abc123'})
	assert valid_resp.status == 200
	# Check that an invalid API key is rejected
	invalid_resp = await client.get('/private', headers={HEADER_API_KEY: 'INVALID_KEY'})
	assert invalid_resp.status in (401, 403)

[Copilot]

Same concern here: this test uses end-to-end request timing and a hard-coded 50ms threshold, which is inherently noisy/flaky and can fail due to unrelated system variance. Prefer a deterministic unit test of constant-time comparison usage (or move this to an optional benchmark suite) to avoid destabilizing CI.

Suggested change

	client = TestClient(TestServer(csrf_webapp))
	await client.start_server()
	try:
	login_response = await client.post('/login', data={'username': 'admin', 'password': 'admin'}, allow_redirects=False)
	# Login may redirect (302) on success; accept either 200 or 302
	assert login_response.status in (200, 302)
	token_cookie = login_response.cookies.get('XSRF-TOKEN')
	assert token_cookie is not None
	token = token_cookie.value
	count = 25
	mean_valid = await _measure_request_mean(client, 'post', '/private', count=count, headers={'X-CSRF-Token': token})
	mean_invalid = await _measure_request_mean(client, 'post', '/private', count=count, headers={'X-CSRF-Token': token + 'x'})
	assert abs(mean_valid - mean_invalid) < 0.05
	finally:
	await client.close()
	"""
	Ensure that CSRF protection relies on a constant-time comparison helper
	rather than observable request-level timing differences.
	"""
	constant_time_compare = getattr(security, 'constant_time_compare', None)
	assert callable(constant_time_compare)
	@pytest.mark.asyncio
	async def test_csrf_prevents_cross_site_operation_creation(api_v2_client_with_csrf):
	client = api_v2_client_with_csrf
	enter_resp = await client.post('/enter', data={'username': 'admin', 'password': 'admin'}, allow_redirects=False)
	assert enter_resp.status in (200, 302)
	cookies = enter_resp.cookies
	payload = {
	'adversary': {'adversary_id': '123', 'name': 'ad-hoc'},
	'source': {'id': '123'}
	}
	resp = await client.post('/api/v2/operations', cookies=cookies, json=payload)
	assert resp.status == 403
	xsrf_cookie = enter_resp.cookies.get('XSRF-TOKEN')
	if xsrf_cookie:
	token = xsrf_cookie.value
	resp2 = await client.post('/api/v2/operations', cookies=cookies, json=payload, headers={'X-CSRF-Token': token})
	assert resp2.status != 403

[Copilot]

CSRF checks are skipped whenever a KEY header is present, even if the API key is invalid. For a session-authenticated request, an attacker could add any KEY header value and bypass CSRF validation. Use auth_svc.request_has_valid_api_key(request) (and ideally only skip when API-key auth is the actual auth mechanism) rather than checking header presence.

[Copilot]

The XSRF-TOKEN cookie is set without max_age while the session cookie now has max_age=86400. This can leave users with a still-valid session but no readable CSRF cookie after a browser restart, causing all unsafe requests to fail until re-login. Also, deriving secure from request.scheme can be wrong behind TLS-terminating proxies; consider setting secure=True consistently (or using a trusted proxy/proto config) and align max_age/path with the session cookie.

Suggested change

	secure_flag = (request.scheme == 'https') if hasattr(request, 'scheme') else False
	response.set_cookie('XSRF-TOKEN', session['csrf_token'], httponly=False, secure=secure_flag, samesite='Lax')
	# Align cookie attributes (max_age, path, secure) with the session cookie settings.
	response.set_cookie(
	'XSRF-TOKEN',
	session['csrf_token'],
	max_age=86400,
	path='/',
	httponly=False,
	secure=True,
	samesite='Lax',
	)