Rails Security Guide "five"

7. User Management

-Almost every web application has to deal with authorization and authentication. Avoid repeating your own wheel, and suggest you use a generic plugin. But please keep them up to date. Some extra precautions can make your application more secure.

There are some authorized and certified plug-ins available in rails. Password encryption is saved better than saving the plain text password directly. The most popular plug-ins are restful_authentication that can avoid session customization. However early versions in some cases one can land even without username and password.

Each new user can activate his account by using an email with an activation code link. After the account is activated, the value of the Activation Code column in the database is set to NULL, and if someone sends one such request, he will be logged to the database as the first active user. (The opportunity to become an administrator):

http://localhost:3006/user/activate
http://localhost:3006/user/activate?id=

This is possible because, on some servers, this way, such as Params[:id, with ID parameters, will be nil. However, here are the Finder methods in a activation action:

User.find_by_activation_code(params[:id])

If the parameter is nil, the result of the SQL query will be:

SELECT * FROM users WHERE (users.`activation_code` IS NULL) LIMIT 1

In this way, the first active user in the database record is found, returning the result, the attacker landed. You can find more information in my blog post. It is wise to update your plugin from time to times. Also, you can view your application to find out more about such vulnerabilities.

7.1. Brute Force guess account

-Brute force guess the account attack is to use the wrong login certificate to try. To block this attack with more general error information, you may need to enter a CAPTCHA.

The list of user names for your Web application may be used to do brute force guessing with a set of passwords, because most people don't use complex passwords. Most passwords are combinations of words and numbers in a dictionary. So it comes with a list of usernames and a hacker dictionary, an automated program that can find the correct password within minutes.

Because of this, most Web applications display a generic error message "Incorrect username or password" when they are incorrect. If the error message displayed is "The username is not found", the attacker automatically compiles a list of user names.

However, most Web application designers ignore the Forgotten Password page. When you enter a username or email address, these pages are often honest and show messages that are found (not found). This allows attackers to produce a list of user names that can be used to violently guess accounts.

A common error message can be mitigated by the forgotten password on this page. In addition, you can request an authentication code after a certain IP address has failed multiple landings. But note that this is not a completely bulletproof approach, and these automated programs can also change their IP addresses frequently. Just add obstacles to the attack.

7.2. Account Hijacking

-Many web applications can easily hijack accounts. Why not make it more difficult?

7.2.1. Password

To think of this, an attacker steals a user's session cookie, so they can share the same application. If the application can easily modify the password, the attacker would only need a few mouse clicks to hijack the user's account. Alternatively, if the form that modifies the password is susceptible to csrf attacks, the attacker would modify his password by luring the victim to a Web page that contains the made CSRF Img-tag. The countermeasure is that the form that modifies the password cannot be CRSF attack, of course when changing the password, also need the user to enter old password.

7.2.2. E-Mail

However, an attacker could also take over an account by modifying an email address. When he changes his email address, he goes to a forgotten Password page, and a new password may be sent to the attacker's e-mail. The response is that when you modify an email address, you also need to enter a password.

7.2.3. Other

Depending on the Web application, there may be more ways to hijack user accounts. In many cases, both CSRF and XSS are instrumental in doing so. For example, a csrf vulnerability in Google Mail, in which the victim is lured to a site controlled by the attacker, in this proof-of-concept attack. There is a good img-tag on this site, and the result of this tag is to send an HTTP GET request to change the mail filter settings in Google Mail. If the victim landed in Google Mail, the attacker would change the filter settings to forward all of his messages to the attacker's mailbox. This is almost as bad as hijacking the entire account. The countermeasure is to audit your Web application logic to plug all XSS and csrf vulnerabilities.