Rails安全导读【完】

Rails安全导读【完】2011-07-18 51cto博客 blackanger译8.注入

— 注入这类攻击是给一个web应用引入恶意的代码或是参数，以便在其安全的上下文里运行。注入的著名的例子就是跨站点脚本（XSS）和SQL注入。

注入是非常棘手的，因为相同的代码或参数在一个环境是恶意的，但是换个环境却是完全无害的。一个上下文可以是一个脚本，查询或是程序语言，shell或是Ruby/Rails方法。下面的章节会涵盖所有重要的注入攻击可能发生的所有上下文。然而第一部分只涉及一个与注入相关的架构决策。

8.1. 白名单 vs 黑名单

— 当净化（sanitizing），保护（protecting）或者验证（verifying）一些东西的时候，白名单胜于黑名单。

黑名单可以是一堆恶意的e－mail地址清单，非公开的actions或者是恶意的HTML tags。这正好和白名单相反，白名单是安全的e－mail地址，公开的actions，合法的HTML tags等等。虽然有时候不可能去创建一个白名单（比如在一个垃圾过滤器里），但也更应该偏向于去使用白名单的方式：:

使用 before_filter :only ⇒ […] 代替 :except ⇒ […]. 这个方法使你避免忘记去屏蔽新增的actions带来的困扰。

使用 attr_accessible 代替 attr_protected. 请看mass-assignment这节的内容（白名单）

允许<strong>而不是取消 <script>来应付Cross-Site Scripting （XSS）。看下文的细节。

不要使用黑名单的方式验证用户的输入:

这是段可用的攻击代码: "<sc<script>ript>".gsub（"<script>", ""）

但要拒绝恶意的输入

白名单是一个好方法，可以避免在黑名单里因为人为因素而忘记一些东西的情况。

8.2. SQL注入

— 要感谢那些聪明的方法，使得在大多数的Rails应用中SQL注入成为了一个困难的问题。然而这是一个在web应用里非常严重和常见的攻击，所以理解它是重要的。

8.2.1. 引入

SQL注入攻击的目的是通过操作web应用的参数来影响数据库查询。一种常见目标的SQL注入攻击是绕开授权。另一种目标是执行数据操纵或者是读取任意数据。这有个例子来说明在查询里不使用用户输入的数据 :

Project.find（:all, :conditions => "name = "#{params[:name]}""）

这段代码可能放在search action里，用户可以输入一个项目的名字来查找他想找的那个项目。如果一个恶意用户输入了OR 1=1, 查询结果就会变成:

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

这两破折号开始一个注释忽略它后面的一切玩意儿。所以查询返回projects表的全部记录，包括对用户屏蔽的内容。这是因为查询条件为真。