Merge branch 'master' into adequaterecord

* master: (311 commits)
  Add a missing changelog entry for #13981 and #14035
  Revert "Fixed plugin_generator test"
  implements new option :month_format_string for date select helpers [Closes #13618]
  add factory methods for empty alias trackers
  guarantee a list in the alias tracker so we can remove a conditional
  stop exposing table_joins
  make most parameters to the AliasTracker required
  make a singleton for AssociationScope
  pass the association and connection to the scope method
  pass the tracker down the stack and construct it in the scope method
  clean up add_constraints signature
  remove the reflection delegate
  remove klass delegator
  remove railties changes. fixes #14054
  remove chain delegate
  remove scope_chain delegate
  Add verb to sanitization note
  fix path shown in mailer's templates
  updated Travis build status image url
  fix guide active_support_core_extensions. add Note to String#indent [ci skip]
  ...

Conflicts:
	activerecord/lib/active_record/associations/join_dependency.rb
	activerecord/test/cases/associations/association_scope_test.rb

1 files changed, 44 insertions, 1 deletions

diff --git a/guides/source/security.md b/guides/source/security.md
index cffe7c85f1..ece431dae7 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -549,7 +549,7 @@ Injection is very tricky, because the same code or parameter can be malicious in
 
 ### Whitelists versus Blacklists
 
-NOTE: _When sanitizing, protecting or verifying something, whitelists over blacklists._
+NOTE: _When sanitizing, protecting or verifying something, prefer whitelists over blacklists._
 
 A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_:
 
@@ -915,6 +915,49 @@ Content-Type: text/html
 
 Under certain circumstances this would present the malicious HTML to the victim. However, this only seems to work with Keep-Alive connections (and many browsers are using one-time connections). But you can't rely on this. _In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks._
 
+Unsafe Query Generation
+-----------------------
+
+Due to the way Active Record interprets parameters in combination with the way
+that Rack parses query parameters it was possible to issue unexpected database
+queries with `IS NULL` where clauses. As a response to that security issue
+([CVE-2012-2660](https://groups.google.com/forum/#!searchin/rubyonrails-security/deep_munge/rubyonrails-security/8SA-M3as7A8/Mr9fi9X4kNgJ),
+[CVE-2012-2694](https://groups.google.com/forum/#!searchin/rubyonrails-security/deep_munge/rubyonrails-security/jILZ34tAHF4/7x0hLH-o0-IJ)
+and [CVE-2013-0155](https://groups.google.com/forum/#!searchin/rubyonrails-security/CVE-2012-2660/rubyonrails-security/c7jT-EeN9eI/L0u4e87zYGMJ))
+`deep_munge` method was introduced as a solution to keep Rails secure by default.
+
+Example of vulnerable code that could be used by attacker, if `deep_munge`
+wasn't performed is:
+
+```ruby
+unless params[:token].nil?
+  user = User.find_by_token(params[:token])
+  user.reset_password!
+end
+```
+
+When `params[:token]` is one of: `[]`, `[nil]`, `[nil, nil, ...]` or
+`['foo', nil]` it will bypass the test for `nil`, but `IS NULL` or
+`IN ('foo', NULL)` where clauses still will be added to the SQL query.
+
+To keep rails secure by default, `deep_munge` replaces some of the values with
+`nil`. Below table shows what the parameters look like based on `JSON` sent in
+request:
+
+| JSON                              | Parameters               |
+|-----------------------------------|--------------------------|
+| `{ "person": null }`              | `{ :person => nil }`     |
+| `{ "person": [] }`                | `{ :person => nil }`     |
+| `{ "person": [null] }`            | `{ :person => nil }`     |
+| `{ "person": [null, null, ...] }` | `{ :person => nil }`     |
+| `{ "person": ["foo", null] }`     | `{ :person => ["foo"] }` |
+
+It is possible to return to old behaviour and disable `deep_munge` configuring
+your application if you are aware of the risk and know how to handle it:
+
+```ruby
+config.action_dispatch.perform_deep_munge = false
+```
 
 Default Headers
 ---------------