Rails Security Guide "one"

Original address: http://guides.rubyonrails.org/security.html

This guide describes the general security issues in Web applications, as well as how to avoid these problems in rails.　 If you have any questions, please mail author, Heiko Webers, at the {et} rorsecurity.info. After reading this article, you should know:

1. All the responses have been highlighted.

2. The concept of the session in rails, what to put in the session, and some popular methods of attack

3. Just browsing a site, how can there be security problems? (with CSRF)

4. What to pay attention to when you use files or provide a management interface

5.The rails-specific Mass Assignment problem

6. How to manage Users: Login, logoff, and attack methods on all levels.

7. And the most popular method of injection attack.

An introduction

The Web application framework helps developers build web apps, and some of the frameworks help you a lot in terms of security. In fact, one framework is no more secure than another. For most frameworks, if you use it correctly, you can build a secure application. Ruby on Rails has many clever helper methods, such as a way to prevent injection attacks, which makes SQL injection a difficult task. I'm glad to see that all of the rails apps I've validated have a good level of security.

There is generally no security for this Plug and play, and security depends on the framework in use and sometimes on the development approach. It depends on all the environments of the Web application: Back-end storage, network servers, and the network application itself (and possibly other layers or applications).

Gartner estimates that about 75% of the attacks are in Web applications and that 97% of the 300 survey Web applications are vulnerable. This is because Web apps are easy to attack because they are easy to understand and manipulate, even for lazy people.

In threatened Web applications, including user account hijacking, bypassing access control, reading or modifying sensitive data, or presenting false content. Or an attacker can install a Trojan horse program or unsolicited email to send software for the purpose of altering the company's resources in financial activities or causing damage to the brand name. To prevent attacks, minimize their impact and eliminate attack points, first of all, you must fully understand the attack methods in order to find the right countermeasures. That is the purpose of the guide.

In order to develop secure Web applications you must constantly update all levels and understand your enemies. To keep updating your subscription's secure mailing list, read the security blog and update and security check habits. I do this by hand, because you can find a nasty logical security problem.

Two Sessions

Our safe journey is best to start with the sessions that are most vulnerable to special attacks.

2.1 What is sessions

-http is a stateless protocol Sessions make it stateful.

-HTTP is a stateless protocol, sessions makes it stateful.

Most applications need to track certain states of a particular user. For example, the contents of a shopping cart, the ID of the current login user, and if no sessions is a good idea, the user must identify the identity at each request. If a new user accesses the application, rails automatically creates a new session. If the user has used this application before, it will automatically load an existing session.

A session is usually a hash and a session ID (usually a 32-character string) to identify the hash. In rails you can save and use the session in the following ways:

session[:user_id] = @current_user.id
User.find(session[:user_id])

2.2 Session ID

-the session ID is a byte long MD5 hash value.

-The session ID is a 132-bit MD5 hash value.

A session ID consists of a hash value of a random string. This random string is the current time, a random number between 0 and 1, a Ruby interpreter process ID number and a constant string.