Перейти к файлу
Patrick Toomey 73bce05b02
Support deeply nested structures with TaintedHash
Before this change, any deeply nested strcuture would result in a regular Hash
being returned and ptoentially leaving an application open to mass assignment
issues.
    hash = {'a' => 1, 'b' => [{'c' => [{'d' => 2, 'e' => 3}]}]}
    tainted = TaintedHash.new hash
    class_type = tainted[:b][0][:c][0].class

In the above, class_type would be `Hash` instead of `TaintedHash`. So, we now
support deep tainting/untainting to prevent this.
2017-04-27 15:34:34 -06:00
lib Support deeply nested structures with TaintedHash 2017-04-27 15:34:34 -06:00
test Support deeply nested structures with TaintedHash 2017-04-27 15:34:34 -06:00
.gitignore nfi if this rails hack works (I'm on a plane) 2012-03-05 19:20:52 -08:00
LICENSE.md add a readme 2012-03-05 16:57:14 -07:00
README.md Update README.md 2012-03-09 19:05:18 -08:00
Rakefile nfi if this rails hack works (I'm on a plane) 2012-03-05 19:20:52 -08:00
tainted_hash.gemspec 0.3.4 2014-09-19 16:06:38 +10:00

README.md

Tainted Hash

A TaintedHash is a wrapper around a normal Hash that only exposes the keys that have been approved. This is useful in cases where a Hash is built from user input from an external service (such as Rails or Sinatra). By forcing the developer to approve keys, no unexpected keys are passed to data stores. Because of this specific use case, it is assumed all keys are strings.

By default, no keys have been approved.

hash = {'a' => 1, 'b' => 2, 'c' => 3}
tainted = TaintedHash.new hash

You can access keys manually to get the value and approve them:

Use #expose to expose keys.

tainted.include?(:a) # false
tainted['a'] # Returns 1
tainted[:a]  # Symbols are OK too.
tainted.include?(:a) # false, not exposed
tainted.expose :a
tainted.include?(:a) # true
tainted.keys # ['a']

If using Rails 2.3, require tainted_hash/rails to setup the necessary hooks. It amounts to little more than this:

def wrap_params_with_tainted_hash
  @_params = TaintedHash.new(@_params.to_hash)
end

Set this up as a before_filter early in the stack. However, it should run after filters like #filter_parameter_logging that needs to filter any key.

Note on Patches/Pull Requests

  1. Fork the project on GitHub.
  2. Make your feature addition or bug fix.
  3. Add tests for it. This is important so I don't break it in a future version unintentionally.
  4. Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
  5. Send me a pull request. Bonus points for topic branches.