Rails Security Guide "End"

8. Inject

-injecting such an attack would introduce malicious code or parameters to a Web application to run in its secure context. The famous example of injection is Cross-site scripting (XSS) and SQL injection.

Injection is tricky because the same code or parameter is malicious in one environment, but it is completely harmless to change the environment. A context can be a script, a query or a program language, a shell, or a ruby/rails method. The following sections cover all the contexts in which all important injection attacks may occur. However, the first part deals only with an injection-related architectural decision.

8.1. White List vs blacklist

-When purifying (sanitizing), protecting (protecting) or verifying (verifying) Something, the whitelist is better than the blacklist.

A blacklist can be a list of malicious e-mail addresses, private actions, or malicious HTML tags. This is exactly the same as the white list, the white list is a safe e-mail address, public actions, legitimate HTML tags and so on. Although it is sometimes impossible to create a whitelist (for example, in a garbage filter), you should also prefer to use the white list:

*

Use before_filter:only⇒[...] instead: except⇒[...]. This approach prevents you from forgetting to shield the new actions.

*

Use attr_accessible instead of attr_protected. Please see the contents of this section of Mass-assignment (white list)

*

Allow <strong> instead of canceling <script> to cope with Cross-site scripting (XSS). Look at the details below.

*

Do not use a blacklist to authenticate user input:

O

This is the attack code available: "<sc<script>ript>". Gsub ("<script>", "")

O

But to reject malicious input,

The whitelist is a good way to avoid the fact that you forget something on the blacklist because of human factors.

8.2. SQL injection

-Thanks to smart methods, SQL injection becomes a difficult problem in most rails applications. However this is a very serious and common attack in Web applications, so it is important to understand it.

8.2.1. Introducing

The purpose of SQL injection attacks is to influence database queries by manipulating the parameters of the Web application. A common target for SQL injection attacks is to circumvent authorization. Another goal is to perform data manipulation or read arbitrary data. Here's an example of not using user-entered data in a query:

Project.find(:all, :conditions => "name = '#{params[:name]}'")

This code may be in the search action, and the user can enter the name of a project to find the item he is looking for. If a malicious user enters or 1=1, the result of the query becomes:

SELECT * FROM projects WHERE name = '' OR 1 --'

These two dashes begin with a comment that ignores everything behind it. So the query returns all the records of the projects table, including the content that is masked to the user. This is because the query condition is true.