设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客

Rails不安全的默认配置:13个安全陷阱

2013-4-26 14:46| 发布者: joejoe0332| 查看: 3605| 评论: 0|原作者: Lax, enixyu, throwable, super0555, jimmyjmh, zhouao, 傅小黑|来自: oschina.net

摘要:   安全的默认值对于构建安全系统至关重要。如果开发者必须采取各种明确行动才能实现安全,最终即使最有经验的开发者也会忘记这么做。出于这个原因,安全专家说: “不安全的默认值导致系统不安全。”   Ra ...

  未解决的问题

  这篇文章剩下的部分会讲一下在出版的时候Rails还存在的的安全风险。希望最少这里的一些会被修复,同时我将会在修复了的情况下更新这篇文章。

  1. VerboseServerHeaders

  默认的Rails服务器是WEBrick(部分是Ruby标准库),虽然它很少在产品模式下运行WEBrick。作为默认的选择,WEBrick返回在每个HTTP回复一个verboseServerHeader。

1HTTP/1.1 200 OK
2# …
3Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
看下WEBrick的源代码,你可以看到头部是由一些关键性的信息组成:
1"WEBrick/#{WEBrick::VERSION} " +
2"(Ruby/#{RUBY_VERSION}/#{RUBY_RELEASE_DATE})",

  这暴露的WEBrick的版本,同时也包括正在运行的特定的Ruby的补丁级别(因为发布日期与补丁级别匹配)。使用这些信息,spray和prey扫描者更有效地针对你的服务器,同时可以定制他们的攻击让其变得更有效了。

  最好的实践: 避免在产品模式运行WEBrick。有其他更好的服务器,如Passenger,Unicorn,Thin和Puma。

  修复: 虽然这个问题是起源于WEBrick的源代码,Rails应该配置WEBrick来使用更小的verboseServerHeader。简单点就“Ruby”似乎更好。

  2. 绑定到0.0.0.0

  如果你启动一个Rails服务器,你会看到一些像下面的东西:

1$ ./script/rails server -e production
2=> Booting WEBrick
3=> Rails 3.2.12 application starting in production on http://0.0.0.0:3000

  Rails在绑定到0.0.0.0(所以网卡)而不是127.0.0.1(仅本地网卡)。这会在开发模式和产品模式的上下文上都会产生安全风险。

  在开发模式,Rails并不安全(举例来说,它渲染诊断500个页面)。此外,开发者可能加载一个混合了产品数据和测试数据的东西(例如用户名:admin/密码:admin)。在三藩市的咖啡店里扫描web服务器的3000端口将可能收到很好的目标。

  在生产环境下,Rails必须通过代理服务器来运行。如果没有代理,IP欺骗攻击就会时常发生。如果Rails绑定了0.0.0.0,攻击者就可以轻松绕过代理服务器,直接攻击Rails服务器。

  所以,绑定到127.0.0.1比默认的0.0.0.0会更安全。

  最佳实践:保证生产环境仲的web服务器进程绑定了最小的一组接口。不要为了调试,而把生产环境数据导入到你的手提电脑。如果你必须这样做,尽可能少的导入数据,并且当它没用的时候立刻删除。

  修复:Rails已经提供了一个绑定选项来修改服务器监听的IP地址。我们必须把默认的0.0.0.0修改为127.0.0.1。开发人员如果需要修改生产环境的绑定接口,可以通过修改部署配置来实现。

  3. 记录Secret Tokens的版本

  每一个Rails app都会获取一个很长,而且是随机生成的secret token,当使用rails new的时候,它会被生成并保存在config/initializers/secret_token.rb。里面的内容类似这样:

1WebStore::Application.config.secret_token = '4f06a7a…72489780f'

  因为rails自动创建secret token,所以很多开发者会忽略掉它。但是这个secret token就像是你的应用的管理员钥匙。如果你拥有了secret token,那样伪造会话和提升权限就会变得很容易。这是其中一个十分重要而且敏感的数据需要去保护的。加密是保护你的钥匙的最佳办法。

  但是很不幸,rails并不能很好的处理这些secret token。secret_token.rb文件会被加入到版本控制当中,复制到GitHub,CI服务器和每一个开发人员的电脑。

  最佳实践:在不同的环境中使用不同secret token。在应用中插入ENV变量就可以实现这个目的。另外一个替代方法是,在部署过程中把secret token作为符号链接。

  修复:至少,rails必须通过.gitignore来忽略config/initializers /secret_token.rb文件。开发人员在部署的时候,用一个符号链接来替代生产环境的token,或者把初始化器转变为使用ENV 变量来初始化(例如Heroku)

  我将会进一步提出rails创建一个保存serect token的机制方案。我们有大量的库提供安装指引如何把secret token加入到初始化器中,但是这并不是一个好的实践。同时,至少还有俩个解决方案来处理这个问题:ENV变量和初始化器的符号链接。

  rails提供一个简单的API给开发人员来管理secret token,而且后台还是可插拔的(就像缓存和会话存储)。

  4. 在SQL语句里记录值

  Rails提供的config.filter_paramters是阻止累计在产品日志文件的敏感信息的有用方法,例如密码。但它不影响记录在SQL语句的值。

01Started POST "/users" for 127.0.0.1 at 2013-03-12 14:26:28 -0400
02Processing by UsersController#create as HTML
03  Parameters: {"utf8"=>"✓œ“", "authenticity_token"=>"...",
04  "user"=>{"name"=>"Name", "password"=>"[FILTERED]"}, "commit"=>"Create User"}
05  SQL (7.2ms)  INSERT INTO "users" ("created_at", "name", "password_digest",
06  "updated_at") VALUES (?, ?, ?, ?)  [["created_at",
07  Tue, 12 Mar 2013 18:26:28 UTC +00:00], ["name", "Name"], ["password_digest",
08  "$2a$10$r/XGSY9zJr62IpedC1m4Jes8slRRNn8tkikn5.0kE2izKNMlPsqvC"], ["updated_at",
09  Tue, 12 Mar 2013 18:26:28 UTC +00:00]]
10Completed 302 Found in 91ms (ActiveRecord: 8.8ms)
  Rails在产品模式的默认日志级别(info)不会记录SQL语句。这里的防线是有时候开发者会在调试的时候增加日志级别。在这期间,应用程序会写入敏 感数据到日志文件,然后在服务器上长时间持久化。一个攻击者获得阅读服务器上文件权限能够简单地通过grep来找到数据。

  最佳实践: 要对产品级日志记录了什么保持清醒。如果你临时增加日志级别,记录下敏感数据,一旦它不再需要了请立刻删除那些数据。

  修复:Rails能改变config.filter_parameters成为 config.filter_logs的样子,并且将其同时应用到参数和SQL语句。它可能不能在所有情形下正确的过滤SQL语句(因为它需要一个SQL 解析器),但对于标准的插入与更新可能有80/20的解决方案。

  作为一个备选方案,如果它包含有对过滤数值的引用,Rails可以编辑整个SQL语句(例如,编辑所有包含“password”的语句),至少在产品模式是如此。


酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部