@7365admin1/core 3.48.1-staging.186 → 3.48.1-staging.187

package/.changeset/user-email-lookup-no-credentials.md

@@ -0,0 +1,52 @@
+---
+"@7365admin1/core": minor
+---
+
+Stop the e-mail account lookup handing out the password hash and session id.
+
+`GET /api/users/user/:email` (`user.route.ts:25`) has no guard on it at all, and
+`GET /api/users/email/:email` next to it is the same handler behind
+`requireAuth`. Both answered `res.json(user)` on the raw stored document, and
+the users collection stores `password` — the hash — and `sid` — that account's
+CURRENT session id.
+
+So anyone at all, with no session, who knew or guessed an e-mail address got
+that account's password hash back in the response body, to crack offline at
+leisure, plus a live session id to reuse. On the authenticated twin, any signed
+in account could read the same two fields for any other account, including an
+administrator's.
+
+The unguarded route cannot simply be guarded. Its only callers anywhere in the
+organisation are pre-login signup screens — the resident app's e-mail check
+(`user-registration.ts:103`) and the four `web-app-main/pages/sign-up-invite/*`
+pages through `layer-common`'s `getUserByEmailV2` — so a session check would
+break registration. The fix is therefore not authentication, it is not handing
+out more than signup asks for.
+
+All five of those callers read NO field off the reply. The mobile check does
+`res !== null`; the four web pages do `if (response)`. So without a session the
+handler no longer loads the document: a new `userExistsByEmail` does a
+`findOne` with an explicit allow-list projection of `_id` alone and returns a
+boolean, and the route answers `{ exists: true }` or `null` exactly as before.
+An allow-list, deliberately — a deny-list would silently start leaking the next
+credential-shaped field somebody adds to the collection.
+
+`getUserByEmail` itself is UNCHANGED and still returns the whole document,
+because signing in genuinely needs the hash to compare against. Putting the
+projection on that function instead of beside it would have broken every login.
+
+With a session the reply keeps its existing shape, minus `password` and `sid`,
+via a small `withoutCredentials`. `_id` is the only field its callers read
+(`web-app-main pages/verify/email`, `web-app-org onboarding/getting-started`)
+and it survives. That path is narrowed by removal rather than by allow-list on
+purpose: it is consumed by screens across web and mobile that cannot all be
+enumerated from here, and removing two credential fields cannot break a
+legitimate one, because no screen renders a password hash or a session id.
+
+The v2 twin `GET /api/users/v2/email/:email` had the same leak — it is behind
+`requireAuth`, so it was never anonymous, but "signed in" is not "entitled to
+another account's credentials" — and is stripped the same way. v2 has no
+anonymous `/user/:email` route and no pre-login caller.
+
+Covered by `test/e2e/user-email-lookup-leak.e2e.test.mjs`, which asserts on the
+absence of the key and never on its value.

package/dist/index.d.ts

@@ -168,6 +168,7 @@ declare function useUserRepo(): {
         pageRange: string;
     }>;
     getUserByEmail: (email: string) => Promise<TUser | null>;
+    userExistsByEmail: (email: string) => Promise<boolean>;
     getUserByReferralCode: (referralCode: string) => Promise<TUser | null>;
     getByEmailApp: (email: string, app: string) => Promise<TUser | null>;
     getUserById: (_id: string | ObjectId) => Promise<TUser & {

package/dist/index.js

@@ -8973,6 +8973,17 @@ function useUserRepo() {
       throw new import_node_server_utils11.InternalServerError("Failed to get user by email.");
     }
   }
+  async function userExistsByEmail(email) {
+    try {
+      const data = await collection.findOne(
+        { email: { $regex: `^${email}$`, $options: "i" } },
+        { projection: { _id: 1 } }
+      );
+      return Boolean(data);
+    } catch (error) {
+      throw new import_node_server_utils11.InternalServerError("Failed to get user by email.");
+    }
+  }
   async function getUserByEmailStatus(email) {
     try {
       const cacheOptions = {
@@ -9624,6 +9635,7 @@ function useUserRepo() {
     getAcceptedTerms,
     listTermsAcceptance,
     getUserByEmail,
+    userExistsByEmail,
     getUserByReferralCode,
     getByEmailApp,
     getUserById,
@@ -18238,11 +18250,20 @@ async function requirePlatformOwner(req) {
   return id;
 }
 
+// src/utils/user-response.util.ts
+function withoutCredentials(user) {
+  if (!user || typeof user !== "object")
+    return user;
+  const { password, sid, ...rest } = user;
+  return rest;
+}
+
 // src/controllers/user.controller.ts
 function useUserController() {
   const {
     getUserById: _getById,
     getUserByEmail: _getByEmail,
+    userExistsByEmail: _existsByEmail,
     getUsers: _getUsers,
     updateBirthday: _updateBirthday,
     updateUserFieldById: _updateUserFieldById,
@@ -18320,8 +18341,13 @@ function useUserController() {
       return;
     }
     try {
+      if (!callerId(req)) {
+        const exists = await _existsByEmail(email);
+        res.json(exists ? { exists: true } : null);
+        return;
+      }
       const user = await _getByEmail(email);
-      res.json(user);
+      res.json(withoutCredentials(user));
       return;
     } catch (error2) {
       import_node_server_utils42.logger.log({ level: "error", message: `${error2.message}` });
@@ -82167,7 +82193,7 @@ function useUserControllerV2() {
       return rejectValidation(error, next);
     try {
       const user = await _getUserByEmail(value);
-      res.json(user);
+      res.json(withoutCredentials(user));
       return;
     } catch (err) {
       import_node_server_utils267.logger.log({ level: "error", message: `${err.message}` });