Reputation: 6947
The source from Rack::Session::Cookie
contains the following warning about not setting a secret to check for cookie integrity:
No secret option provided to Rack::Session::Cookie. This poses a security threat. It is strongly recommended that you provide a secret to prevent exploits that may be possible from crafted cookies.
When using the Rack::Session::Cookie
module, you can set a secret in this fashion:
use Rack::Session::Cookie, secret: 'change_me'
However, I'm using Rack::Session::Pool
, which "provides simple cookie based session management." I'm assuming that I also need to provide it with a secret, but can't find a relevant example. The source code/documentation is not very helpful either. Does anybody know if this needs to be done, and how it would be accomplished if so?
Upvotes: 2
Views: 1408
Reputation: 12251
If you take a look at this question and answer on the differences between Cookie
and Pool
, it points out that only the "id" (actually a SID) is kept within a cookie and everything else is kept in memory. If the data is in memory then the requirement to generate a HMAC is a lot lower than if it had been stored in the cookie, and if you really needed that then I suppose it's been left up to you.
I had a look at the source, and Pool does not look for a secret passed as an option, but Cookie does.
I believe from reading the source for Pool
that it generates a unique SID each time, so no keys/id's from your data are exposed.
As a side note, if you're going to choose to use cookies, encrypt them.
Upvotes: 2