Rails安全导读【四】

 我的译言链接：

[url]http://www.yeeyan.com/articles/view/blackanger/17939[/url]

5. 企业内联专用网和管理安全

— 企业内联网和管理界面是最流行的***目标, 因为它们有特殊的访问权限. 虽然它会有一些额外的安全措施，可是现实里并非如此。

2007年，在线招聘站点Monster.com遭受了一起定制***（Tailor-made Trojans）***，这是第一只专门从企业内联网偷窃信息的定制***。定制***是非常罕见的，迄今为止，发生率比较低, 但是它也确实是可能发生的，这也是一个客户端主机安全何等重要的例子. 然而，企业内联网和管理应用程序面对的最大威胁还是XSS和CSRF.

XSS  如果你的应用重现了恶意用户从外网的输入，那么你的应用会受到XSS的危害。用户名，评论，垃圾邮件等是容易被XSS***的常见的例子。

在管理界面或是内网只要一个地方没有被消毒（sanitized）就会导致整个应用遭受危害。可能的漏洞包括窃取有特权管理员的cookie，iframe注入（Monster.com就是被这样***的）窃取管理员密码或者是通过浏览器的安全漏洞安装一款恶意软件来接管管理员的计算机。

参看Injection章节，有XSS的对策，以及推荐了一款在内网和管理员界面使用的SafeErb的插件。

CSRF 跨站点 Reference 伪造 (CSRF) 是一个强大的***方法,它允许***者能做内网用户和管理员能做的一切事情。正如你已经看到上面几部分里CSRF如何工作的，这里也有一些例子，说明***者能在内网和管理界面做些什么。

一个现实世界的例子是一个通过CSRF重新配置路由的例子。这个***者发送了一封包含CSRF的恶意的电子邮件给墨西

Logo

首页

文章

关注

订阅专栏

专家

网站导航

注册

登录

手机阅读

搜索

写文章

在线

客服

翻译 推荐

Rails安全导读【四】

blackanger关注2人评论876人阅读2008-11-15 06:12:39

 我的译言链接：

[url]http://www.yeeyan.com/articles/view/blackanger/17939[/url]

5. 企业内联专用网和管理安全

— 企业内联网和管理界面是最流行的***目标, 因为它们有特殊的访问权限. 虽然它会有一些额外的安全措施，可是现实里并非如此。

2007年，在线招聘站点Monster.com遭受了一起定制***（Tailor-made Trojans）***，这是第一只专门从企业内联网偷窃信息的定制***。定制***是非常罕见的，迄今为止，发生率比较低, 但是它也确实是可能发生的，这也是一个客户端主机安全何等重要的例子. 然而，企业内联网和管理应用程序面对的最大威胁还是XSS和CSRF.

XSS  如果你的应用重现了恶意用户从外网的输入，那么你的应用会受到XSS的危害。用户名，评论，垃圾邮件等是容易被XSS***的常见的例子。

在管理界面或是内网只要一个地方没有被消毒（sanitized）就会导致整个应用遭受危害。可能的漏洞包括窃取有特权管理员的cookie，iframe注入（Monster.com就是被这样***的）窃取管理员密码或者是通过浏览器的安全漏洞安装一款恶意软件来接管管理员的计算机。

参看Injection章节，有XSS的对策，以及推荐了一款在内网和管理员界面使用的SafeErb的插件。

CSRF 跨站点 Reference 伪造 (CSRF) 是一个强大的***方法,它允许***者能做内网用户和管理员能做的一切事情。正如你已经看到上面几部分里CSRF如何工作的，这里也有一些例子，说明***者能在内网和管理界面做些什么。

一个现实世界的例子是一个通过CSRF重新配置路由的例子。这个***者发送了一封包含CSRF的恶意的电子邮件给墨西哥的用户。电子邮件声称有一个电子贺卡等着他们，但是它也包含了一个可以造成一个HTTP- GET请求去重新设置用户路由的图像标记（image tag）（这在墨西哥比较流行）。这个请求改变了DNS设置以便到墨西哥银行的请求可以映射到***者的站点。每个访问银行网站的人通过这个路由都能看到***者的伪造站点，并且他的证书被盗。

另一个例子是通过GSRF改变Google Adsense的email地址和密码。如果受害者是登陆到Google Adsense，一个Google竞投广告的管理界面，***者可能会改变他的安全证书。

另一种流行的***是你的web应用上的垃圾， 在你的blog或者论坛传播恶意XSS. 当然，***者必须知道URL结构，但是大多数的Rails URLS是相对简单，或者，如果它是一个开源应用的管理界面，是很容易被他们找出的。***者甚至可以做1000个仅包括恶意img tags的幸运的猜测去尝试每一个可能的组合。

对于在管理界面和内网应用的CSRF对策，请参考CSRF章节里的对策。

5.1. 额外的预防措施

一般的管理界面是这样工作的: 它的位置是[url]www.example.com/admin[/url], 可只有在用户模式被设置了admin tag的才能访问。重现用户的输入，然后删除，增加，修改想要的任何数据。这里有一些想法：

考虑最坏的情况是非常重要的: 如果某人真的掌握了我的cookie或是用户证书。你能控制角色为管理界面去限制***者的可能性。或者除了哪些用于公共部分的应用，为管理界面提供一个专门的登陆证书如何，或者对于每次重要的action提供一个密码 ？

是否这个管理员真的必须能从世界各地访问这个接口？ 考虑一下根据ip地址段来限制登陆。检测request.remote_ip 了解用户的IP地址. 这并不是防弹的，而只是制造一个障碍。但请记住，有可能有人在使用代理。

把管理界面放到一个专门的子域，例如admin.application.com,使其用户管理成为一个单独的应用程序。这使得***者不可能从通常的[url]www.application.com[/url]窃取cookie。这是因为在你的浏览器里存在同一个原生标准: 在[url]www.application.com[/url]的注入脚本(XSS)不能读取admin.application.com的cookie，反之亦然。

6. Mass assignment

— 是指对Model.new(params[:model]) 允许***者设置任意数据库列的值没有任何防范措施。

这个mass-assignment可能变成一个问题, 因为它允许***者通过操作hash传到一个model的new()方法里来设置model的任意属性 :

def signup

 params[:user] #=> {:name => “ow3ned”, :admin => true}

 @user = User.new(params[:user])

end

Mass-assignment为你省去了大量的工作, 因为你不必要去设置每个单独的值。只需要给new()方法传一个hash，或者是指定attributes=(attributes)hash值，就可以在hash里设置一个model的属性。问题是，在controller里经常使用可用的hash参数会被***者操纵。 他可能会这样改变URL:

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

这样会在controller里设置如下的参数 :

params[:user] #=> {:name => “ow3ned”, :admin => true}

如果你通过mass-assignment这种方式创建一个新用户，那么这个用户很有可能会变成一个管理员。

6.1. 对策

为了避免这个问题， Rails在ActiveRecord类里提供了两个类方法去控制访问你的那些model的属性。attr_protected方法可以设置一个不被mass-assignment方式访问的属性清单（黑名单）：

attr_protected :admin

attr_accessible是一个更好的方式，因为它遵循了白名单原则。 这和attr_protected是完全相反的，因为它列出的是可被访问的属性清单。 所有其他的属性会被保护。这样你就不会忘记去保护在开发过程中增加的新的属性。这里有个例子:

attr_accessible :name

如果你想要保护一个属性，你就必须独立的去指定它 :

params[:user] #=> {:name => "ow3ned", :admin => true}

@user = User.new(params[:user])

@user.admin #=> false # not mass-assigned

@user.admin = true

@user.admin #=> true

安全RubyRails

0