CSRF protection from cross-origin <script> tags

[jeremy]

Extend protect_from_forgery to cover GET requests with JavaScript responses, protecting apps from cross-origin <script> embedding that may leak sensitive data.

TODO

• Changelog
• Update Security guide
• Test actions that use Accept rather than an explicit format
• Test actions that had neither .format nor Accept

[jeremy]

This content type comparison is gross but I couldn't find a better alternative.

[carlosantoniodasilva]

Can content type be some other like application/javascript?

[rafaelfranca]

I think so.

[rafaelfranca]

text/ecmascript and application/ecmascript are also valid values and I think there are more supported content types for javascript execution.

Whitelisting is not an option right?

[pier-oliviert]

unless I'm mistaken, doesn't the Mime types already take care of this?

request.format == :js && !request.xhr?

[jeremy]

@pothibo request.format is the requested format, not the response Content-Type.

For example, in #test_should_only_allow_same_origin_js_get_with_xhr_header:

> [content_type, request.format, rendered_format]
=> ["text/javascript", #<Mime::Type:0x007ff4d96d15e8 @synonyms=["application/xhtml+xml"], @symbol=:html, @string="text/html">, #<Mime::NullType:0x007ff4d8438530>]

[jeremy]

@rafaelfranca You'll only get those Content-Type if you manually specify them with render ..., type: 'application/ecmascript'. Mime::JS will always be text/javascript.

We may want a whitelist to extend verification to other Content-Type (including JSON for those supporting ancient browsers) in the future, but I don't think it's necessary to start.

[rafaelfranca]

👍

[acapilleri]

👍 Thanks!

[carlosantoniodasilva]

If people can skip verify_authenticity_token in a controller that inherits protect_from_forgery, then mark_for_same_origin_verification would still be triggered and thus verify_same_origin_request too, not? Would they need to skip that too, independently?

[jeremy]

Yes. I'll move the marker to verify_authenticity_token to fix that.

I used a separate, private method because we encourage people to change the builtin method:

      # The actual before_action that is used. Modify this to change how you handle unverified requests.
      def verify_authenticity_token

So an overriding method would miss the marking and skip same-origin verification.

I'm removing that comment. Shouldn't be overriding that method.

[rafaelfranca]

Tests are broken 😢

[rafaelfranca]

Extend protect_from_forgery to GET requests with JavaScript responses,

[jeremy]

@rafaelfranca fixed the other broken tests, they hit the same-origin verification 😁

[rafaelfranca]

[carlosantoniodasilva]

👍

[homakov]

@jeremy probably instead of exception it should respond with "please send x requested with header to verify request origin"

[jeremy]

@homakov thought about that.. responding with 403 Forbidden so it's clear it's a client error not an application error

App devs can use rescue_from to do that today. But then they'd never get exception emails / notifications and they remain ignorant of the issue. We do that with CSRF also, and it feels strange for an app to ignore unauthorized requests. We just don't have a good convention or API for alerting devs about attacks that were thwarted. Could do that with an AS notification channel: publish security events, let apps/plugins consume them and report and alert.

In any case, this is starting as small as possible. I hope we'll see PRs that do a default rescue_from for this exception, or add separate response strategies like CSRF token verification handling uses.

[jeremy]

@TechFounder Sounds like you're making a GET request that has a JavaScript response, but you aren't passing the X-Requested-With request header. You'll need to track down where and why.

[harmdewit]

In our production server i'm getting ActionController::InvalidCrossOriginRequest:Security warnings in my app for requests with format=*/*. The strange thing is that most requests are correctly called with format=js and some with the strange format=html and even fewer with format=*/*. Only the requests with format=*/* are raising the error and return status 500. I'm trying to reproduce requests with format=*/* but without success.

Am i seeing these inconsistencies because of browser differences? I'm using jquery-rails, is it incorrectly setting the dataType?

[masonforest]

@harmdewit did you ever figure this out? I'm having the same issue.

[harmdewit]

I'm not sure what the issue was after this long time but putting this into our ApplicationController seemed to fix it

+  def non_xhr_javascript_response?
+    unless request.get?
+      content_type =~ %r(\Atext/javascript) && !request.xhr?
+    end
+  end

[masonforest]

Thanks @harmdewit! 😃

[masonforest]

I'm not sure what is requesting format=/ either.

Another solution I came up with is to reorder the respond_to formats:

So I changed this:

respond_to do |format|
     format.js do
       ...
     end
     format.html
end

to this:

respond_to do |format|
     format.html
     format.js do
       ...
     end
end

That way format=/ will return html.