free version security vulnerabilities

Here is the security risk analysis of the onboarding changes:

---

1. Authentication Bypass via the Sign-In Endpoint (Critical)

• Vulnerability Location: FreeVersionSignInController.cs
• The Issue: The SignIn endpoint is decorated with [AllowAnonymous]. It accepts the username, dbname, and email parameters directly from the public GET query string and immediately issues an encrypted authentication cookie without validating whether the user successfully passed the OTP verification.
• How it can be exploited: A hacker does not need an OTP. They can simply navigate to: https://<app-domain>/freeversionsignin/signin?username=attacker&dbname=mfg_realclient&email=victim@realclient.com The server will generate a valid login cookie for the mfg_realclient database, letting the hacker log in as an administrator to that tenant.
• Recommended Fix: Do not pass login credentials via open query parameters. Instead, issue a short-lived, encrypted, single-use token upon successful OTP validation on the Blazor server. The sign-in controller should decode and validate this token before writing the authentication cookie.

---

2. Client-Controlled Database Selection (Insecure Direct Object Reference / IDOR)

• Vulnerability Location: LoginDisplay.razor & ApiKeyAuthAttribute.cs
• The Issue: The Blazor frontend stores the active user session data (_PostLogin), including the dbname string, in the browser’s sessionStorage under the key "userinfo". The API routes are authorized using a static, shared ApiKey (ApiKeyAuthAttribute.cs) and query the database name passed in route parameters or headers without verifying user ownership.
• How it can be exploited: A trial user can log in legally as a free tenant, open the Chrome Developer Console (Application -> Session Storage), and manually modify the "dbname" string inside "userinfo" from mfgfree_hacker to an enterprise client’s database name (e.g. mfg_realclient). When they perform actions or refresh the page, the Blazor server reads the modified sessionStorage value and requests data from the enterprise client’s database. Since the backend API does not verify if the user’s email owns that database, it returns the records.
• Recommended Fix: The API backend must independently resolve the tenant database mapping based on the claims (such as email) embedded in the authenticated session identity. It should never trust client-provided database name parameters.

---

3. Database Server Exhaustion (Denial of Service / DoS)

• Vulnerability Location: FreeVersionRepository.cs
• The Issue: Anyone can register a free account. Each registration executes a heavy SQL Server BACKUP and RESTORE operation to provision an isolated database.
• How it can be exploited: A hacker can write a script to register thousands of trial users in parallel. Spawning hundreds of native SQL backup and restore processes simultaneously will consume 100% CPU, storage IOPS, and disk space, causing the database server to crash and taking down all production/enterprise client databases sharing that SQL Server instance.
• Recommended Fix:
  • Add a Captcha (like Google reCAPTCHA) on the registration page to prevent bot sign-ups.
  • Limit registration concurrency and enforce strict IP-based rate limiting on the registration endpoint.
  • Consider a single shared database structure (e.g. using a Tenant ID column) for the free/trial tier rather than spawning native databases.