brakeman-llm 0.0.1

data/docs/warning_types/http_verb_confusion/index.markdown

@@ -0,0 +1,42 @@
+---
+layout: page
+title: "HTTP Verb Confusion"
+date: 2020-10-23 15:21
+comments: false
+sharing: true
+footer: true
+---
+
+Ruby on Rails treats `HEAD` requests just like `GET` requests, except it drops the
+response body and does not return it to the client _and_ `request.get?` returns `false`.
+
+If code is assuming a request is either a `GET` or a `POST` and uses `request.get?` to check,
+then a `HEAD` request will be treated like a `POST` instead of a `GET`.
+This may trigger the wrong logic or allow a request to bypass CSRF protection
+(since `GET`/`HEAD` requests are not protected).
+
+[This post explains a vulnerability in GitHub](https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html)
+arising from this confusion.
+
+To avoid introducing a vulnerabilty with `request.get?`,
+either use completely separate routes and actions for `GET` vs `POST` (preferred!):
+
+```ruby
+get '/some/path', to: 'my_controller#some_action'
+post '/some/path', to: 'my_controller#a_different_action'
+```
+
+
+or else check `request.post?` explicitly:
+
+```ruby
+if request.get?
+  # do something
+elsif request.post?
+  # do something else
+end
+```
+
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/information_disclosure/index.markdown

