Same-origin server fetch missing credentials for absolute paths

[GrygrFlzr]

Describe the bug

kit/packages/kit/src/runtime/server/page/load_node.js

Lines 100 to 103 in 5cea0c2

	if (/^[a-zA-Z]+:/.test(url)) {
	// external fetch
	const request = new Request(url, /** @type {RequestInit} */ (opts));
	response = await options.hooks.serverFetch.call(null, request);

Currently, all absolute fetch requests are treated as cross-origin, and cookies are not passed through. This does not adequately cover the three main cases of same-origin sites where cookies are shared:

• Different port on the same domain, e.g. localhost:3000 and localhost:5000
• Subdomains, e.g. api.domain.com and domain.com
• The same domain and port, but specified as an absolute path to satisfy some library (e.g. Apollo, which sucks)

However, this is not a trivial fix:

• Passing in cookies for all external requests would lead to indiscriminately sending cookies to cross-origin domains, which is wasted bandwidth at best and a security violation at worst.
• Browsers do not send the domain associated with cookies. A SvelteKit server hosted at sub.domain.com can receive cookies from domain.com OR sub.domain.com and cannot distinguish the two.

The lack of domain information presents various issues and limitations for potential solutions.

[Loose] If we assume that received cookies all belong to the second-level domain:

• We must identify what a "second-level domain" actually is (e.g. domain.co.uk exists, so we cannot blindly assume the level of the domain based on the number of separators)
• This is a security issue for subdomains that are shared with others, as is common in shared hosting (e.g. vercel, github pages, js.org) as it can happily send all vercel.app cookies to malicious.vercel.app
• This assumption is invalid for any pages hosted on direct IP addresses (eg. https://1.1.1.1 from Cloudflare)

[Strict] If we pick the strictest domain and assume received cookies belong to the current domain of the application:

• A SvelteKit app hosted at sub.domain.com would have to assume domain.com cookies as sub.domain.com cookies, and so api.domain.com would not be eligible to receive the cookies from server-side fetch using this algorithm, despite the fact that they would normally be passed by the browser clientside.
• The above behavior would require extensive documentation, as it would be a difference between the client and the server fetch.

The above also assumes we can adequately identify the current host. The Host HTTP header can be manipulated by the client, which seems questionable. A configurable setting may lead unaware devs to emulate the loose mode to "make things work" and turn the feature into a footgun.

To Reproduce
https://github.com/GrygrFlzr/sk-cookie-issue

Expected behavior
Cookies passed through to the API endpoint for the "Same Domain and Port" and "Same Domain, Different Port" cases.

Information about your SvelteKit Installation:

Diagnostics

  System:
    OS: Windows 10 10.0.22000
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 15.96 GB / 31.93 GB
  Binaries:
    Node: 14.16.0 - C:\program files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.14.13 - C:\program files\nodejs\npm.CMD
  Browsers:
    Chrome: 91.0.4472.124
    Edge: Spartan (44.22000.1.0), Chromium (91.0.864.59)
    Internet Explorer: 11.0.22000.1
  npmPackages:
    @sveltejs/kit: next => 1.0.0-next.119
    svelte: ^3.34.0 => 3.38.3

Severity
Depends:

• Annoyance for situations where proxying the API in SvelteKit is possible - it's an extra network trip.
• Blocking for situations involving third party libraries.

[daamsie]

Thank you for opening this.

I feel like behaviour should follow browser standards.

domain.com cookies should only be for "domain.com" - and not subdomains.
.domain.com cookies are available on all subdomains.

There is no need to "assume received cookies belong to the current domain" when there is already an explicit way of specifying what the cookie belongs to.

[GrygrFlzr]

I don't know how to emphasize "browsers do not send domain information of cookies" more than I already have, which is why we're stuck with assuming in the first place.

[GrygrFlzr]

I feel like behaviour should follow browser standards.

domain.com cookies should only be for domain.com - and not subdomains.
.domain.com cookies are available on all subdomains.

This is outdated and has not been true for a while. RFC 2109 describes the behavior you mentioned, but RFC 6265 trumps it and ignores the leading dot:

The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.) If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.

[daamsie]

Ah well that's good to know. I still see it around so much (including right here on Github). Thanks for the response and for looking into this issue in any case. I'll probably just be heading down the proxy route in the meanwhile, but hopefully this can be resolved for the future.

[daamsie]

And sorry, I see your point now on not knowing what domain the cookie is actually set up for. Makes sense.

In some other scenarios, I've seen this dealt with by optional attributes/settings along the lines of "domainCookie=true" or similar to force the framework to set domain cookies. Perhaps a similar approach could be used?

[traed]

Has this been released as of 1.0.0-next.162? I'm having this issue still.

[eikaramba]

if you talking about https://github.com/sveltejs/kit/pull/1847/files, yes that should work. at least for me. maybe share the code which is not working for you?

[traed]

The code is nothing special. It's a simple fetch to an absolute URL on the same domain, no options being passed in.

fetch('http://localhost:8080/api/dictionaries')

Checking the cookie header in the handle-hook will reveal that during SSR no cookies are passed through , but if I disable SSR for the module the cookies arrive as expected.

[eikaramba]

where are you calling the fetch method? in needs to be inside the module script tag. also directly in the load method. if you do it anywhere else not the internal fetch method from svelte-kit will be used. as i wanted to use it in some api wrapper i basically store the fetch object for later usage there from the __layout file. then when i want to make an api call i just use it. you should also include credentials:'include'

let me share some code to you:

__layout.svelte

<script context="module">
	import { setup } from "$lib/utils/api.js";

	export async function load({ page,fetch,session}) {
              setup(fetch); //<-- store internal fetch for later usage. you can also pass it everytime, but i didn't wanted that
........

someFile.svelte

<script context="module">
    import { print } from 'graphql/language/printer.js'
    import { query } from "$lib/utils/api";
    import gql from "graphql-tag";
      
        export async function load({ session, fetch, context, page }) {
            let res = await query(gql` //<--- i am calling an graphql endpoint by hand ,but this can also just be a regular rest server. in fact i am doing both
                        query {
                            ......
                        }
                    `
                )
            return {
                props: {
                    xxxxxx
                }
            };
        }
    </script>

api.js

export function setup(fetchlib) {
    if(myFetch) return;
    myFetch = fetchlib;
}
export async function query(query) {
  let res = await myFetch(VITE_APIURL + "/graphql",
  {
    method: 'POST',
		mode: "cors",
    credentials:'include',
    body: JSON.stringify({query: print(query)}),
    headers: {
      'Accept': 'application/json, text/plain, */*',
      'Content-Type': 'application/json'
    },
  })
  
  if (res.status != 200) {
    throw new Error(`expected status 200, got ${res.status}`)
  }
  
  return await res.json()
}

hope there is something here that helps you out