Let us just make it clear, if it still wasn’t. Before an attacker has access to your local storage, it means the attacker already has access to the session of your users, first and foremost. Let that sink in first
It’s exactly the same for a cookie - js can access that value. A difference with the cookie though, is that the value of the cookie is sent back and forth with every http request, where as the value stored in local storage is not. And like I said before, we can’t use an httpOnly cookie, because Meteor needs to be able to read the value client side.
I have been using REDIS for the authentication part of my app in meteor. And in serverside cookies are there for load balancers to work properly. Check this package this is the one I have been using for authentication and token storage and so on.
That article suggests cookies are more secure than local storage, but I still don’t understand why. Why is it harder for an attacker to grab the cookie value using javascript than it is for the attacker to grab the local storage value?
The argument that “no XSS is possible on my site” is both besides the point and utterly wrong. (I am not attributing this argument to you, just enumerating)
The argument that “it’s all the same once the client is compromised” is also wrong, for the numbered reasons above.
It seems to me that some people are arguing against the claim “Cookies are perfect”, but this is a straw man. The claim is: they are superior.
localStorage is simply not intended to store sensitive information, but cookies are (at least, by comparison). Why not “honor” the intention?
My proximate/initial motive in this thread is regarding the stance taken up top, basically opposing the customer, instead of supporting. I mean, your chances of convincing the auditor are sub-zero, and also, maybe it should give us pause to hear what paid specialists are saying, and do we want Meteor to appeal to serious, corporate customers – or not? Even if the concern didn’t make sense (it does), accommodation seems like a productive response.
A cookie is sent on every HTTP request, so it is available on the server side. To use this pattern for Meteor, the login must be treated different than now, because this is done entirely using web sockets and the login method.
That’s right. What I meant was that Meteor can’t just use a monkey patch and switch to using httpOnly cookies in place of another client readable method (local storage or secure cookies). The client side app needs access to the auth token to send it with requests over DDP.
I wonder if a sort of half-duplex model could be constructed from various parts though. We really only require DDP requests to contain the auth token, not receipts. There are already tools to set up cookies for SSR (staringatlights:fast-render) and others to convert methods to REST. If Meteor was modified a bit, it could probably be set up to receive http requests (method/subscription requests) which would attach httpOnly cookie auth token, and then respond through a DDP connection.
I guess I meant that, you can look up the cookie values. Browser security prevents JavaScript from accessing that information. Otherwise JavaScript loaded from a site can access localStorage or cookies.
Hi all, thank you everyone for some robust discussion.
It would be amazing if we could get a feature request to address this - not sure what or where to request this though… @jkuester - is this something you could setup? (and throw a link to the Feature Request here?)
Is it needed to send the cookie auth on every method/sub calls? It might be possible that only the initial connection that will authenticate the cookie and then succeeding calls will be an “authenticated” ddp. Or are we talking about the same thing?
Possibly - I haven’t looked at the code that controls DDP. I’m not actually certain that the token is even transferred with every request. It actually would make sense not to. But there are recovery scenarios where I think the token would be needed, such as lost and recovered connections, changing IPs, etc.
If it’s not needed for every request, maybe just the handshake (however that works) could be done over HTTP with the httpOnly cookie.
It should be inbuilt to all websites these days. Pick two: