fix: sanitize source url to avoid attack

[salmanm]

As reported in fastify/fast-proxy#42, this module too has similar vulnerability.
This PR fixes that.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[jsumners]

I'm not sure I follow the issue, but it seems to me that sticking a complicated regular expression in this path is asking for a redos vulnerability.

[salmanm]

Ok, would you rather replace strings manually? like str.replace('http://', '').replace('https://', '').replace('//', '/')?
I'm open to any other suggestion.
The intent here is to prevent changing base host if set.

[jsumners]

I'm unclear how the base would get changed:

> new URL('https://example.com/https://foo.com')
URL {
  href: 'https://example.com/https://foo.com',
  origin: 'https://example.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'example.com',
  hostname: 'example.com',
  port: '',
  pathname: '/https://foo.com',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

But, yeah, I think a dest.startsWith(/(http|\/\/)/) would be better.

[salmanm]

I'm unclear how the base would get changed:

[salmanm]

But, yeah, I think a dest.startsWith(/(http|//)/) would be better.

It's not just urls that start with http. See the screenshot, urls starting with // also cause trouble.

[salmanm]

Just noticed there's a regex in startsWith. It does not support regex.

The reason my original regex may look complicated is because I was trying to

• Remove any protocol string from the beginning (including arbitrary one's like foo://)
• Remove any number of forward slashes in the beginning. If I just remove 2, and if the string is ////foo.com then it'll still fall prey to the attack

[jsumners]

Okay, looking at the docs for the URL function, I see what the issue is:

The code in this module is:

1. If there is not a pre-defined "base" URL, accept source as-is
2. If there is a pre-defined "base" URL, we will always append the given source to the base

It is case 2 that exhibits the problem wherein an absolute source is ignoring the pre-defined base. I propose the following:

const destURL
if (base) {
  if (/^\/\w/.test(source) === false) {
    throw Error('source must be a relative path string')
  }
  destURL = new URL(input, base)
} else {
  destURL = new URL(source)
}

It is my opinion that it is a mistake to provide any non-relative source when a base is defined. We should just not even be attempting to sanitize it ourselves. The user of the module is doing something incorrectly. Either they are forgetting they defined a base or they are passing along user input untested. Regardless of which, or whatever else, it is on them to fix the issue.

Also consider:

> new URL('urn:foo:bar', 'https://example.com')
URL {
  href: 'urn:foo:bar',
  origin: 'null',
  protocol: 'urn:',
  username: '',
  password: '',
  host: '',
  hostname: '',
  port: '',
  pathname: 'foo:bar',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

The following is correct and totally valid:

> new URL('/urn:foo:bar', 'https://example.com')
URL {
  href: 'https://example.com/urn:foo:bar',
  origin: 'https://example.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'example.com',
  hostname: 'example.com',
  port: '',
  pathname: '/urn:foo:bar',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

[salmanm]

Thanks. I had considered throwing but thought it'd be breaking change so wasn't sure. But guess it makes sense to throw when base is defined and url still contains a host.

[jsumners]

It is likely a breaking change. But probably a necessary one.

[salmanm]

Aye pushed an update with different approach and no regex checks at all 🎉

I'll update docs once the approach is finalized Done.

[jsumners]

LGTM

[delvedor]

LGTM