Some sort of CSRF protection

[Rich-Harris]

(draw the rest of the owl)

[halfnelson]

Listening to your Svelte Summit (spring 2021) post talk discussion about the "enhance" form support and its integration with SvelteKit. Maybe that same integration is what can provide the CSRF support (considering since a non JS post to a form is where CSRF is most needed)

[nbgoodall]

@Rich-Harris I soon need to draw this owl for an app nearing production, and why duplicate work?

Do you have any thoughts on this or how you'd like to see it implemented? :)

[nakleiderer]

I think, since svelte kit pairs nicely with FaaS, it would likely be best to avoid server side state. The Double Submit Cookie technique seems like a reasonable choice. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie

I believe it could be implemented as a POC without modifying svelte kit code. There's a few strategies that could be considered, but I'd consider using the JWT standard to be the simplest.

Proposal using JWT:

• Server generates anti-csrf token in the form of a JWT (hs256, maybe?) to generate anti-csrf token with expiration time, using server-side secret.
• Token is given to client in either session, or cookie, or a custom hidden input field injected into each form.
  • Cookie or hidden form input would be best for no-javascript executions
• Server uses middleware to validate token, rejecting with 403 if it is missing or invalid.
• Server executes request and generates a new CSRF token.

[mlusetti]

I think, since svelte kit pairs nicely with FaaS, it would likely be best to avoid server side state. The Double Submit Cookie technique seems like a reasonable choice. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie

I agree. A cookie with a SameSite: strict and HttpOnly (Secure too obviously) should do the trick

[Karlinator]

@nbgoodall I'm also needing to draw this owl about now. Did you get anywhere with this?

My first idea was to set the double submit cookie and inject the form field/value though the handle function (now nicely chainable with sequence). The cookie worked, but the input value was of course overwritten by Svelte during hydration. I don't yet have an idea for injecting the token into the form (so it will also appear in the POST request).

I'm trying right now to do this purely as a handler middleware without changing any code in SvelteKit itself.

[Karlinator]

So I've arrived at (I think) a working solution using only a handler.

It's essentially a signed double submit cookie with the added security of submitting it through a custom header (which means the same-origin policy comes to our defence as well).

The handler generates a JWT token with an expiry in a few minutes, then it adds a Set-Cookie header and injects a meta tag with the token in the document head.

On incoming requests, the handler reads the x-csrf-token custom header, compares it to the cookie, and verifies the signature. If everything is good it sets requests.locals.csrfVerified = true.

What I haven't decided is how to deal with getting new tokens. As it stands, tokens are only changed when the user reloads the page (and triggers SSR). The easy option is of course to just disable the router where necessary. That said, I don't think there's a way to disable the router for all navigation to a page, only from a page.

Alternately, you can just accept that the token is the same for however long the user remains on the page without refreshing.

[nbgoodall]

@Karlinator how are you adding the x-csrf-token header? In the fetch requests themselves?

My biggest motivation for this was making forms secure without JavaScript. It is a double submit cookie, storing an encrypted value in the cookie session and exposing a masked version in forms (similar to how Rails does it to protect against SSL breach attacks). I was already using an encrypted cookie to store arbitrary JSON, so the token lives in there.

On each request:

