Attack vector arising from naive developer use of the `+layout.server.js` tree

[cdcarson]

Describe the bug

tldr;

• The existence of the +layout.server.js tree will lead folks to put logic there rather than in +page.server.js.
• Because SvelteKit decides on the client what to fetch from the tree, there are edge cases where important (e.g., authorization) logic in +layout.server.js is skipped.
• This may seem a contrived edge case, but it is an attack vector that needs to be addressed through documentation.

---

Consider the following case. (Repo link below)

src
└── routes
    └── launch-codes
        ├── +layout.server.js
        ├── +page.server.js
        └── +page.svelte

Let's say I naively (but I think quite naturally) do the following things:

• I place authentication/authorization logic in the +layout.server.js file. Perhaps I plan to elaborate this section of the site with launch-codes/[id].
• Meanwhile, I use +page.server.js to fetch a paged list of codes from the database.

Essentially I have separated the concerns of authorization and data collection.

Now this is totally secure as long as my user remains signed in. But let's say the following happens:

• The user goes to /launch-codes. This first page view runs the authorization logic in +layout.server.ts.
• They are signed out, say on another tab, or because the cookie expires, or just by deleting the cookie in the console.
• In the original tab, now signed out, they go to /launch-codes?page=2. The authorization logic in +layout.server.ts is skipped, and the signed out user is shown the launch codes.

I don't think there's a way to reliably fix this in the framework. The client side router decides what to fetch, and that AFAICT will always be manipulable. The only way to "fix" it is by documentation.

(Or we could get rid of the layout data tree notion entirely. Not a bad option, IMO, but a separate losing argument.)

I know all this may seem contrived, but:

• It's not that far-fetched for a developer to assume that separating authorization concerns is partly what +layout.server.js is for.
• It's not that far-fetched to assume that some apps may require quick cookie expiration. Think your bank.
• It exists. It's an attack vector.

Reproduction

Reproduction here, as minimal as I could make it: https://github.com/cdcarson/yellow-submarine.git

git clone https://github.com/cdcarson/yellow-submarine.git
cd yellow-submarine
npm i
npm run dev

• Go to http://127.0.0.1:5173/launch-codes
• Assuming you are not signed in, you'll be redirected to a sign in page, and redirected back after clicking the button
• Navigate through the paginated list
• In the tab's console, delete the signedIn cookie. (I.e. the cookie has expired or you've been signed out on another tab.)
• Without refreshing the page, click to another page in the list. You will be shown that page, rather than being redirected to /sign-in

I made a separate route with a "non-naive" implementation, getting rid of layout.server.js and doing the authorization in +page.server.ts.

• Go to http://127.0.0.1:5173/launch-codes-fixed
• Replicate the steps above. This time, after deleting the cookie, subsequent navigations through the list at /launch-codes-fixed will be redirected to /sign-in

Logs

No response

System Info

System:
    OS: macOS 12.4
    CPU: (8) arm64 Apple M1
    Memory: 70.06 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.13.2 - ~/.nvm/versions/node/v16.13.2/bin/node
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.2/bin/npm
  Browsers:
    Chrome: 104.0.5112.101
    Safari: 15.5
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.66 
    @sveltejs/kit: next => 1.0.0-next.442 
    svelte: ^3.44.0 => 3.49.0 
    vite: ^3.0.4 => 3.0.9

Severity

serious, but I can work around it

Additional Information

No response

[CaptainCodeman]

