Sinatra和Rack保护装置

Question

我正在使用Sinatra和CORS来接受A域(hefty.burger.com)上的文件上传。域B (fizzbuzz.com)有一个表单，可将文件上载到A上的路由。

我有一个选项路径和一个post路径，两者都被命名为'/uploader‘。

options '/uploader' do
  headers 'Access-Control-Allow-Origin' => 'http://fizz.buzz.com',
  'Access-Control-Allow-Methods' => 'POST'
  200
end 

post '/uploader' do
  ... 
  content_type :json
  [{:mary => 'little lamb'}].to_json
end

选择先被击中..。而且很管用..。然后门柱被击中并返回403。

如果我破坏了保护，那帖子就能工作..。我需要从名单中排除什么样的保护才能保持保护，但允许这些帖子通过？

我最近才被新的护栏烧死了，给我带来了一些悲伤。有谁能很好地指点这里该做什么？我这么说的原因是，我突然看到日志条目中有会话劫持问题的警报(几乎可以肯定，这仅仅是因为应用程序运行>1Dyno)。我看到机架保护(1.2.0)在我的Gemfile.lock，尽管我从来没有要求它.我的清单中有东西在召唤它，所以它被加载了，但是我的Sinatra应用程序中没有任何东西试图要求它或者设置它。

Answer 1

在Sinatra应用程序中使用它可以解决您的问题：

set :protection, :except => [:json_csrf]

一个更好的解决方案可能是将Sinatra升级到1.4，它使用Rack：：Protection1.5，并且不应该导致您正在看到的问题所在。

问题是当您使用内容类型: application/json响应时，RackProtection::JsonCsrf in的版本与CORS不兼容。下面是机架保护中csrf.rb的一个片段：

def call(env)
  status, headers, body = app.call(env)
  if headers['Content-Type'].to_s.split(';', 2).first =~ /^\s*application\/json\s*$/
    if referrer(env) != Request.new(env).host
      result = react(env)
      warn env, "attack prevented by #{self.class}"
    end
  end
  result or [status, headers, body]
end

当引用程序不是来自服务器的同一主机时，您可以看到这个拒绝具有application/json响应的请求。

这个问题在后来版本的机架保护中得到了解决，该版本现在考虑请求是否是XMLHttpRequest：

   def has_vector?(request, headers)
    return false if request.xhr?
    return false unless headers['Content-Type'].to_s.split(';', 2).first =~ /^\s*application\/json\s*$/
    origin(request.env).nil? and referrer(request.env) != request.host
  end

如果您使用的是Sinatra 1.3.2而不能升级，则解决方案是禁用此特定保护。使用CORS，您将显式地启用跨域XHR请求。Sinatra允许您完全禁用保护，或者禁用Rack::Protection的特定组件(参见Sinatra文档中的“配置攻击保护” )。

Rack::Protection提供了帮助战胜常见攻击的12个中间件组件：

• Rack::Protection::AuthenticityToken
• Rack::Protection::EscapedParams
• Rack::Protection::FormToken
• Rack::Protection::FrameOptions
• Rack::Protection::HttpOrigin
• Rack::Protection::IPSpoofing
• Rack::Protection::JsonCsrf
• Rack::Protection::PathTraversal
• Rack::Protection::RemoteReferrer
• Rack::Protection::RemoteToken
• Rack::Protection::SessionHijacking
• Rack::Protection::XssHeader

在编写本报告时，当您使用Rack：：保护中间件(Rack::Protection::AuthenticityToken、Rack::Protection::FormToken、Rack::Protection::RemoteReferrer和Rack::Protection::EscapedParams必须显式添加)时，除了四个之外，所有这些都会自动加载。

Sinatra使用Rack：：一个例外的默认设置:它只在启用会话时添加SessionHijacking和RemoteToken。

最后，如果您试图在Sinatra中使用CORS，您可以尝试使用机架，它为您处理了很多细节。

Answer 2

如果您看到这个问题，您没有使用CORS (跨源资源共享)，而是在反向代理(如nginx或apache)后面，请确保您的反向代理不会去掉host头，并将其替换为本地主机。

例如，在nginx中，您需要使用proxy_set_header

location / {
    proxy_pass http://localhost:9296;
    proxy_set_header Host $host;
}

当标题从请求中删除时，Rack::Protection认为它是CSRF攻击。

Answer 3

让我猜猜，你是在测试Chrome应用程序'Dev客户端‘吗？试一试：

curl -v -X POST http://fizz.buzz.com/uploader

来自机架保护模块：“支持浏览器：：Google 2，Safari 4及更高版本”

这应该是可行的：

class App < Sinatra::Base
  ...
  enable :protection
  use Rack::Protection, except: :http_origin
  use Rack::Protection::HttpOrigin, origin_whitelist: ["chrome-extension://aejoelaoggembcahagimdiliamlcdmfm", "http://fizz.buzz.com"]

  post '/uploader' do
    headers \
      'Allow'   => 'POST',
      'Access-Control-Allow-Origin' => 'http://fizz.buzz.com'
    body "it work's !"
  end

你可能对chrome-extension://aejoelaoggembcahagimdiliamlcdmfm很好奇吧？这就是当你用Chrome应用程序发送帖子请求时，机架保护作为env'HTTP_ORIGIN'得到的。