Session security in Rails

Introduction

Most of the current web development frameworks support and help developers a lot in building web applications. Some of them also help to better secure web applications. In fact, no one framework is perfect: if you use them cleverly and cleverly, you can build highly secure applications with multiple frameworks. Ruby on rails has several such methods, for example against SQL injection attacks.

Security depends on the user of the framework, sometimes on the development method. And it depends on all levels of the web environment: back-end hosting, web server and web app. The Gartner Group estimates that 75% of attacks are on the web application layer, and found that out of the 300 websites surveyed, 97% contained vulnerabilities to attack. Because, these web apps are relatively easy to attack, because they are easy to understand and execute, even for ordinary people.

Vulnerabilities to web applications include: hijacking user accounts, bypassing access controls, reading and changing sensitive data, or displaying fraudulent content. Or an attacker could install a Trojan program, or unwanted mailing software, for malicious purposes. To prevent attacks, minimize their impact and eliminate vulnerabilities, you must first fully understand the attack methods to find the exact countermeasures, which is what this article is about. towards.

Sessions

A good place to start is with sessions, which is quite vulnerable to Sessions.

Most applications need to track the status of a specific user. For example, the content of the shopping cart or the id of the user who is logged in. If there are no sessions, the user must identify, authenticate on each of his requests. Rails automatically creates a new session when the user starts accessing the application. Later, it will load the existing session if the user is already using the application.

A session is a hash of values ​​and an additional session ID is usually a string of 32 characters to identify the hash. Each cookie sent to the client’s browser contains the session ID. And the browser sends it to the server with every request from the client. In Rails, you can save or get those values ​​with session methods:

Session ID

Most web applications have an authenticate system: a user provides the user name and password, then the web application checks and saves the corresponding user id into the session. For each request from the user, the web application will authenticate the user with the user id of the session without requiring a new authenticate.

Cookies act as temporary authentication for web applications. Therefore, anyone who obtains that cookie may use the web application as it does with that user’s right, with potentially serious consequences. Here are some ways to hack a session and how to deal with them:

• Sniff cookies in an insecure network, such as a wireless LAN, With an unencrypted wireless LAN, it’s easy to hear the traffic of all connected clients. From a web developer perspective, we need to provide a secure connection over SSL. From Rails 3.1 onwards, this can be done by configuring SSL in the config.force_ssl = true
• Most users do not have the habit of clear cookies after accessing at a public internet point, such as consistent strokes. So, if the end user forgets to log out of the web application, you can use them with this user right. Provide a log-out button in your app and put it in an eye-catching location.
• There are many cross-site scripting (XSS) attacks that target a user’s cookie. More details can be found at: http://guides.rubyonrails.org/security.html#cross-site-scripting-xss

Note when using the session

• Do not store large objects in a session. Instead, you should save them and the database and save their id in the session. This will make it easier to synchronize and avoid session overflow. This is also a good idea, if you modify the structure of an object, you can easily synchronize them because you only store the id of the object in the session.
• Important data should not be saved in the session. If users delete their cookies or close their browser, they will be lost.

Session storage

Rails provides a few session archiving tools, typically

CookieStore stores session hashes directly at the client side cookie. The server side receives the session hash from the cookie and get the session ID. That will significantly increase the speed of the application, but it’s a controversial storage and you have to think about the security issues surrounding it:

• Cookies can store up to 4kB data. This makes perfect sense because it is not recommended to store large amounts of data in a session. Usually just store the id of the database in cookies.
• The client can see everything you store in a session, because it is stored in clear-text (base64 encoded form). So you don’t want to store any confidential data here. To prevent tampering, a digest has been created from the session with a server-side secret (secrets.secret_key) and inserted at the end of the cookie. However, since Rails 4, the default storage is EncryptedCookieStore. With EncryptedCookieStore, the session is encrypted before being stored into cookies. This will prevent users from accessing and tampering with the content of cookies. So the session becomes a safe place to store data. secrets.secret_key is saved in config / secrets.yml

Therefore, the security issue depends entirely on this secret key, and a digest algorithm (usually the default is SHA1). secrets.secret_key_base is used as a special key to allow the session to be verified again to prevent tampering.

Attack CookieStore Sessions

It works as follows:

• A user gets a credit account, the money is saved in the session (that’s a bad idea, but suppose so)
• User buys something
• Credit amount decreases and new value is changed during the session
• The user copies the cookie from the previous step before buying and replacing it on the new cookie
• Users with original accounts when not purchased yet. Adding a Nonce in the session will solve replay attacks. A nonce is only valid once, and the server must monitor all nonces valid. The job becomes more complicated if the system runs on several servers. Storing nonces in a database will prevent the entire purpose of CookieStore.

The best solution against it is not to store any data of this type in the session, but only in the database. In this case, the credit information should be stored in the database, and logged_in_user_id in the session

Session Fixation

Above is a diagram of a session fixation attack. The attack focuses on changing the victim’s session ID to attack, forcing the victim’s browser to use a certain session ID without necessarily stealing the user’s session ID, the steps are as detailed as after:

• Hackers create a valid session ID at a credit system, for example, login and get a valid session ID, such as actions 1 and 2.
• Periodically access the application to keep the session in action
• The attacker and intruder forces the user’s browser to use the session ID above (action number 3). Because it is not possible to change cookies of another domain, a hacker can run a javascript code from the domain of the target application. Inject a JS code into the application with XSS. Eg:

• The attacker traps the victim into clicking on a page containing that Javascript. Thus the victim’s browser will automatically change the session ID
• When the session ID trap is used, the victim revisits the credit system and, of course, requires authentication to login.
• From now on, both the victim and the hacker will be using the same credit system with the same session. The session is valid without the victim’s knowledge

Session Fixation – Workaround

The most effective solution is to identify a new session and remove the old one after successful login. That way, hackers cannot use fixed sessions. This is also an effective measure against session theft. Here’s how to create a new session in Rails:

If you are using the Devise gem, it will automatically generate new and expire session IDs after you log in. After logging in the old session is removed and the new session is born. Another countermeasure is to store the unique attributes of the user during the session, verify them each time the request, and deny if invalid. Such as IP address or web browser name. When saving IP addresses, you must remember that internet service providers hide their users behind proxies.

Session Expiry

It is possible to set cookie expires expiration time with a session ID. However, the client side can edit cookies in the browser so setting expires for the server side session is more secure. Here is an example to set session expires in the database:

Epilogue

Above is how it works, attacks, and precautions for session hacking.