Rails Development Details (eight) security for rails applications

After reading this article, you should be familiar with the following:

All the obvious countermeasures.

The concept of a session in rails, where the content is stored, common means of attack.

A large number of allocation issues in rails.

There are a few things that you have to focus on when providing a management interface.

How to manage Users: Login, exit, attack methods at all levels.

Common method of injection attack.

1. Introduction

The web framework helps developers build Web applications. Some of them can also help you build secure Web applications. In fact, a framework is no safer than 21 frameworks, and if you use it correctly, you can build secure Web applications with many frameworks. Rails contains smart help tools, such as tools to prevent injection of attacks, so this is hardly a problem. Happily, many of the rails applications I've audited have a good level of security.

Generally, there is no security for Plug and play. Security depends on the person who uses the framework, sometimes the way it is developed. It relies on all layers of the Web application environment: Back-end storage, Web servers, Web applications themselves (and possibly even other layers or other applications).

Gartner Group estimates that about 75% of the attacks occur at the Web application tier, and that 97% of the 300 audited sites are vulnerable. This is because Web applications are relatively easy to attack because they are easy to understand and manipulate, and they can be understood and manipulated by the set of unprofessional people.

Threats to Web applications include user account hijacking, bypassing access control, reading and writing sensitive data, and displaying spoofing information. Even an attacker might install Trojans, or an unsolicited email-sending software that targets financial data, or destroys a brand by modifying the company's resources. To stop an attack, minimize the impact of an attack, and remove the attack point, the first thing you need to do is to fully understand the approach of the attack before you can find the right response. This is the purpose of this article.

To develop secure Web applications, you have to keep the layers updated and understand your enemies. Subscribe to secure mailing lists, keep up to date information, and read security-class blogs. I do this by hand, because that's how you find the dirty logic security problem.

2.sessions

A good place to start knowing about security is the session, where it is vulnerable to special attacks.

2.1. What is session

HTTP is a stateless protocol, and the session makes it stateful.

Most applications need to track the status of a particular user. This may be the content of the shopping cart, or the userid of a landing user. If there is no session, the user needs to be identified and validated on each request. When a new user accesses the application, rails will create a new session by itself. If the user has already used the application, an already existing session is loaded.

The session consists of a hash value and a SessionID, SessionID is usually a 32-character hash string. Each cookie sent to the client browser contains SessionID. The browser sends the SessionID back in every request from the client. In rails you can save and get the session value through the following code.

SESSION[:USER_ID] = @current_user. ID 
user.find (session[:user_id])

2.2.session ID

SessionID is a 32-byte MD5 hash value.

The SessionID consists of a hash value of a random string. The random string includes the current time, the random number between 0-1, the process ID of the Ruby interpreter (also a random number), and a constant string. So far, profiteering attacks on rails ' sessionid are not feasible. MD5 is irreversible, but can collide, so creating a string of the same hash value is only a possibility of existence theory.

2.3session Hijacking

After stealing a user's SessionID, an attacker can access the Web application on behalf of the victim.

Many Web applications have validation systems: Users provide login account and login password, Web application validation of this information, validation passed, the user's ID saved to the session. After that, the session is valid. Each request loads the user, identifying the user through the user ID in the session, and does not need to be validated again. The SessionID of the cookie is used to identify the session.

Therefore, cookies provide a temporary validation function for Web applications. Every user who gets a cookie from someone who can use the Web application on behalf of that person may have serious consequences. Here are some ways to hijack the session, has been the corresponding countermeasures.

Sniff cookies in an insecure network. Wireless LAN is such a network environment. In an unencrypted wireless LAN, it is especially easy to listen to all the connected clients ' communications. That's why you don't want to work in a coffee shop. Builders of Web applications should provide a secure connection through SSL. In Rails3.1 and later versions, you can configure them in a configuration file to force SSL connections to be used in the application.

Config.force_ssl = True

Most people do not clear cookies after working at a public terminal. If the user did not quit the Web application, you can use the Web application as the user just now. Provide a log-out button to the user in a Web application and place it in a prominent position.

The goal of many cross-site attack scripts Cross-site scripting (XSS) is to get the user's cookie.

Instead of stealing a cookie that is unknown to an attacker, change the user's session identity (in a cookie) to what he or she can understand. In the back, we'll talk about this so-called session fix.

The main purpose of most attackers is to obtain money. The private price of stealing a bank account is 10-1000 dollars, the credit card number is 0.4-20 dollars, the auction site's accounts are 1-8 dollars, the email password is 4-30 dollars.

2.4.session Guide

Here are some common session guides

Do not store large objects in the session. Stores content to a database, and only the ID of the data is saved in the session. This eliminates the headaches of synchronization and does not take up the session's storage space (depending on the type of storage session you choose). Server-side session storage space you can clear session, but it is difficult to reduce the client's storage space pressure.

Critical data should not be stored in the session. If the user clears his cookie or closes the browser, the information disappears. At the client's session store, the user can read the data.