? before the @ sign allows one to bypass whitelists in ionicabizau/parse-url
Reported on
Mar 14th 2022
Description
? before the @ sign in HTTP URLs allows one to bypass whitelists
Proof of Concept
Convince NodeJS HTTP client to make a request to 127.0.0.1 bypassing a google.com whitelist.
const parse = require('parse-url')
const http = require('http')
const url = parse("http://127.0.0.1?@google.com")
if (url.resource === "google.com") {
http.get(url.href)
}
? is a special character in URLs and anything after the ? should be interpreted as the query.
Impact
This vulnerability is capable of SSRF whitelist bypasses.
Occurrences
Hi Haxatron! The impact of this parsing issue is unclear and I'm not sure if this would constitute a vulnerability. For the proposed impact to be true, the parser would need to indicate that data should be loaded from one resource, whilst providing a different resource to a potential whitelist. How can this be?
Adjusting the severity until this is clear.
Hi @admin, Node's HTTP client as well as the browser follows the WHATWG URL spec which parses the URL, interpreting the ? after as the query, I believe this has been demonstrated quite clearly by my Proof-of-Concept.
This is how the WHAWG URL parser will parse it
new URL("http://127.0.0.1?@google.com")
URL {origin: 'http://127.0.0.1', protocol: 'http:', username: '', password: '', host: '127.0.0.1', …}
hash: ""
host: "127.0.0.1"
hostname: "127.0.0.1"
href: "http://127.0.0.1/?@google.com"
origin: "http://127.0.0.1"
password: ""
pathname: "/"
port: ""
protocol: "http:"
search: "?@google.com"
If this is an inconsistency with the WHATWG URL spec, then this is a bug, but not a security issue...
For this to be a vulnerability you must clearly state how this issue can lead to a security impact. This is currently not being demonstrated.
The WHATWG URL spec is the definitive spec. I have shown how it bypassed the whitelist in my SSRF PoC above.
For reference, the browser also follows the WHATWG URL spec, if you copy paste the payload into the URL Bar, you can see it goes to 127.0.0.1
This is the PoC i have highlighted clearly in my report which demonstrates the security issue
const parse = require('parse-url')
const http = require('http')
const url = parse("http://127.0.0.1?@google.com")
if (url.resource === "google.com") {
http.get(url.href)
}
NodeJS's HTTP client is the standard built-in HTTP client to make HTTP requests.
The above PoC doesn't demonstrate a security issue. As per your previous comments, this indicates a lack of compliance with spec. The maintainer has also confirmed on previous reports that this is not a security issue.
How does the above example (the PoC) not demonstrate a security issue? Non-compliance that leads to a security issue is a security issue, which I have demonstrated clearly above. In addition, the maintainer's did not reject other reports based on non-compliance, but because they failed to show how non-compliance resulted in a security issue.
@admin, just to be clear that this conversation also involves https://huntr.dev/bounties/d127d367-a9c3-4a50-9222-c35c36e3213c/ since you marked the severity 0 there as well, I am just merging my response into a single thread.
Apologies haxatron... I've re-read the report and also agree that this is a security issue.
I missed that in the if
statement, you were fetching href
whilst using the resource
for something similar to origin checking.