railsversion is susceptible to DOS attack via Mime type caching RB-A1008
Selected versions of Rails till version 4.2.5 do not properly restrict the use of the MIME type caches, which allows remote attackers to cause a denial of service (memory consumption) via a crafted HTTP Accept header. Upgrading to newer versions of Rails can help fix this issue.
sprocketsgem version is susceptible to path traversal vulnerability RB-A1009
Specially crafted requests can be used to access files that exist on the filesystem that is outside an application's root directory when the Sprockets server is used in production. Upgrading to newer versions of the gem can help fix this issue.
railsversion specified in Gemfile does not encode JSON keys RB-A1010
Hash containing user-controlled data is encode as JSON (either through
ActiveSupport::JSON.encode), Rails does not perform adequate escaping that matches the guarantee implied by the
escape_html_entities_in_json option (which is enabled by default). If this resulting JSON string is subsequently inserted directly into an HTML page, the page will be vulnerable to XSS attacks. Upgrading to newer versions of Rails can help fix this issue.
All versions of Rails below
220.127.116.11, and some versions of Rails 6 till
6.0.3 make it possible for an attacker to, given a global CSRF token such as the one present in the
authenticity_token meta tag, forge a per-form CSRF token.
Selected versions of Rails 2, 3 & 4 are vulnerable to denial of service attacks via XML. Upgrading to newer versions of Rails can help fix this issue.
Selected versions of Rails 2, 3 & 4 are vulnerable to file disclosures. Upgrading to newer versions of Rails or disabling serving of static assets, if enabled, can help fix this issue.
Selected versions of Rails 2 & 3 are vulnerable to ActiveRecord symbol denial of service attacks. Upgrading to newer versions of Rails can help fix this issue.
Selected versions of Rails till version 4.2.5 are susceptible to timing attack in basic auth. Upgrading to newer versions of Rails can help fix this issue.
i18ngem versions are vulnerable to cross-site scripting (XSS) RB-A1007
The internationalization component in Ruby on Rails 3.x before 3.2.16 and 4.x before 4.0.2 allow remote attackers to inject arbitrary web script or HTML via a crafted string that triggers generation of a fallback string by the i18n gem. Upgrading to newer versions of Rails & i18n gem can help fix this issue.
railsversion is vulnerable to DoS on using
Action View in Ruby on Rails 3.x before 3.2.17 converts MIME type strings to symbols during use of the
render: :text option, which allows remote attackers to cause a denial of service (memory consumption) by including these strings in headers. Upgrading to newer versions of Rails can help fix this issue.
IOclass must be avoided RB-A1012
Calls to methods in the
IO class must be avoided unless a command needs to be invoked intentionally.
_blank, but no
link_to that contain a
target: '_blank' but no
rel: 'noopener' can be a security risk, as the loaded page will have control over the previous page and could change its location for phishing purposes. The option
rel: 'noreferrer' also blocks this behavior and removes the
Avoid usage of weak cryptographic keys like MD5, SHA1 and HMAC.
Rails 3.1 introduced a callback
http_basic_authenticate_with to simplify basic authentication. You can simply pass a username and password
in plaintext to have a basic form of authentication. This especially is a big problem when the password is passed as plaintext, as it can be
Selected versions of Rails 3 contain the SafeBuffer bug. Upgrading to newer versions of Rails can help fix this issue.
Requests to secure endpoints must not be made without verifying the SSL certificate. It can be fixed by setting
use_ssl in the
Net::HTTP object to
Passing symbol arguments to source (e.g. source :rubygems) is deprecated because they default to using HTTP requests. Instead, specify 'https://rubygems.org' if possible, or 'http://rubygems.org' if not.
Binding#eval must never be used against untrusted user input.
These methods are meant to serialise data from trusted user input, like from your own database server or clients under your control, it could be dangerous to allow untrusted users to pass JSON sources into it.
load can deserialize almost any class loaded into the Ruby process. In many cases this can lead to remote code execution if the Marshal data is loaded from an untrusted source. As a result,
load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.