Rails Security Guide "four"

5. Enterprise Intranet and management security

-Intranet and management interfaces are the most popular attack targets because they have special access rights. Although it will have some additional security measures, this is not the case in reality.

2007, the online recruitment site Monster.com suffered a custom Trojan (tailor-made Trojans) attack, this is the first specifically from the intranet to steal information from the custom Trojan. Custom Trojan is very rare, so far, the incidence rate is low, but it is also really possible, this is a client host security how important example. However, the biggest threat to intranet and management applications in the enterprise is XSS and CSRF.

XSS If your application recreates a malicious user's input from the extranet, then your application will be compromised by XSS. User names, comments, spam, etc. are common examples of easy XSS attacks.

In the management interface or intranet as long as a place has not been disinfected (sanitized) can cause the entire application to suffer harm. Possible vulnerabilities include stealing a privileged administrator's cookie, an IFRAME injection (monster.com) stealing an administrator password, or installing a malicious software to take over an administrator's computer through a browser's security vulnerability.

See the injection section for XSS countermeasures, as well as the recommendation of a Safeerb plug-in for both the intranet and the admin interface.

CSRF Cross Site Reference forgery (CSRF) is a powerful attack method that allows attackers to do everything intranet users and administrators can do. As you've seen how CSRF works in the previous sections, here are some examples of what attackers can do in the intranet and the admin interface.

A real-world example is an example of reconfiguring routing via CSRF. The attacker sent a malicious email containing csrf to a user in Mexico. E-Mail claims to have an e-card waiting for them, but it also contains an image tag (image tag) that can cause a Http-get request to reset the user's route (which is more prevalent in Mexico). This request changes the DNS settings so that requests to the Mexican bank can be mapped to the attacker's site. Every person who visits a bank site can see the attacker's bogus site through this route, and his certificate is stolen.

Another example is to change Google AdSense email address and password via GSRF. If the victim is logged into Google Adsense, a Google bid advertising management interface, the attacker may change his security certificate.

Another popular attack is spam on your Web application, spreading malicious XSS in your blog or forum. Of course, the attacker must know the URL structure, but most rails URLs are relatively simple, or, if it is an open source application management interface, it is easy for them to find out. Attackers can even do 1000 lucky guesses that include only malicious IMG tags to try every possible combination.

For CSRF countermeasures in the management interface and intranet application, please refer to the countermeasures in the CSRF chapters.

5.1. Additional Preventive measures

The general management interface works like this: its position is www.example.com/admin, but only in user mode is set up admin tag to access. Reproduce the user's input and then delete, add, and modify any data you want. Here are some ideas:

It is important to consider the worst-case scenario: if someone really has my cookie or user certificate. You can control the role for the management interface to limit the likelihood of an attacker. Or in addition to what is used in the public sector, how do you provide a dedicated login certificate for the Admin interface, or do you provide a password for each important action?

Does this administrator really have to be able to access this interface from around the world? Consider restricting landing based on IP address segments. Detect REQUEST.REMOTE_IP understand the user's IP address. It's not bulletproof, it's just creating an obstacle. But keep in mind that there may be people using proxies.

Place the management interface in a specialized subdomain, such as admin.application.com, to make its user management a separate application. This makes it impossible for an attacker to steal cookies from the usual www.application.com. This is because the same native standard exists in your browser: www.application.com injection Scripts (XSS) cannot read admin.application.com cookies, and vice versa.

6. Mass Assignment

-Refers to Model.new (Params[:model]) that allows an attacker to set values for arbitrary database columns without any precautions.

This mass-assignment may become a problem because it allows an attacker to set any property of model by manipulating the hash to a model new () method:

def signup
　 params[:user] #=> {:name => “ow3ned”, :admin => true}
　 @user = User.new(params[:user])
end

Mass-assignment saves you a lot of work because you don't need to set each individual value. Only need to pass a hash to the new () method, or specify attributes= (attributes) hash value, you can set a model in the hash of the property. The problem is that the hash parameters that are used frequently in controller are manipulated by attackers. He might change the URL like this:

http://www.example.com/user/signup?user[name]=ow3ned&user[admin]=1

This will set the following parameters in the controller:

params[:user] #=> {:name => “ow3ned”, :admin => true}
如果你通过mass-assignment这种方式创建一个新用户，那么这个用户很有可能会变成一个管理员。