Use global.location.host over '*' in global.postMessage

[tannerlyons]

This addresses a security concern where messages can be intercepted and/or sent to
any window that uses '*' as the 2nd parameter (the origin) to postMessage.

Per the OWASP HTML5 Security Cheat Sheet:

When posting a message, explicitly state the expected origin as the second argument to postMessage rather than * in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.

MDN's docs also state:

Always provide a specific targetOrigin, not *, if you know where the other window's document should be located. Failing to provide a specific target discloses the data you send to any interested malicious site

I see 2 issues with this PR and would appreciate your feedback:

1. Testing this doesn't seem to be an option in the current framework, as none of the browsers in the test framework allow location.host modification to actually reproduce this. This is a good thing for those browsers :)
2. window.location isn't actually part of the ES3 standard. It's implemented a bit differently in each browser. Since this code branch is only run in browsers that support postMessage, we can assume window.location.host is implemented because it was adopted by major browsers at the time of postMessage. I've not been able to find any great resource proving this, it's mostly from memory which feels bad.

The reason this is important for me is that to use this fantastic library in the USA government cloud (aws/azure/etc.), you must adhere to certain security scanners. The scanner has been able to exploit this to pass messages between different hosts. I'm guessing this is not using a major browser, but some other browser with security features turned off. I'm guessing that merging this PR would allow many more people here to use this library.

One last thing: clearly in reading this code there's not REALLY a big vulnerability. a message is posted, and then immediately executed on the next loop, then forgotten. Other windows can really only see the unique id of the deferred function. You can imagine, however, that someone might be able to do something with those, but I cannot think of a reasonable scenario where this would actually affect anything. The biggest concern here is the government scanner.

Thank you for this excellent lib!!!

[zloirock]

IIRC initially (before core-js publishing) I used something like proposed in this PR, but for some reason, it was changed to '*', I don't remember why. I know that it's not recommended way, but I don't see any possible vulnerabilities here. I think that this PR does not cause problems, so I'll try to accept it with some minor changes.

[tannerlyons]

Thanks!!

[ddillard]

Is a CVE going to be obtained for this issue? I can get one assigned if that would help.

[dominykas]

Is a CVE going to be obtained for this issue?

I don't think a CVE is relevant here. All that is contained in the messages that are sent is the numerical counter and the number is then checked against the local queue of functions to be called.

So there of course can be bugs, resulting in a DoS or something (if you have a really wild imagination), if a random number comes in over the channel at just just the very right time (a SUPER short timespan), and the function is called too early. But it is meant to be called as soon as possible, so I don't think even that is a concern.

This is a solid implementation and I see no way to exploit that.

The bigger concern is that for every deferral a listener is added and never removed, so that might be something worth fixing up (by ensuring addListener is only called once?) to avoid memory leaks or something, but that is outside of the original scope and unrelated to the original problem.

[dominykas]

I suppose the broadcast would be sending numbers to other websites using other libraries, which can then interpret those numbers in a weird manner, which is definitely a bug, and might cause other apps misbehave, but I'm not sure this can be classified as a security issue - a malicious website can do that in a much easier way without even bothering with core-js and a website which uses core-js is unlikely to be easily forced to send such messages in a malicious fashion.

[ddillard]

Per Snyk this issue can cause XSS, see https://snyk.io/vuln/SNYK-JS-COREJS-174627. If that's correct, that's a security issue.

[dominykas]

@ddillard snyk have amended this and they no longer classify this as a vulnerability:

This was deemed not a vulnerability.

[tannerlyons]

@zloirock do you have an eta on deploying 3.0.2? My team is hoping for an estimate.

[ddillard]

@ddillard snyk have amended this and they no longer classify this as a vulnerability:

This was deemed not a vulnerability.

Good news! Ok, never mind then! :-)

[zloirock]

@tannerlyons it will be 3.1.0. After some days. I have no concrete date since now I have some much more serious problems.

[tannerlyons]

@zloirock Thank you for the update. We'll react accordingly here 😄