search

kadirahq / fast-render

Render you app even before the DDP connection is live. - magic?
MIT License
560 stars 80 forks source link

FastRender + page caching = security hole? #145

Open shilman opened 8 years ago

shilman commented 8 years ago

Suppose I am running FastRender on a page that does not require the user to be logged in. Furthermore, suppose I am using a CDN or some other intermediate page cache to improve my page load performance.

Now, suppose a logged-in user Alice accesses that page. FastRender will insert Alice's loginToken into the page head, and the page will be cached.

Next, suppose another user Bob accesses the cached page. Bob will then have access to Alice's loginToken, and can therefore access the site as Alice.

If this is correct, FastRender should never be used in conjunction with page caching. Or am I misunderstanding something about FastRender and/or Meteor security?

Thanks for your help.

avalanche1 commented 8 years ago

as far as I know, FR doesn't inject loginToken alongside with user data.. You can check this by Meteor.user() in the console.

arunoda commented 8 years ago

It's depends. We send the loginToken, if it comes with the cookie. (We can do it better). So, if you cached a loggedIn users page(even if it's a public page), it will have issues.

If you cached a non-logged user's page that won't have any issues.

shilman commented 8 years ago

Thanks for the response @arunoda -- I think this is a pretty serious issue and I'm surprised that more people haven't made a fuss about it. I guess this is a great reason to transition to SSR as quickly as possible. Thanks for being a trailblazer on both fronts! :smile:

If I come up with any good workarounds/practices as I work through this, I will post them here.

avalanche1 commented 8 years ago

@arunoda, could you elaborate on if it comes with the cookie and how to circumvent this?

arunoda commented 8 years ago

FR set the loginToken into the cookie once loggedIn. Then every request to server carries the login token. That's how it identify the user.

theodorDiaconu commented 6 years ago

I'm almost sure there is nothing in this world that offers page caching for logged in users. As different people may see different results based on their role/data access restrictions on the same route.