Is devise vulnerable to session hijacking over a normal http:// connection? I am having trouble figuring it out from the documentation.
Yes. Rails' default way to manage sessions is susceptible to hijacking.
This is because it transmits to the client all the information the client further requires to identify itself in HTTP cookies. For the most part, anybody who can intercept the HTTP connection can assume the identity of the client from Rails' perspective.
The simplest countermeasure is to only serve your site via HTTPS and have Rails issue secure cookies, which tells the browser only to send that cookie via HTTPS. The security guide has more helpful tips.
As mentioned in this email on Devise discussion group, security setup for the application is in the domain of the main application (in this case, Rails, I assume).
Do check out the RailsCast episode - Dangers of Session Hijacking to deal with session hijacking at the Rails Application level.
Rails Security Guide's section on Session Hijacking is another must read resource.
Devise provides for forcing SSL only cookies by setting :secure => true in the config/initializers/devise.rb file of a Rails App.
Related
I'm adding oauth support (via omniauth) to a legacy Rails app. One complication to this app is that it uses subdomain-based multitenancy (for example account1.example.com, account2.example.com) and when registering our app with oauth providers, we need to specify full URLs for our callback — no wildcard domains allowed.
No problem, I'll just reserve oauth.example.com and register that.
The problem, though, is that our session ID cookies are set for account1.example.com and such. This makes CSRF protection break and also makes passing along the client's destination a lot tricker.
I can reconfigure our Rails app to set the session ID cookie on .example.com which fixes the CSRF issue. But! If I change that in production, it will invalidate every session for every user of our app. Not a showstopper, I guess, but pretty unfriendly.
So! As the only place I want to share cross-domain sessions is for our oauth actions — is there a way I can override the session handler on a per-controller basis?
Or would I maybe be looking to write a custom Rack middleware to override session handling for some requests…?
My question is different it's rather conceptual - As when a user login, session is created on server and it stores a unique id to client(browser) what if I copy that cryptographically signed cookie and any associate data from browser like token whatever app uses to recognize the machine, paste it or create it on another machine?
How would server recognize that? could someone Explain me as much you can? that would be a help
I tried finding the solution.
or how can I secure that? :)
As far as I know, only the user-identifying token in the Rails session cookie identifies the user. By sending that token (which happens automatically on each request), the server knows who you are. Anyone having that token will be treated by the server as if it were you. This is called Session hijacking.
There are a few things you can do to protect your user's cookies. First of all, secure your cookies by setting two flags:
secure tells the browser to send that cookie only over HTTPS, so it is protected against someone reading your traffic (and your cookie).
HttpOnly tells the browser to hide that cookie from Javascript, which improves protection against XSS (Cross Site Scripting). An attacker may find a way to inject some malicious Javascript, but the browser won't give it your session cookie.
On setting these flags, see the Rails API. For custom cookies it's basically:
cookies[:my_cookie] = { value: '...', secure: true, httponly: true}
For configuring the Rails session cookie, see this answer.
Recently, I have written a middleware that sets both flags automatically to any cookie in the application. It is called safe_cookies and we're using it in order to protect our applications.
i've done my google due diligence and can't find an explicit answer. so, good people of stack overflow...
if, in a rails 3 app, i'm not using cookies to store sessions, is it important to securely manage the "Application.config.secret_token"? furthermore, it is used at all?
The secret_token is used by the cookie_store, used to store session data client side. Here is a nice write-up of how to execute arbitrary code using a known secret_token.
This cookie_store is more precisely ActionDispatch::Session::CookieStore, a rack middleware that rails loads into your rack stack when you set session_store(:cookie_store). So if you're setting that to :session_store you should be fine not setting secret_token.
You can examine Rails.configuration.middleware to see all your middlewares and confirm ActionDispatch::Session::CookieStore is not one of them.
FWIW, a rails 3.2 app will start with secret_token not set, but requests that try to set session variables will fail 500. I haven't tracked down exactly where the failure happens.
But if you're not setting secret_token, and you don't have ActionDispatch::Session::CookieStore in your rack stack, and your app appears to work, you are safe from that particular attack.
The other use of secret_token is digest authentication.
In summary, to answer the question, if you're not using digest authentication, and you don't use cookie_store (e.g., by setting session_store(:cache_store)), then secret_token is not important.
The Application.config.secret_token is also used for HTTP Basic and Digest Access Authentication.
Rais 3.2 HTTP Basic and Digest Access Authentication source file
Basic and Digest Access Authentication RFC
It would be great to have a supporting doc for the same.
I'm assuming the question can be restated as "Does Devise use a cookie to keep track of your session after authentication." If so, the answer is yes.
To test this, clear your cookies, log in and then check your cookies again. You'll see one for your website named after your app.
#Rodrigo, sessions are enabled by cookies. That's how the session can follow you through multiple pages. HTTP is inherently stateless. Cookies allow you to save state.
Not directly.
Devise is built on top of Warden, which uses the session. I don't see any easy way to use cookies for authentication (although you may use rememberable to keep it recorded between sessions). Sessions are enabled by cookies, so it uses the cookies indirectly.
is it true that Rails depend on cookies? It seems that flash is a part
of session, and session uses cookies... so when i disable cookie in
Firefox, a Rails app that was working shows
[error]
ActionController::InvalidAuthenticityToken
so is it true that for a RoR app to work, cookies are mandatory?
Update: or, to make the Rails app work again, what is the simplest way? (and if it is one server only (Apache running mod_rails), then is it easier?)
They are not mandatory, but there are some things you can't do without cookies. You can turn the authenticity tokens off as described here.
It's not mandatory to use cookies, but it is the rails default from 2.x up. Using cookies serves as a simple solution to some more difficult problems that arise when you try to store cookies in memory on multiple servers (and you get into things like sticky sessions, losing user data etc).
You can set where rails stores your session data; that is the flash and anything that's associated with the specific user. In environment.rb you can configure where you store your sessions using the config.action_controller.session_store. The options for this are: :cookie_store, :active_record_store, :p_store, :drb_store, :mem_cache_store, or :memory_store.
cookie_store is the default, if you comment the option out or remove it from environemnt.rb. It's also the most versatile. If you have multiple servers, one request for a user might come into one server, and the next request might come into a different server. In this situation, you couldn't use memory_store, as the 2nd server wouldn't know anything about the current user.
By storing session information in an encrypted cookie, there is less load on the server to store this information. The only downside is that each request to the server needs to pass the cookie (usually <1k), but it's not a noticeable difference in anything I've ever experienced.
:cookie_store, :mem_cache_store and :active_record_store are the most commonly used ones.