For security you need to check auth on every request. Every route can be fetched directly, without using the app UI at all, and each fetch is independent of anything that happened previously (although they can "collaborate" with the new await parent()

[Rich-Harris]

It sounds like what you want is a way for a load function to say 'always run me, even if you think you don't need to'. Straw man:

import { gateAuthenticated } from '$lib/auth';
import type { LayoutServerLoad } from '../../../.svelte-kit/types/src/routes/launch-codes/$types';
import type { LaunchCodeLayoutData } from './shared';

export const load: LayoutServerLoad = (event): LaunchCodeLayoutData => {
+	event.alwaysRun();
	const signedIn = gateAuthenticated(event);
	return { signedIn };
};

[cdcarson]

@Rich-Harris My gut is that this is a "more documentation" issue. event.alwaysRun() could just as well be omitted as await parent() (or however it is now recommended to ensure the entire tree is invalidated.) Granted, to footgun the omission is in one +layout.server.js rather than in each leaf. Might make sense.

[cdcarson]

Ack, I see I wrote this:

Granted, to footgun the omission is in one +layout.server.js rather than in each leaf. Might make sense.

Ungarbled: For the vector to be in play, the developer would only have to forget to do event.alwaysRun() in the one +layout.server.js where the logic exists, rather than forgetting to repeat the logic in any one of many +page.server.jss.

So yes, I'd be on board with event.alwaysRun() if it's guaranteed that the client router couldn't override it.

The footgun would still exist, but event.alwaysRun() affords the opportunity to explain how to avoid it in a concrete. memorable way.

[TranscendentalRide]

Why not +auth.server.js since authentication is among the basics of apps.

[cdcarson]

@TranscendentalRide Adding an +auth.server.js filename would light a dumpster fire 🔥. (See the discussions in the repo.) But I see where you're going. Right now the +layout.server load tree is all about caching, a fundamentally different concern from auth. So, maybe something like this in +layout.server.js...

// SvelteKit type...
export type LayoutServerGuard = (event: RequestEvent) => MaybePromise<void>;


// src/routes/kittens/[kittenId]/dashboard/+layout.server.ts...

// as now, refetched only when invalidated
export const load: LayoutServerLoad = async (event): Promise<KittenDashboardData> => {
   const { kittenId } = event.params
   const kitten = await db.findUnique({where: {id: kittenId}});
   return { kitten };
}

// called for every navigation to page in `/kittens/[id]/dashboard/*`
export const guard: LayoutServerGuard  = async (event): Promise<void> => {
  // authorize the current user in relation to the kitten dashboard
  // could be just reading a cookie in many cases -- i.e. quick
  // if the user isn't authorized, throw error or redirect, otherwise void
}

...where guard, if it exists, would (1) always be called and (2) always beawaited before load (if load is called.) There's also a case where one would want guard without load. Note that LayoutServerGuard deliberately doesn't return anything, maintaining its independence & simplicity.

But maybe that's gilding the lily. I'd be happy with alwaysRun if that's simpler to implement.

[TranscendentalRide]

@cdcarson Maybe... but that shouldn't matter

I believe the declarative benefits of this "plus paradigm", ie +function.location.js affords us not to need to dig into the code to see how it renders. Back pedaling on it give more power to the idea that this is the wrong direction.

[AdrianGonz97]

Today I learned about an interesting quirk of SvelteKit's invalidation that I think we can use to our advantage for this exact scenario. We can force the load function of +layout.server.ts to rerun every time we navigate to and between the child routes of a layout group.

This issue was referenced in this video demonstrating the current problem of protecting routes by way of only checking the auth in +layout.server.ts files, without awaiting the parent on each route.

Check out this repo that I forked from @huntabyte to see it in action. To accomplish this, I'm adding url.href here as an almost equivalent event.alwaysRun() function that Rich presented, but not quite.

Adding a url.href anywhere in the load function works because url.href has now become a dependency of said load function. If any dependency of the load function changes, the load function will rerun, as specified here.

By adding a url.href in the layout load function, we no longer have to add an await parent() in each child +page.server.ts load function.

Obviously, this isn't an ideal solution by any means, but it's an interesting one that I stumbled upon.

[ivanhofer]

Adding my two cents here:

Handling authorization is currently easy to mess up.

1. The main issue was already described above:
   If you don't explicitly run all checks on each request, someone could access data he isn't allowed to see.
   Unexperienced users probably won't notice the issue. They will think if they protect a node inside this tree structure, each leave will also be protected.
   Having to manually add await parent() is too easy to forget. Even if you are paying attention, you will probably mess it up at some point in the future and you won't spot the issue until it's to late.

2. Another smaller issue is: because all load functions per default run in parallel, data could get fetched from the DB before a parent load function detects that the user is not authorized. Not a big issue since the data will not get passed to the user, but also not ideal, since it could make an expensive call to the DB.

3. And yet another issue I can see is that regular endpoints must also be protected individually. Which is fine, but I guess this is not clear to all developers.

You will end up with a lot of duplicated code because you need to check authorization in each exported function of every +*.server.js file. And also easy to mess up when you alter the check somewhere, but forget to change it everywhere else.

There were already described a few solutions in the comments above:

• event.alwaysRun(): I don't think this is a good solution as it only solves issue 1
• export const guard inside +*.server.js files: would solve issue 1 and 2
• +auth.server.js: would solve all 3 issues

In my opinion adding +auth.server.js would be a great addition to SvelteKit

• Before a load or an endpoint function get's called, all +auth.server.js files get checked. If one of those checks throw an error object, nothing gets executed and the error Response get's returned.
• Inside the auth file, someone could implement advanced auth checks, handling POST and DELETE independently. As those files probably tend to be just a few lines short, it would be really easy to understand. In contrast to a load function where you need to find out where auth code stops and where the actual data fetching happens.
• Having auth defined as a file inside a directory makes it obvious that the route is protected somehow.
• I also really like that the order matches the flow in which those files get called:

   /route
   	/+auth.server.js
    	/+layout.server.js
    	/+page.server.js
   	/+page.svelte

  auth happens before layout which happens before page and at the end the .svelte file gets rendered.

I think this would fit really well into the current concepts of SvelteKit, would make thinks more obvious and easier to maintain.

Would a +auth.js (without server) also make sense? For my use-cases probably not, but maybe someone could need it.

And If someone does not like the additional file, he does not have to use it and can implement auth like we currently have to do.