Security - StanfordBioinformatics/pulsar_lims GitHub Wiki
SSL Connections
The default app domains provided by heroku are SSL-enabled. If a user tries to reach the app using the HTTP protocol, the web browser will switch to HTTPS.
Additionally, the configuration for the production environment forces SSL connections by setting config.force_ssl = true
[1] in config/environments/production.rb
such that HTTP connections are disallowed altogether.
Encrypted Cookies
Each user session is stored in a cookie whose contents are encrypted [1]. This prevents users from being able to directly modify the session stored in the cookie. The encryption key (created with rake secret
) is stored in an environment variable named SECRET_KEY_BASE, and referenced in config/initializers/secret_token.rb
. Together with an SSL connection, this also prevents a malicious user from sniffing your cookie on the network to hijack your session.
Cross-site request forgery (CSRF) protection
Having an encrypted session ID stored in a cookie is not enough to protect from CRSF. Consider this scenario: An attacker composes a link to a popular application that you just might be currently signed into, an finds a way for you to click it, or for your browser to load it (i.e. be making that the source link in an HTML image tag in a blog post you are visiting, for example). When your browser tries to load the image or navigate to the link, it will also send along the associated cookie to the application you are signed into. The session will be identified as you, and the action carried out through the link could be something harmful, such as delete data or even transfer funds if we're talking about banking.
The way that RAILS gets around this is to provide an authenticity token in all generated forms (and AJAX requests) coming from the application server. This token is stored server-side in the session, thus the cookie doesn't include it. If your browser follows a link to the application, there won't be an authenticity token included in the parameters (unless the attacker hard-codes one as a parameter in the link, but they'd have to know your token to begin with). As a result, RAILS will reject the request since the authenticity token or lack thereof in the request will not match that stored in the session.
CSRF protection is set in the application controller with the line
protect_from_forgery with: :exception
References
[1] Rails security guide - http://guides.rubyonrails.org/security.html