Estoy usando Sinatra y CORS para aceptar la carga de un archivo en Un dominio (hefty.burger.com). Dominio B (fizzbuzz.com) tiene un formulario que carga un archivo en una ruta en A.

Tengo una de las opciones de ruta y un post de la ruta, tanto el llamado ‘/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

Las opciones se golpea primero… y funciona.. entonces el mensaje se golpeó y devuelve un 403.

Si puedo desactivar la protección, el post funciona… ¿qué tipo de protección que necesito para excluir de una lista para mantener la protección, pero permitir que estos puestos a través de?

Sólo recientemente he sido quemado por el nuevo Bastidor de protección de patadas en Heroku y me causa algo de dolor… alguien tiene un buen indicador de por qué hacemos aquí? La razón por la que digo eso, es que de repente estoy viendo las entradas de registro con alertas de secuestro de sesión temas (casi seguramente se debe a nada más que ejecutar > 1 Dinamómetro para la Aplicación). Veo rejilla de protección (1.2.0) en mi Gemfile.bloqueo aunque nunca me lo pidió… algo en mi manifiesto es que le pedían, por lo que se carga, pero nada en mi Aplicación Sinatra trata incluso de lo requieran o configurarlo.

Si tiene habilitado el registro debe mostrar que la protección era responsable, algo así como attack prevented by RemoteToken (con el registrador de preámbulo antes de ella).
Estoy viendo esto en la Rejilla de Protección 1.5.3. Esto no ocurrió con Rejilla de Protección eb7e4c9a176d.

OriginalEl autor David Lazar | 2012-05-09

5 Comentarios

  1. 17

    El uso de este en su aplicación Sinatra debería resolver su problema:

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

    Una mejor solución puede ser la actualización de Sinatra a 1.4, que utiliza Rack::Protección de la 1.5 y no debe causar el problema que usted está viendo.

    El problema es que su versión de RackProtection::JsonCsrf en es incompatible con CORS cuando usted responde con Content-Type: application/json. Aquí está un fragmento de la viejo json_csrf.rb en rack de protección:

    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
    

    Se puede ver este rechaza las solicitudes que tienen un application/json respuesta cuando el referente no es desde el mismo host que el servidor.

    Este problema fue resuelto en una versión posterior de la rejilla de protección, de la que ahora se examina si la solicitud es un 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
    

    Si usted está usando Sinatra 1.3.2 y no se puede actualizar la solución es desactivar esta protección especial. Con CORS que son explícitamente la habilitación de la cruz-dominio de peticiones XHR. Sinatra le permite desactivar la protección por completo, o deshabilitar componentes específicos de Rack::Protection (ver «Configuración De Protección Frente A Ataques» en el Sinatra docs).

    Rack::Protección proporciona 12 componentes de middleware que ayudar a derrotar a los ataques comunes:

    • 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

    Al momento de escribir, todos menos cuatro de estos se cargan automáticamente cuando se utiliza el Bastidor::Protección de middleware (Rack::Protection::AuthenticityToken, Rack::Protection::FormToken, Rack::Protection::RemoteReferrer, y Rack::Protection::EscapedParams debe ser añadido de forma explícita).

    Sinatra utiliza Rack::Protección de la configuración predeterminada con una excepción: sólo añade SessionHijacking y RemoteToken si habilita sesiones.

    Y, por último, si usted está tratando de utilizar CORS con Sinatra, usted puede tratar de rack-cors, que se ocupa de muchos de los detalles para usted.

    Pero en el archivo que pones esa línea? Confuso.

    OriginalEl autor Ryan

  2. 4

    Si usted ve este problema, no se está utilizando CORS (Cross-origin resource sharing), y está detrás de un proxy inverso (como nginx o apache), asegúrese de que el proxy inverso no está excluyendo host encabezado y reemplazarlo con localhost.

    Por ejemplo, en nginx necesita utilizar proxy_set_header:

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

    Cuando el encabezado es despojado de una solicitud, Rack::Protección cree que es un ataque CSRF.

    Tu post ha sido como un guante a mi la arquitectura, pero la adición de proxy_set_header Host $host; a mi nginx config, no resolverlo.

    OriginalEl autor Martin Konecny

  3. 3

    Déjame adivinar, tienes que probar con el Chrome app ‘Dev HTTP de Cliente’ ? Pruebe esto en su lugar:

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

    De la rejilla de protección del módulo:
    «Compatible navegadores: Google Chrome 2, Safari 4 y más tarde»

    Esto debería funcionar:

    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
    

    Usted probablemente se preguntará acerca de chrome-extension://aejoelaoggembcahagimdiliamlcdmfm ? Bueno, eso es lo que la rejilla de protección se presenta como env[‘HTTP_ORIGIN’] cuando usted envía una solicitud POST con el Chrome app.

    En una nueva aplicación Sinatra he tenido que cambiar de use Rack::Protection::HttpOrigin, origin_whitelist: ["chrome-extension://aejoelaoggembcahagimdiliamlcdmfm", "http://fizz.buzz.com"] A set :protection, origin_whitelist: ['chrome-extension://aejoelaoggembcahagimdiliamlcdmfm']

    OriginalEl autor Zoran Kikic

  4. 1

    Es este porque no devolver los métodos permitidos de vuelta en sus opciones de ruta?

    Una pregunta aquí se refiere a que las notas de los métodos permitidos de la espalda.

    Una extensión aquí y middleware aquí pueden ayudar a.

    No, yo soy la configuración de las opciones correctas. Yo permitir explícitamente el POST y, sin embargo, POST devuelve 403 forbidden. No estoy seguro de que la parte de la rejilla de protección es controlar eso. Los documentos no están del todo claro, y no parecen contener todo lo concerniente a la CORS.
    David, debo de haber estado en el espacio de la noche anterior. Puede que pruebe a establecer, use Rack::Protection, :except => :json_csrf? Alguien tiene un problema en rack::protección del repositorio git acerca de Rack::Protección y CORS así.

    OriginalEl autor al3xnull

Dejar respuesta

Please enter your comment!
Please enter your name here