Information leak: Last visit redirect is triggered also for anonymous requests (public home page, if shared document)

[jon ⚝]

When an anonymous user visits an instance, they are redirected to the last visited page.

• If that is a publicly shared page, they are stuck there.
  It is still possible to manually call the /login route for creating a valid session through logging in.
• If it is a private page, they are redirected and asked to /login.

It would be expected that knowledge of the last_visit state is restricted to logged in users only, and not leaked to the public.

---

This runtime value is mutated when a logged in user does call loadNoteById:

notea/components/container/edit-container.tsx

Line 31 in d5f8113

 const loadNoteById = useCallback( 

And is set to the id for all cases, in which no new ID is opened:

notea/components/container/edit-container.tsx

Lines 71 to 75 in d5f8113

 if (!isNew && id !== 'new') { 
     await mutateSettings({ 
         last_visit: `/${id}`, 
     }); 
 } 

---

This also allows to set a temporary home page of a Notea instance, by carefully choosing the page last navigated to in a Notea tab before closing it.

---

Further down the road, somehow a similar "feature", combining a targeted redirect and a publicly shared page, could allow for a nice and simple "home page" of an instance. This would seemingly require an additional (runtime) setting, such as last_visit, but set and named differently.

---

Remediation would probably center around these pieces of the code base, where the lastVisit is patched into the request, if a user isLoggedIn:

notea/pages/index.tsx

Lines 57 to 66 in d5f8113

 const lastVisit = ctx.req.props?.settings?.last_visit; 
  
 if (lastVisit && ctx.req.session.get('user')?.isLoggedIn) { 
     return { 
         redirect: { 
             destination: lastVisit, 
             permanent: false, 
         }, 
     }; 
 } 

This is always true, if the auth.type equals to none.

notea/libs/server/middlewares/auth.ts

Lines 23 to 25 in d5f8113

 if (cfg.auth.type === 'none') { 
     return true; 
 } 

Which always seems to be the case:

notea/libs/server/config.ts

Line 143 in d5f8113

 let auth: AuthConfiguration = { type: 'none' }; 

[jon ⚝]

I'm also not perfectly sure how this line is to be read:

notea/libs/server/config.ts

Line 28 in d5f8113

 export type AuthConfiguration = { type: 'none' } | BasicAuthConfiguration; 

And how it is to be interpreted in the context of the type exports just before:

notea/libs/server/config.ts

Lines 15 to 27 in d5f8113

 export type BasicUser = { username: string; password: string }; 
 type BasicMultiUserConfiguration = { 
     username?: never; 
     password?: never; 
     users: BasicUser[]; 
 }; 
 type BasicSingleUserConfiguration = { username?: string; password: string } & { 
     users?: never; 
 }; 
 export type BasicAuthConfiguration = { type: 'basic' } & ( 
     | BasicSingleUserConfiguration 
     | BasicMultiUserConfiguration 
 ); 

#108 states that Notea is distinctively a single user platform. Why would it declare and export any MultiUser type?

[jon ⚝]

This is an edge case, which I have only found, because I had last visited a publicly shared page.

It's possible to reproduce this behaviour with an unauthenticated curl client:

$ curl -I https://notea.example.org 2>/dev/null | grep '307|location'
HTTP/2 307 
location: /U0lXWiHywE

[tecc]

This is actually a non-issue, at least in the latest alpha version. The issue was glanced upon in #169, which I promptly fixed.

The multiple-user configuration stuff is a remnant from when I was going to add that feature - this was when I was working on it as a fork, rather than as the maintainer. Things happened, I became the maintainer (although I've been doing an awful job thus far), and I decided to merge my changes to the upstream.

[jon ⚝]

Thanks for fixing this already.

Yes, #169 (comment) describes the same issue, I agree.