diff options
Diffstat (limited to 'railties/guides/source/security.textile')
| -rw-r--r-- | railties/guides/source/security.textile | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile index 182f3631ef..893f65856c 100644 --- a/railties/guides/source/security.textile +++ b/railties/guides/source/security.textile @@ -57,7 +57,11 @@ Many web applications have an authentication system: a user provides a user name Hence, the cookie serves as temporary authentication for the web application. Everyone who seizes a cookie from someone else, may use the web application as this user – with possibly severe consequences. Here are some ways to hijack a session, and their countermeasures: -* Sniff the cookie in an insecure network. A wireless LAN can be an example of such a network. In an unencrypted wireless LAN it is especially easy to listen to the traffic of all connected clients. This is one more reason not to work from a coffee shop. For the web application builder this means to _(highlight)provide a secure connection over SSL_. +* Sniff the cookie in an insecure network. A wireless LAN can be an example of such a network. In an unencrypted wireless LAN it is especially easy to listen to the traffic of all connected clients. This is one more reason not to work from a coffee shop. For the web application builder this means to _(highlight)provide a secure connection over SSL_. In Rails 3.1 and later, this could be accomplished by always forcing SSL connection in your application config file: + +<ruby> +config.force_ssl = true +</ruby> * Most people don't clear out the cookies after working at a public terminal. So if the last user didn't log out of a web application, you would be able to use it as this user. Provide the user with a _(highlight)log-out button_ in the web application, and _(highlight)make it prominent_. |