Concresca full-root release r5 — diagnostic CSRF repair

Report body

Concresca full-root release r5 — diagnostic CSRF repair

Release: concresca-full-root-20260927-r5
Diagnostic build: concresca-locked-diagnostics-20260927-root-r5

Deploy the complete release, then reopen diagnostics

This is the entire consolidated website/application, based on the r4 full-root release. No partial overlay or earlier repair package is required. Extract into the existing actual website document root. There is no outer project folder and no public/ tree to merge.

Do not empty that directory. Preserve the existing root .htaccess, database, external private environment, hosting Python environment, mutable runtime/ state, and the private .concresca-diagnostics/ directory in the account home. This archive deliberately does not contain or replace those host-specific resources. Use your existing backup/deployment process for the upload.

For this PHP diagnostic fix, no Python activation command is needed. After extraction, open a fresh GET of:

https://concresca.com/concresca-diagnostics.php

Do not use Back/Resubmit to reuse an old POST. The footer should identify concresca-locked-diagnostics-20260927-root-r5. The public, non-secret execution check is:

https://concresca.com/concresca-diagnostics.php?action=ping

Read the current code from account-home/.concresca-diagnostics/access-code.txt, outside the website. Enter it only into the diagnostic page. An existing unexpired code is retained; normal 24-hour expiration still applies. After unlocking, run diagnostics and download the redacted report. Never share the code, cookie, environment file or raw logs.

If access is rejected again, the page now provides a Download access-error report button. This separate report contains only enumerated reasons and boolean presence checks, not the submitted code, tokens, cookies, full host paths, IP addresses or raw request headers. Authenticated AJAX failures also preserve a sanitized access-error result in the downloaded diagnostic report.

What was repaired

The r4 diagnostic page emitted Referrer-Policy: no-referrer. Browsers can therefore send Origin: null on an ordinary HTML form POST. The same page explicitly rejected that origin before examining the access code. A native Apache/PHP HTTPS reproduction of the unmodified r4 file returned HTTP 403 with CSRF_REJECTED despite the correct locally generated access code, matching session cookie, and matching form token. The reproduction client supplied the documented browser header; it was not an automated browser-navigation test.

R5 emits Referrer-Policy: same-origin and an equivalent page-level meta policy. Same-origin forms no longer need to be made compatible by weakening origin checks, while cross-origin referrers remain suppressed. Origin: null, foreign origins, cross-origin fetch metadata and invalid tokens are still rejected. The synchronized session token, HTTPS, secure/HttpOnly/SameSite=Strict cookie, login rate limit, session expiration and code rotation remain enforced.

The cookie explicitly clears its Domain parameter. Without that explicit setting, an inherited PHP cookie domain can invalidate the browser's __Host- cookie requirements. A native test uses an inherited .concresca.com setting and verifies the emitted cookie has no Domain attribute and supports the complete unlock/read/lock flow. This tests a possible configuration hazard, not evidence of your host's actual PHP settings.

Scope and the original readiness failure

This release fixes a demonstrated defect in the diagnostic access path. It does not establish that the live Python dispatcher is active or that autonomous verification is passing. The Python application/verification logic from r4 is retained unchanged. No readiness gate is bypassed and no passing receipt is shipped.

The existing full host activation entry point remains included for your deployment workflow:

python3 concresca-repair/activate.py

Run it only on the hosting server, with the application's existing Python environment. It verifies the full-file manifest, preserves unrelated host configuration, tests live runtime routing, and installs the automatic verifier schedule. It is not required to open the PHP diagnostics, and should not be used as a prerequisite to obtaining the report about a failed Python deployment. --check-only verifies distributed file integrity without host activation or a readiness claim.

Test evidence

See concresca-repair/TEST-RESULTS.md, VALIDATION.json, and CSRF-REPRODUCTION.json. The local regression run includes 259 Python tests (19 are real loopback Apache/PHP HTTPS roundtrips), 46 PHP function assertions, and 86 synthetic JavaScript assertions. Real browser navigation and production Passenger/LiteSpeed/MySQL operation are not established by these results. The final archive is separately extracted and revalidated before delivery.

References

Browser referrer behavior: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
Cookie-prefix requirements: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie
PHP cookie options: https://www.php.net/manual/en/function.session-set-cookie-params.php
CSRF defenses: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html