1. If there's not a CSRF token in the encrypted cookie session, generate and store a new one.
2. Mask the token using a one-time pad and add it to Svelte's $session.
3. Add the token in a hidden input field to all non-GET forms (I've created a custom Form element). This works for me, but asking users to do something like this seems a bit much...
4. On form submission, unmask the token and compare it to the encrypted one. If they don't match, throw an error.

The session is encrypted using AES as I needed to decrypt the contents, but HMAC would be slightly faster if all you need is to verify the token...

What I haven't decided is how to deal with getting new tokens. As it stands, tokens are only changed when the user reloads the page (and triggers SSR).

I'm not sure this is an issue; it's common for a token to last a whole session, and realistically how long is someone going to be on a page for?

[Karlinator]

@nbgoodall

I'm adding it in the fetch requests, yes. We ended up not supporting non-JS anyway, so at that point there was no reason not to.

I tried to limit myself as far as I could to only doing stuff in the handle function, as I didn't really want to create custom components. That said, I did have to manually pass the token into the fetch calls so I only partly succeeded. That is the only thing that happens outside the handle hook though, which I am pretty happy with.

But I had to trade off non-JS function entirely so it's definitely not a universal solution. I think creating (or importing, if this were a package) a custom form component is probably reasonable given the alternatives right now? Otherwise we'd have to modify Svelte itself probably (and in the process "lie" about what the DOM will look like). I could definitely see a CSRFForm as a component with a slot (although that double F is killing me).

What I haven't decided is how to deal with getting new tokens. As it stands, tokens are only changed when the user reloads the page (and triggers SSR).

I'm not sure this is an issue; it's common for a token to last a whole session, and realistically how long is someone going to be on a page for?

You're probably right. Depending on who you ask (there are some long threads on this on StackOverflow) I'd probably be fine with just checking for the existence of the header and relying on the same-origin policy. It's generated anew every time it's sent out, after all, so it shouldn't really be a problem. I'm probably being a bit paranoid; I have more than enough layers of defence in depth already not to worry about the token living through some client-side routing.

Thanks for outlining your solution though!

[nakleiderer]

Here's more details on the solution I ended up using. It supports JS and non-JS forms and operated in a serverless environment, so seems to be perfectly aligned with svelte-kit's principles. I'm only using this token for CSRF protection and not to store any session info.

Generate & Hyrdate

To add CSRF to a non-js page, you can hydrate the tokens in the handle hook. You'll need to set your cookie value and inject values into the HTML, like so:

import * as cheerio from "cheerio";

export async function hydrateCsrfProtection(
  response: ServerResponse,
  csrfToken: string
): Promise<ServerResponse> {
  if (response.headers["content-type"] !== "text/html") {
    return response;
  }

  // Add csrf information to meta tags
  const $ = cheerio.load(response.body.toString());
  $("head").append(
    `<meta name="csrf-param" content="${clientConfig.csrfParam}" />`,
    `<meta name="csrf-token" content="${csrfToken}" />`
  );

  /// Add csrf information to forms in case javascript is disabled or not loaded
  $("body")
    .find("form")
    .each(function () {
      $(this).append(
        `<input type="hidden" name="csrf-token" content="${csrfToken}" />`
      );
    });

  return {
    ...response,
    body: $.html(),
  };
}

Enhance Forms

To solve the cookie going away with hydration, you can add a use directive to "enhance" the form. For example:

const csrfTokenMeta = (): HTMLMetaElement =>
  document.querySelector('meta[name="csrf-token"]');
const csrfParamMeta = (): HTMLMetaElement =>
  document.querySelector('meta[name="csrf-param"]');
export const csrfToken = (): string => csrfTokenMeta().content;
export const csrfParam = (): string => csrfParamMeta().content;

// this action (https://svelte.dev/tutorial/actions) allows us to
// progressively enhance a <form> that already works without JS

export function enhance(form: HTMLFormElement): void {
  if (browser) {
    const csrfParamInput = document.createElement("input");
    csrfParamInput.setAttribute("type", "hidden");
    csrfParamInput.setAttribute("name", csrfParam());
    csrfParamInput.setAttribute("value", csrfToken());
    form.append(csrfParamInput);
  }
}

Wrap fetch for client-side only posts

You can support client-side fetch like this:

export const clientFetch: typeof fetch = (
  input: RequestInfo,
  init?: RequestInit
) => {
  const initHeader =
    typeof input === "string" ? init?.headers : init.headers ?? input.headers;
  const headers = new Headers(initHeader);
  headers.set("Content-Type", "application/json");
  headers.set("x-csrftoken, csrfToken());

  if (typeof input === "string") {
    return fetch(input, { ...init, headers });
  }

  return fetch({ ...input, headers }, { ...init, headers });
};

Ensure the tokens in the header/form and cookie match

To get the token from the form or the header, you can use another handle hook modification

const extractCsrfToken = (request: ServerRequest) => {
  if (request.body === undefined) {
    return "";
  }

  return typeof request.body !== "string" && "get" in request.body
    ? request.body.get(clientConfig.csrfParam)
    : request.headers[clientConfig.csrfHeader];
};

You'll need to make sure the header/form value matches the cookie. To get the cookie:

  const cookies = cookie.parse(headers.cookie ?? "");
  const cookieCsrfToken = cookies.csrf_token;

Your matching algorithm will differ depending on how you implement your tokens. A good start would be a HS256 JWT for both tokens. Use the same sub value for both tokens with a different cyptographically-random jti. In addition, set an eat (15 minutes is probably a good start). Validate both JWTs to make sure they haven't been tampered with or expired. Then, make sure the sub value in each token matches.