Package Instance

Possible ReDoS vulnerability in HTTP Token authentication in Action Controller
There is a possible ReDoS vulnerability in Action Controller's
HTTP Token authentication. This vulnerability has been assigned
the CVE identifier CVE-2024-47887.

## Impact

For applications using HTTP Token authentication via
`authenticate_or_request_with_http_token` or similar, a carefully
crafted header may cause header parsing to take an unexpected amount
of time, possibly resulting in a DoS vulnerability. All users running
an affected release should either upgrade or apply the relevant
patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications
using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends
on Ruby 3.2 or greater so is unaffected.

## Releases

The fixed releases are available at the normal locations.

## Workarounds

Users on Ruby 3.2 are unaffected by this issue.

## Credits

Thanks to [scyoon](https://hackerone.com/scyoon) for reporting

Improper Input Validation
The template selection functionality in actionpack/lib/action_view/template/resolver.rb in Ruby on Rails 3.0.x before 3.0.10 and 3.1.x before 3.1.0.rc6 does not properly handle glob characters, which allows remote attackers to render arbitrary views via a crafted URL, related to a "filter skipping vulnerability."

Possible Open Redirect Vulnerability in Action Pack
There is a possible Open Redirect Vulnerability in Action Pack. This
vulnerability has been assigned the CVE identifier CVE-2021-22903.

Versions Affected:  >= v6.1.0.rc2
Not affected:       < v6.1.0.rc2
Fixed Versions:     6.1.3.2

Impact
------
This is similar to CVE-2021-22881: Specially crafted Host headers in
combination with certain "allowed host" formats can cause the Host
Authorization middleware in Action Pack to redirect users to a malicious
website.

Since rails/rails@9bc7ea5, strings in config.hosts that do not have a leading
dot are converted to regular expressions without proper escaping. This causes,
for example, config.hosts << "sub.example.com" to permit a request with a Host
header value of sub-example.com.

Workarounds
-----------
The following monkey patch put in an initializer can be used as a workaround:

```ruby
class ActionDispatch::HostAuthorization::Permissions
  def sanitize_string(host)
    if host.start_with?(".")
      /\A(.+\.)?#{Regexp.escape(host[1..-1])}\z/i
    else
      /\A#{Regexp.escape host}\z/i
    end
  end
end
```

Improper Input Validation
Ruby on Rails 2.1 before 2.1.3 and 2.2.x before 2.2.2 does not verify tokens for requests with certain content types, which allows remote attackers to bypass cross-site request forgery (CSRF) protection for requests to applications that rely on this protection, as demonstrated using text/plain.

Cross-Site Request Forgery (CSRF)
Ruby on Rails 2.1.x, 2.2.x, and 2.3.x before 2.3.11, and 3.x before 3.0.4, does not properly validate HTTP requests that contain an X-Requested-With header, which makes it easier for remote attackers to conduct cross-site request forgery (CSRF) attacks via forged (1) AJAX or (2) API requests that leverage "combinations of browser plugins and HTTP redirects," a related issue to CVE-2011-0696.

Rails has possible XSS Vulnerability in Action Controller
# Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(`translate`, `t`, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected:  >= 7.0.0.
Not affected:       < 7.0.0
Fixed Versions:     7.1.3.1, 7.0.8.1

Impact
------
Applications using translation methods like `translate`, or `t` on a
controller, with a key ending in "_html", a `:default` key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

```ruby
class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end
```

To reiterate the pre-conditions, applications must:

* Use a translation function from a controller (i.e. _not_ I18n.t, or `t` from
  a view)
* Use a key that ends in `_html`
* Use a default value where the default value is untrusted and unescaped input
* Send the text to the victim (whether that's part of a template, or a
  `render` call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases
--------
The fixed releases are available at the normal locations.

Workarounds
-----------
There are no feasible workarounds for this issue.

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

*  7-0-translate-xss.patch - Patch for 7.0 series
*  7-1-translate-xss.patch - Patch for 7.1 series

Credits
-------

Thanks to [ooooooo_q](https://hackerone.com/ooooooo_q) for the patch and fix!

Translate helper method which may allow an attacker to insert arbitrary code into a page
The helper method for i18n translations has a convention whereby translations strings with a name ending in 'html' are considered HTML safe. There is also a mechanism for interpolation. It has been discovered that these 'html' strings allow arbitrary values to be contained in the interpolated input, and these values are not escaped.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The cross-site scripting (XSS) prevention feature in Ruby on Rails 2.x before 2.3.12, 3.0.x before 3.0.8, and 3.1.x before 3.1.0.rc2 does not properly handle mutation of safe buffers, which makes it easier for remote attackers to conduct XSS attacks via crafted strings to an application that uses a problematic string method, as demonstrated by the sub method.