All the vulnerabilities related to the version 0.1.4 of the package
Improper Validation and Sanitization in url-parse
Insufficient validation and sanitization of user input exists in url-parse npm package version 1.4.4 and earlier may allow attacker to bypass security checks.
url-parse Incorrectly parses URLs that include an '@'
A specially crafted URL with an '@' sign but empty user info and no hostname, when parsed with url-parse, url-parse will return the incorrect href. In particular,
parse(\"http://@/127.0.0.1\")
Will return:
{
slashes: true,
protocol: 'http:',
hash: '',
query: '',
pathname: '/127.0.0.1',
auth: '',
host: '',
port: '',
hostname: '',
password: '',
username: '',
origin: 'null',
href: 'http:///127.0.0.1'
}
If the 'hostname' or 'origin' attributes of the output from url-parse are used in security decisions and the final 'href' attribute of the output is then used to make a request, the decision may be incorrect.
Path traversal in url-parse
url-parse before 1.5.0 mishandles certain uses of backslash such as http:/ and interprets the URI as a relative path.
Authorization Bypass Through User-Controlled Key in url-parse
url-parse prior to version 1.5.8 is vulnerable to Authorization Bypass Through User-Controlled Key.
Open redirect in url-parse
Affected versions of npm url-parse are vulnerable to URL Redirection to Untrusted Site.
Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
url-parse incorrectly parses hostname / protocol due to unstripped leading control characters.
Leading control characters in a URL are not stripped when passed into url-parse. This can cause input URLs to be mistakenly be interpreted as a relative URL without a hostname and protocol, while the WHATWG URL parser will trim control characters and treat it as an absolute URL.
If url-parse is used in security decisions involving the hostname / protocol, and the input URL is used in a client which uses the WHATWG URL parser, the decision may be incorrect.
This can also lead to a cross-site scripting (XSS) vulnerability if url-parse is used to check for the javascript: protocol in URLs. See following example:
const parse = require('url-parse')
const express = require('express')
const app = express()
const port = 3000
url = parse(\"\\bjavascript:alert(1)\")
console.log(url)
app.get('/', (req, res) => {
if (url.protocol !== \"javascript:\") {res.send(\"<a href=\\'\" + url.href + \"\\'>CLICK ME!</a>\")}
})
app.listen(port, () => {
console.log(`Example app listening on port ${port}`)
})
Open Redirect in url-parse
Versions of url-parse before 1.4.3 returns the wrong hostname which could lead to Open Redirect, Server Side Request Forgery (SSRF), or Bypass Authentication Protocol vulnerabilities.
Update to version 1.4.3 or later.
Authorization bypass in url-parse
Authorization Bypass Through User-Controlled Key in NPM url-parse prior to 1.5.6.
Prototype Pollution in querystringify
A vulnerability was found in querystringify before 2.0.0. It's possible to override built-in properties of the resulting query string object if a malicious string is inserted in the query string.