search

gadicc / meteor-headers

Access HTTP headers on both server and client. Client IP with proxy support.
https://atmospherejs.com/gadicohen/headers
GNU Lesser General Public License v3.0
61 stars 21 forks source link

httpOnly Cookies #18

Closed Nemo64 closed 10 years ago

Nemo64 commented 10 years ago

I just noticed, that cookies are also available in the client script. That one is critical because it works around the httpOnly policy on cookies. I'm not sure if headers should be whitelisted or blacklisted, but there should definitely be some kind of filtering be going on.

gadicc commented 10 years ago

Right again. Will fix this on the next release. I think it's best to just not send these. To access cookies, users can simply use regular JS if httpOnly is off. Thanks for pointing this out, this is critical for sites that use cookies.

Nemo64 commented 10 years ago

Meteor includes the jQuery Cookie extension... just wanted to point that out ;)

But I don't know if cookies are the only problem. Can't http include authorization (or is that already secured)?

And other things (like the cookie) can be obtained though the browsers methods quiet well, like the user agent though navigator.userAgent and therefor don't need to be transmitted, but should still be available on the server. On the other hand, headers could provide a standardized way of accessing those things... not sure about that.

gadicc commented 10 years ago

Right again, authorization key now not sent back to client either. Both of these addressed in 0.0.16 with commit https://github.com/gadicohen/meteor-headers/commit/a655ef825cc14238f3811f666fff46740bdeb7b1.

Yeah, I'd prefer to leave it as a standard way, rather than leave it up to the dev to check which keys are available via the browser and not. Also some keys are "available" in the browser but don't have the same value as what's ultimately sent in the HTTP request (don't recall examples off hand, but remember dealing with this in the past).

For userAgent as an example, do extensions that send fake userAgent values also modify navigator.userAgent?

I'm closing this issue because it's resolved, but we can still discuss below :)

Nemo64 commented 10 years ago

It seems like it does! screenshot

It was just a minor thing with the user agent. if you have to create exceptions for transfer anyways, it wouldn't be a big thing to do that for user-agent too. I would say that cookie and user-agent don't have to be sent over the wire and instead can be fetched/emulated using document.cookie and navigator.userAgent.

gadicc commented 10 years ago

Ok, I concede :) This is in 0.0.17 now.