The main goal here is to get rid of the duplicate definitions of module
`IO`, which currently exist in both `frameworks/core/IO.qll` and
`frameworks/Files.qll`.
We do this by moving the classes inside `Files::IO` to `core/IO.qll`,
but moving most of the actual definitions of those classes to an
internal module `core.internal.FileOrIO`. This means both `Files.qll`
and `IO.qll` can depend on them without leaking them to end users.
Make ActionDispatch::Route into a private class
ActionDispatch::RouteImpl, defining a new class Route which exposes the
necessary public API from RouteImpl.
Also rename getHTTPMethod to getHttpMethod.
ActionDispatch modelling now understands that
match "/foo", to: "foo#bar", via: :all
is equivalent to
match "/foo",
to: "foo#bar",
via: [:get, :post, :put, :patch, :delete]
Add `Route` classes which model Rails routing information, typically
defined in a `routes.rb` file. We extract only the most basic
information: HTTP method, path, controller and action. This is enough to
determine whether a given controller method is a route handler, and what
HTTP method it handles, which is useful for, among other things, the URL
redirect query.
Module#const_get takes a single string argument and interprets it as the
name of a constant. It then looks up the constant and returns its value.
Object.const_get("Math::PI")
# => 3.141592653589793
By itself, this method is not as dangerous as e.g. eval, but if the
value returned is a class that is then instantiated, this can allow an
attacker to instantiate arbitrary Ruby classes.
As a result, I think it's safe to say that any remote input flowing into
this call is a potential vulnerability. A real-world example of this is
https://github.com/advisories/GHSA-52p9-v744-mwjj.