@@ -0,0 +1,20 @@
+---
+layout: page
+title: "Information Disclosure"
+date: 2013-10-17 14:37
+comments: false
+sharing: true
+footer: true
+---
+
+Also known as [information leakage](https://www.owasp.org/index.php/Information_Leakage) or [information exposure](http://cwe.mitre.org/data/definitions/200.html), this vulnerability refers to system or internal information (such as debugging output, stack traces, error messages, etc.) which is displayed to an end user.
+
+For example, Rails provides detailed exception reports by default in the development environment, but it is turned off by default in production:
+
+    # Full error reports are disabled
+    config.consider_all_requests_local = false
+
+Brakeman warns if this setting is `true` in production or there is a `show_detailed_exceptions?` method in a controller which does not return `false`.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/link_to/index.markdown

@@ -0,0 +1,19 @@
+---
+layout: page
+title: "Cross Site Scripting: link\_to"
+date: 2012-07-11 11:36
+comments: false
+sharing: true
+footer: true
+---
+
+In the 2.x versions of Rails, `link_to` would not escape the body of the HREF.
+
+For example, this will popup an alert box:
+
+    link_to "<script>alert(1)</script>", "http://google.com"
+
+Brakeman warns on cases where the first parameter contains user input.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/link_to_href/index.markdown

@@ -0,0 +1,19 @@
+---
+layout: page
+title: "Cross Site Scripting: link\_to HREF"
+date: 2012-07-11 11:36
+comments: false
+sharing: true
+footer: true
+---
+
+Even though Rails will escape the link provided to `link_to`, values starting with "javascript:" or "data:" are unescaped and dangerous.
+
+Brakeman will warn on if user values are used to provide the HREF value in `link_to` or if they are interpolated at the beginning of a string.
+
+The `--url-safe-methods` option can be used to specify methods which make URLs safe. 
+
+See [here](https://github.com/presidentbeef/brakeman/pull/45) for more details.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/mass_assignment/index.markdown

@@ -0,0 +1,67 @@
+---
+layout: page
+title: "Mass Assignment"
+date: 2011-11-09 14:37
+comments: false
+sharing: true
+footer: true
+---
+
+Mass assignment is a feature of Rails which allows an application to create a record from the values of a hash.
+
+Example:
+
+    User.new(params[:user])
+
+Unfortunately, if there is a user field called `admin` which controls administrator access, now any user can make themselves an administrator with a query like
+
+    ?user[admin]=true
+
+### Rails With Strong Parameters
+
+In Rails 4 and newer, protection for mass assignment is on by default.
+
+Query parameters must be explicitly whitelisted via `permit` in order to be used in mass assignment:
+
+   User.new(params.permit(:name, :password))
+
+Care should be taken to only whitelist values that are safe for a user (or attacker) to set. Foreign keys such as `account_id` are likely unsafe, allowing an attacker to manipulate records belonging to other accounts.
+
+Brakeman will warn on potentially dangerous attributes that are whitelisted.
+
+Brakeman will also warn about uses of `params.permit!`, since that allows everything.
+
+
+### Rails Without Strong Parameters
+
+In older versions of Rails, `attr_accessible` and `attr_protected` can be used to limit mass assignment.
+However, Brakeman will warn unless `attr_accessible` is used, or mass assignment is completely disabled.
+
+There are two different mass assignment warnings which can arise. The first is when mass assignment actually occurs, such as the example above. This results in a warning like
+
+    Unprotected mass assignment near line 61: User.new(params[:user])
+
+The other warning is raised whenever a model is found which does not use `attr_accessible`. This produces generic warnings like
+
+    Mass assignment is not restricted using attr_accessible
+
+with a list of affected models.
+
+In Rails 3.1 and newer, mass assignment can easily be disabled:
+
+    config.active_record.whitelist_attributes = true
+
+Unfortunately, it can also easily be bypassed:
+
+    User.new(params[:user], :without_protection => true)
+
+Brakeman will warn on uses of `without_protection`.
+
+### More Information
+
+[Strong Parameters in Rails Security Guide](http://edgeguides.rubyonrails.org/action_controller_overview.html#strong-parameters)
+[Mass Assignment in Rails Security Guide](http://guides.rubyonrails.org/v3.2.8/security.html#mass-assignment)
+
+---
+
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/model_validation/index.markdown

@@ -0,0 +1,14 @@
+---
+layout: page
+title: "Format Validation"
+date: 2011-11-10 12:47
+comments: false
+sharing: true
+footer: true
+---
+
+<script>
+window.location.replace("http://brakemanscanner.org/docs/warning_types/format_validation/");
+</script>
+
+Content moved to [Format Validation](format_validation/).

data/docs/warning_types/path_traversal/index.markdown

@@ -0,0 +1,57 @@
+---
+layout: page
+title: "Path Traversal"
+date: 2024-01-24 16:01
+comments: false
+sharing: true
+footer: true
+---
+
+Path traversal vulnerabilities allow an attacker to access or manipulate files outside the intended
+directory by providing specially crafted paths as input to read or write sensitive data. This can occur when 
+improperly handling user-supplied input in filesystem-related operations such as image uploads, dynamic content loading, and user file downloads.
+
+An attacker could exploit a path traversal vulnerability to:
+
+* Read sensitive files, including configuration files or other data containing credentials or encryption keys.
+* Write files into restricted directories that enables code injection or privilege escalation.
+* Download or delete critical system files.
+* Gain access to user data and perform unauthorized actions.
+
+## Example
+
+```ruby
+# `params[:file][:path]` could contain "../../../../../etc/passwd", e.g.
+
+send_file File.join('some', 'path', params[:file][:path])
+```
+
+## Pathname Confusion
+
+`Pathname#join` has some confusing behavior: _any_ absolute path segment (e.g. starting with `/`) causes the path to be absolute from that point.
+
+Example:
+
+```
+> Pathname.new('a').join("a", "b", "/c", "d")
+ => #<Pathname:/c/d> 
+```
+
+Note that `Rails.root` is a `Pathname`.
+
+Exercise extreme caution when passing user-provided input to this function.
+
+### Additional Protections
+
+Besides coding defensively, there are additional options for protecting against path traversal:
+
+* Use the ActiveStorage module for handling uploaded files and store them in a service like S3, rather than storing user data on the same server or directory as the application.
+* Configure permissions on the application server to disallow writing files or reading files outside of the application directory.
+* Never include user-provided values in the file path or the file name.
+
+A common pattern is to store files using application-generated file names, but keep a record of the user-provided name. When the user downloads the file, the [`download`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download) attribute and/or the [Content Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header can be used to tell the browser the preferred name of the file, which can be the original user-provided name. Note that libraries like ActiveStorage will handle this for you.
+
+However, be careful if users can download files named by _other_ users. Overall, it is safer to generate file names from known-safe values.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/redirect/index.markdown

@@ -0,0 +1,60 @@
+---
+layout: page
+title: "Redirect"
+date: 2011-11-09 15:21
+comments: false
+sharing: true
+footer: true
+---
+
+Unvalidated redirects and forwards are #10 on the [OWASP Top Ten](https://web.archive.org/web/20190223031311/https://www.owasp.org/index.php/Top_10_2010-A10).
+
+Redirects which rely on user-supplied values can be used to "spoof" websites or hide malicious links in otherwise harmless-looking URLs. They can also allow access to restricted areas of a site if the destination is not validated.
+
+
+Brakeman will raise warnings whenever `redirect_to` appears to be used with a user-supplied value that may allow them to change the `:host` option.
+
+For example,
+
+    redirect_to params.merge(:action => :home)
+
+will create a warning like
+
+    Possible unprotected redirect near line 46: redirect_to(params)
+
+This is because `params` could contain `:host => 'evilsite.com'` which would redirect away from your site and to a malicious site.
+
+If the first argument to `redirect_to` is a hash, then adding `:only_path => true` will limit the redirect to the current host. Another option is to specify the host explicitly.
+
+    redirect_to params.merge(:only_path => true)
+
+    redirect_to params.merge(:host => 'myhost.com')
+
+If the first argument is a string, then it is possible to parse the string and extract the path:
+
+    redirect_to URI.parse(some_url).path
+
+**If the URL does not contain a protocol (e.g., `http://`), then you will probably get unexpected results, as `redirect_to` will prepend the current host name and a protocol.**
+
+### Rails 7 Updates
+
+If `config.action_controller.raise_on_open_redirects` is `true` (default for _new_ Rails 7.0 applications), then Rails will not allow redirecting to a domain that differs from the request.
+
+Even if the configuration setting is not `true`, the protection can be applied by setting `allow_other_host: false` explicitly:
+
+    redirect_to params[:url], allow_other_host: false
+
+The code above will raise an exception if `params[:url]` does not match the current domain.
+
+Brakeman will warn about calls where `allow_other_host` is set to `true`.
+
+To coerce the URL to be "safe", use [`url_from`](https://api.rubyonrails.org/v7.0/classes/ActionController/Redirecting.html#method-i-url_from):
+
+    redirect_to url_from(params[:url])
+
+If the URL is does not match the current domain, then `url_from` returns `false`. The recommended pattern is to provide a fallback:
+
+    redirect_to url_from(params[:url]) || some_safe_default_url
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/remote_code_execution/index.markdown

@@ -0,0 +1,17 @@
+---
+layout: page
+title: "Remote Code Execution"
+date: 2013-03-01 11:22
+comments: false
+sharing: true
+footer: true
+---
+
+Brakeman reports on several cases of remote code execution, in which a user is able to control and execute code in ways unintended by application authors.
+
+The obvious form of this is the use of `eval` with user input.
+
+However, Brakeman also reports on dangerous uses of `send`, `constantize`, and other methods which allow creation of arbitrary objects or calling of arbitrary methods.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/remote_code_execution_yaml_load/index.markdown

@@ -0,0 +1,19 @@
+---
+layout: page
+title: "Remote Code Execution in YAML.Load"
+date: 2013-01-18 17:08
+comments: false
+sharing: true
+footer: true
+---
+
+As seen in [CVE-2013-0156](https://groups.google.com/d/topic/rubyonrails-security/61bkgvnSGTQ/discussion), calling `YAML.load` with user input can lead to remote execution of arbitrary code. (To see a real point-and-fire exploit, see the [Metasploit payload](https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/http/rails_xml_yaml_code_exec.rb)). While upgrading Rails, disabling XML parsing, or disabling YAML types in XML request parsing will fix the Rails vulnerability, manually passing user input to `YAML.load` remains unsafe.
+
+For example:
+
+    #Do not do this!
+    YAML.load(params[:file])
+
+---
+
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/session_manipulation/index.markdown

@@ -0,0 +1,28 @@
+---
+layout: page
+title: "Session Manipulation"
+date: 2015-12-28 07:43
+comments: false
+sharing: true
+footer: true
+---
+
+Session manipulation can occur when an application allows user-input in session keys.
+Since sessions are typically considered a source of truth (e.g. to check the logged-in user or to match CSRF tokens),
+allowing an attacker to manipulate the session may lead to unintended behavior.
+
+For example:
+
+    user_id = session[params[:name]]
+    current_user = User.find(user_id)
+
+In this scenario, the attacker can point the `name` parameter to some other session value (for example, `_csrf_token`) that will be interpreted
+as a user ID. If the ID matches an existing account, the attacker will now have access to that account.
+
+To prevent this type of session manipulation, avoid using user-supplied input as session keys.
+
+([See here for a tiny, self-contained challenge demonstrating this issue](https://gist.github.com/joernchen/9dfa57017b4732c04bcc).)
+
+---
+
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/session_setting/index.markdown

@@ -0,0 +1,24 @@
+---
+layout: page
+title: "Session Settings"
+date: 2011-11-10 16:15
+comments: false
+sharing: true
+footer: true
+---
+
+### HTTP Only
+
+It is recommended that session cookies be set to "http-only". This helps prevent stealing of cookies via cross site scripting.
+
+### Secret Length
+
+Brakeman will warn if the key length for the session cookies is less than 30 characters.
+
+### Version control inclusion
+
+Brakeman will warn if the config/initializers/secret_token.rb is included in the version control. It is recommended that secret_token.rb is excluded from version control, and included in .gitignore
+
+---
+Back to [Warning Types](/docs/warning_types)
+

data/docs/warning_types/session_settings/index.markdown

@@ -0,0 +1,18 @@
+---
+layout: page
+title: "Session Settings"
+date: 2011-11-10 16:15
+comments: false
+sharing: true
+footer: true
+---
+
+<script>
+window.location.replace("http://brakemanscanner.org/docs/warning_types/session_setting/");
+</script>
+
+Content has moved to [Session Setting](/docs/warning_types/session_setting/)
+
+---
+Back to [Warning Types](/docs/warning_types)
+

data/docs/warning_types/sql_injection/index.markdown

@@ -0,0 +1,41 @@
+---
+layout: page
+title: "SQL Injection"
+date: 2011-11-09 14:12
+comments: false
+sharing: true
+footer: true
+---
+
+Injection is #1 on the 2010 [OWASP Top Ten](https://web.archive.org/web/20190223031311/https://www.owasp.org/index.php/Top_10_2010-A1) web security risks. SQL injection is when a user is able to manipulate a value which is used unsafely inside a SQL query. This can lead to data leaks, data loss, elevation of privilege, and other unpleasant outcomes.
+
+Brakeman focuses on ActiveRecord methods dealing with building SQL statements.
+
+A basic (Rails 2.x) example looks like this:
+
+    User.first(:conditions => "username = '#{params[:username]}'")
+
+Brakeman would produce a warning like this:
+
+    Possible SQL injection near line 30: User.first(:conditions => ("username = '#{params[:username]}'")) 
+
+The safe way to do this query is to use a parameterized query:
+
+    User.first(:conditions => ["username = ?", params[:username]])
+
+Brakeman also understands the new Rails 3.x way of doing things (and local variables and concatentation):
+
+    username = params[:user][:name].downcase
+    password = params[:user][:password]
+
+    User.first.where("username = '" + username + "' AND password = '" + password + "'")
+
+This results in this kind of warning:
+
+    Possible SQL injection near line 37:
+    User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
+
+See [the Ruby Security Guide](http://guides.rubyonrails.org/security.html#sql-injection) for more information and [Rails-SQLi.org](http://rails-sqli.org) for many examples of SQL injection in Rails.
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/ssl_verification_bypass/index.markdown

@@ -0,0 +1,41 @@
+---
+layout: page
+title: "SSL Verification Bypass"
+date: 2014-01-06 17:27
+comments: false
+sharing: true
+footer: true
+---
+
+Simply using SSL isn't enough to ensure the data you are sending is secure. Man in the middle (MITM) attacks are well known and widely used. In some cases, these attacks rely on the client to establish a connection that doesn't check the validity of the SSL certificate presented by the server. In this case, the attacker can present their own certificate and act as a man in the middle.
+
+In Ruby, this happens when the OpenSSL verification mode is set to `VERIFY_NONE`
+
+    require "net/https"
+	require "uri"
+
+	uri = URI.parse("https://ssl-site.com/")
+	http = Net::HTTP.new(uri.host, uri.port)
+	http.use_ssl = true
+	http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+	request = Net::HTTP::Get.new(uri.request_uri)
+
+	response = http.request(request)
+
+In this case, if an invalid certificate was presented, no verification would occur, providing an opportunity for attack. When successful, the data transmitted (cookies, request parameters, POST bodies, etc.) would all be able to be intercepted by the MITM.
+
+Brakeman would produce a warning like this:
+
+    SSL certificate verification was bypassed near line 24: http.verify_mode = OpenSSL::SSL::VERIFY_NONE
+
+To ensure that SSL verification happens use the following mode:
+
+    http.verify_mode = OpenSSL::SSL::VERIFY_PEER
+
+If the server certificate is invalid or context.ca_file is not set when verifying peers an OpenSSL::SSL::SSLError will be raised.
+
+For more information on the impact of this issue, see the paper [The Most Dangerous Code in the World](https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf).
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/unmaintained_dependency/index.markdown

@@ -0,0 +1,33 @@
+---
+layout: page
+title: "Unmaintained Dependencies"
+date: 2024-01-24 16:01
+comments: false
+sharing: true
+footer: true
+---
+
+Unmaintained or "end-of-life" dependencies can present security risks to your application.
+
+When a dependency is no longer maintained, its developers may not release new versions with security patches for known 
+vulnerabilities. This means that any known vulnerabilities in the dependency remain unpatched, leaving your application open to attacks.
+
+In addition to known vulnerabilities, older versions of software are likely to receive less scrutiny
+are more likely to contain vulnerabilities that are not published and do not receive any public attention.
+
+Maintained dependencies are also more likely to follow security best practices, such as using secure coding practices, 
+regularly testing for vulnerabilities, and providing timely security patches. Outdated dependencies may not follow these best practices, increasing the 
+risk of security vulnerabilities.
+
+As a library ages, it is more likely to be completely abandoned or forgotten by its creator.
+Abandoned libraries may become target for supply chain attacks, where the attacker takes over an old code repository or
+an account on a package management server (such as RubyGems) and publishes a malicious version of the software.
+
+## Ruby and Rails
+
+Ruby versions are generally maintained for 3 years and 3 months after release. Check [the listing of maintenance branches](https://www.ruby-lang.org/en/downloads/branches/) for more information.
+
+Rails is more complicated, but generally only the current series and the last of the previous series is supported. See the [Rails Maintenance Policy](https://guides.rubyonrails.org/maintenance_policy.html#security-issues).
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/unsafe_deserialization/index.markdown

@@ -0,0 +1,17 @@
+---
+layout: page
+title: "Unsafe Deserialization"
+date: 2013-05-17 14:37
+comments: false
+sharing: true
+footer: true
+---
+
+Objects in Ruby may be serialized to strings. The main method for doing so is the built-in `Marshal` class. The `YAML`, `JSON`, and `CSV` libraries also have methods for dumping Ruby objects into strings, and then creating objects from those strings.
+
+Deserialization of arbitrary objects can lead to [remote code execution](/docs/warning_types/remote_code_execution), as was demonstrated with [CVE-2013-0156](https://groups.google.com/d/msg/rubyonrails-security/61bkgvnSGTQ/nehwjA8tQ8EJ). 
+
+Brakeman warns when loading user input with `Marshal`, `YAML`, or `CSV`. `JSON` is covered by the checks for [CVE-2013-0333](https://groups.google.com/d/msg/rubyonrails-security/1h2DR63ViGo/GOUVafeaF1IJ)
+
+---
+Back to [Warning Types](/docs/warning_types)

data/docs/warning_types/unscoped_find/index.markdown

@@ -0,0 +1,25 @@
+---
+layout: page
+title: "Unscoped Find"
+date: 2014-10-14 08:48
+comments: false
+sharing: true
+footer: true
+---
+
+Unscoped `find` (and related methods) are a form of [Direct Object Reference](https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References). Models which belong to another model should typically be accessed via a scoped query.
+
+For example, if an `Account` belongs to a `User`, then this may be an unsafe unscoped find:
+
+    Account.find(params[:id])
+
+Depending on the action, this could allow an attacker to access any account they wish.
+
+Instead, it should be scoped to the currently logged-in user:
+
+    current_user = User.find(session[:user_id])
+    current_user.accounts.find(params[:id])
+
+---
+
+Back to [Warning Types](/docs/warning_types)