Description

First Assume this example

var parseUrl = require("parse-url")
parseUrl("http://[email protected]:[email protected]/path/name?foo=bar&bar=42#some-hash")

that return :

protocols: ["http"]
protocol: "http"
port: null
resource: "[email protected]"
user: ""
pathname: "/[email protected]/path/name"
hash: "some-hash"
search: "foo=bar&bar=42"
href: "http://[email protected]:[email protected]/path/name?foo=bar&bar=42#some-has"

With the same URL in the URL interface of nodejs we have following result:

hash: "#some-hash"
host: "google.com"
hostname: "google.com"
href: "http://firstdomain.com%40jflsdk.com:20200@google.com/path/name?foo=bar&bar=42#some-hash"
origin: "http://google.com"
password: "20200"
pathname: "/path/name"
port: ""
protocol: "http:"
search: "?foo=bar&bar=42"
searchParams: URLSearchParams {}
username: "firstdomain.com%40jflsdk.com"

In parse-url, You can see that the resource and href have different origins but they have the same origin in the URL interface of nodejs/browser.

attack senario

The scenario is simple: developers get a URL from the user in Backend, parse it, and verify its host(resource). The host value of the parsed payload is google.com, and they confirm the host as a reliable host, then use href to get the contents and show them to users, but the aaaaaa.com contents will be delivered to users.

Maybe You say developers often don’t use the href and they use the URL instead ( after confirming the host value ), I say :

They store the created URL object and want to keep it somewhere and use it again and again.

More interesting example :

After storing the URL object, developers want to get content from google.com with the cookies that belong to them, but they think wrong!! And they send the cookies and other authorization headers to aaaaaa.com that cause potential information disclosure damage.