There is a possible XSS vulnerability in ActionView’s JavaScript literal escape helpers. Views that use the j or escape_javascript methods may be susceptible to XSS attacks.

Versions Affected: All. Not affected: None. Fixed Versions: 6.0.2.2, 5.2.4.2

Impact

There is a possible XSS vulnerability in the j and escape_javascript methods in ActionView. These methods are used for escaping JavaScript string literals. Impacted code will look something like this:

<script>let a = `<%= j unknown_input %>`</script>

or

<script>let a = `<%= escape_javascript unknown_input %>`</script>

Releases

The 6.0.2.2 and 5.2.4.2 releases are available at the normal locations.

Workarounds

For those that can’t upgrade, the following monkey patch may be used:

ActionView::Helpers::JavaScriptHelper::JS_ESCAPE_MAP.merge!(
  {
    "`" => "\\`",
    "$" => "\\$"
  }
)

module ActionView::Helpers::JavaScriptHelper
  alias :old_ej :escape_javascript
  alias :old_j :j

  def escape_javascript(javascript)
    javascript = javascript.to_s
    if javascript.empty?
      result = ""
    else
      result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"']|[`]|[$])/u, JS_ESCAPE_MAP)
    end
    javascript.html_safe? ? result.html_safe : result
  end

  alias :j :escape_javascript
end

~> 5.2.4 >= 5.2.4.2 >= 6.0.2.2

n/a

n/a

There is an vulnerability in rails-ujs that allows attackers to send CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3 Not affected: Applications which don’t use rails-ujs. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or the action attribute of a form tag that will trigger a POST action, the attacker can set the href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:

link_to params

to code like this:

link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

~> 5.2.4.3 >= 6.0.3.1

n/a

n/a

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3 Not affected: rails < 4.0.0 Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from Strong Parameters. Specifically the return value of each, or each_value, or each_pair will return the underlying “untrusted” hash of data that was read from the parameters. Applications that use this return value may be inadvertently use untrusted user input.

Impacted code will look something like this:

def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end

Note the mistaken use of each in the clean_up_params method in the above example.

Workarounds

Do not use the return values of each, each_value, or each_pair in your application.

~> 5.2.4.3 >= 6.0.3.1

< 4.0.0

n/a

There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when untrusted user input is written to the cache store using the raw: true parameter, re-reading the result from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

data = cache.fetch("demo", raw: true) { untrusted_string }

Versions Affected: rails < 5.2.5, rails < 6.0.4 Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum, this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.

In addition to upgrading to the latest versions of Rails, developers should ensure that whenever they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes, detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using the raw argument should be double-checked to ensure that they conform to the expected format.

~> 5.2.4.3 >= 6.0.3.1

n/a

n/a

It is possible to possible to, given a global CSRF token such as the one present in the authenticity_token meta tag, forge a per-form CSRF token for any action for that session.

Versions Affected: rails < 5.2.5, rails < 6.0.4 Not affected: Applications without existing HTML injection vulnerabilities. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Given the ability to extract the global CSRF token, an attacker would be able to construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

~> 5.2.4.3 >= 6.0.3.1

n/a

n/a