Hi Arunoda,
This is very cool! I'm really excited to see experimentation with
storing login tokens in cookies, because that's something we'll need to
figure out eventually for server-side rendering.
Perhaps I'm being paranoid, but I see two ways that having login tokens in
cookies could potentially be dangerous. What do you think about
the following advice for fast-render users?
1. Users need to be careful about setting Access-Control-Allow-Origin
headers anywhere in their app if they're using fast-render. If a user
sets Access-Control-Allow-Origin: * on any request in their app, then a
malicious site could send an XHR request to the app and read the
response, which could include the user's subscription data from when the
request passed through the fast-render connect handler.
2. Users shouldn't write any code that has side effects inside their
fast-render route callbacks and publish functions, because a malicious
site could trigger those side effects by having the user's browser send
a request to an app using fast-render. (CSRF) Of course, it would be a
weird pattern to have side effects -- I don't think many people are
writing publish functions that, for example, change a user's settings or
change data from private to public, so this is probably extra paranoid
advice.
As a footnote to #1, Access-Control-Allow-Origin: * is actually set on
all SockJS XHR polls. This makes me a little nervous, but looks okay to
me because the SockJS handlers run before user-supplied handlers and
don't pass the request on to user-supplied handlers, so the fast-render
connect handler will never (or, at least, not as long as there are no
bugs in Meteor/SockJS) get its hands on a /sockjs request. If it did,
could cause the user's browser to open an authenticated DDP connection
to an app that is using fast-render, and
evil.com could easily get the
app server to send a DDP message that includes the string "<!DOCTYPE
html><head>", which would then be replaced with the user's subscription
data, which would then be readable by
evil.com on the DDP connection. So
I have the following questions/suggestions that might allow fast-render
to alleviate the impact of, for example, a bug in SockJS or Meteor that
ends up passing /sockjs requests through user-supplied connect handlers:
* Is there a reason that fast-render does not depend on route-policy and
use route-policy to avoid serving subscription data on /sockjs and other
non-app-html requests? (I see that there is a check for
`typeof(RoutePolicy) != 'undefined'`, but since fast-render does not
depend on route-policy, I believe that `appHtml(url)` will evaluate to
`true` for any url that passes through the fast-render connect handler,
except for the hardcoded ones like '/favicon.ico'.)
* When you override `http.outgoingMessage.prototype.write`, could you
save off the response headers and refuse to write subscription data on
responses that have Access-Control-Allow-Origin set? This would be an
extra safety belt in case a Access-Control-Allow-Origin request slips
through and gets passed to user-supplied connect handlers.
Thanks for yet another awesome contribution!
Emily