Rails安全导读【完】 - 编程入门网

Rails安全导读【完】

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)。看下文的细节。

*

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

o

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

o

但要拒绝恶意的输入

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

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表的全部记录，包括对用户屏蔽的内容。 这是因为查询条件为 真。

Rails安全导读【完】(2)

8.2.2. 绕过授权

一般一个web应用是包括访问控制的。用户输入他的登陆凭证，web应用试图在users表里去找到与其相匹配的结果。如果它找到一条记录， 那么应用就授其访问权限。然而，一个攻击者可能通过SQL注入的手段绕开这个检查。下面是一个典型的Rails数据库查询,当那些登陆凭证和用 户输入的一致时，就会在users表里找到对应的第一条记录。

User.find(:first, "login = ''#{params[:name]}'' AND password = ''#{params[:password]}''")

如果一个攻击者输入 OR ''1=1 作为用户名, OR 2>''1 作为密码, 那么查询结果就会变成:

SELECT * FROM users WHERE login = '''' OR ''1''=''1'' AND password = '''' OR ''2''>''1'' LIMIT 1

这会很简单就找到了数据库的第一条记录，并且给了这个用户访问权限。

8.2.3. Unauthorized reading

UNION连接的两个 SQL查询，会返回一组数据集。一个攻击者可以用它

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!