Cannot access window.location

[paulelliott]

I need to inspect the current subdomain and get the full URL for use with Open Graph tags but window.location is not available when running in fastboot.

[tomdale]

I'm not sure how this would work. In the browser you can derive window.location because it's the hostname of the server that gave you the assets, a.k.a. the origin. But on a node server probably running behind a load balancer, I don't think there's any way we could reliably guess this. It seems like a better bet would be to include the domain in your environment/configuration set up and use that.

[paulelliott]

I was thinking you could either:

1. Wrap the request URL with a mock location object.

2. Just document that this doesn't work in fastboot. Maybe have an empty dummy object with a configuration like you suggest so that it doesn't blow up.

[paulelliott]

For a little background on why this is important in my case, this ember app is publicly accessible and runs across multiple subdomains. Customers can choose a subdomain and the API server uses that as an account key to know what data to return. Since it is one app running multiple accounts, I can't just set that in the environment.

[tomdale]

@paulelliott We've tried to avoid recreating a synthetic browser environment (à la mimicking window.location) but I am definitely in favor of exposing this on the fastboot service.

[paulelliott]

That fastboot service already has headers and cookies in it so it seems to be shaping up to be a representation of the request itself. I wouldn't want to just add the raw request to it because that couples fastboot to the underlying implementation.

If that is the direction then I would suggest just adding currentUrl as an attribute of the service directly.

Otherwise I would nest a third object alongside headers and cookies because that opens the door for more functionality down the road. I wouldn't want to call it request because it implies that it is the actual request but it isn't.

What do you think of one of these contracts?

  this.get('fastboot.currentUrl')

  OR

  this.get('fastboot.meta.url')
  this.get('fastboot.requestData.urll')
  this.get('fastboot.requestMeta.url')
  ...or some other container name

[tomdale]

@paulelliott In #128, @danmcclain has exposed a host property. That would solve your use case, right?

One thing I'm nervous about are the security implications of this. Here's why:

In the browser, you are de facto running on an untrusted, remote client. Because you have designed for a 100% untrusted environment, the user forging things like URLs doesn't matter. For example, if you're using window.location to construct a new URL, it doesn't matter if the user tampers with it because they could just cURL that URL anyway.

But with FastBoot, you now have a server that potentially has more privileges and may be running behind a firewall. If the client sends a forged Host header, and then your Ember app uses that to construct a URL that points to a machine that is only accessible behind the firewall, you may have just given an attacker a vector to access what you thought was a protected system.

Here's another scenario: you use the hostname the user is accessing to determine what API server to hit to get sensitive account details. So something like:

return fetch(`{hostname}/users/1234.json`);

However, an attacker wants to maliciously retrieve the account credentials for another account. If the attacker sends a Host header with a malformed value, he or she may be able to cause the wrong URL to be synthesized. For example, imagine the attacker sets the Host to http://api-3.example.com/users/justin-bieber.json?.

Assuming the FastBoot server is authorized to access data from multiple accounts, we have now introduced a vulnerability into the system.

So here are some things to think about:

1. Is there any normalization happening to the Host header?
2. If not, should we be responsible for ensuring that the host is properly formed and doesn't contain extraneous path information that could enable the attack described above?
3. Given that the host is easily forged by an attacker, is there anything we can do to make this more secure?

For example, perhaps we only enable this property is the user specifies one or more regular expressions to whitelist certain hosts. This way the user could say something to effect of: "only set host if it matches /*.example.com/." If an attacker provided a Host header of http://evil.com, the host property would not be set. (This is kind of a general problem: Ember apps are written assuming the single-origin policy. How do we enforce good security in an environment without the SOP?)

[danmcclain]

@tomdale: Won't the malicious party need access to a specific user's credentials (be it via a stolen cookie, stolen access token) before they can use a forged header to access protected resources? The browser will not allow you to forge host headers, so a CSRF will not allow the third party to use a forged header.

If a third party gained access to a token or cookie, it's game over anyway in terms of security

[tomdale]

@danmcclain That's true, but I can imagine a world-readable database behind the firewall. For example, consider a Redis server where the hostname is used to generate a query, for some reason. I'm not saying it's a good idea, but someone will almost surely do this in practice.

[paulelliott]

I'm not sure this is something we need to worry about. The API server should be handling authentication and resource scoping regardless of where the requests originate from.

[paulelliott]

Resolved by #136