ActiveResource: Disallowed type attribute: "symbol" in Rails 3.2.11

rubyonrails-talk
1

Has anyone started seeing the error:

Disallowed type attribute: “symbol”

when making an ActiveResource call after upgrading to Rails 3.2.11?

I found this blog entry which seems to completely describe the problem: http://techtime.getharvest.com/blog/activeresource-xml-bug-fix-for-rails-3-dot-0-19 but it claims that the problem was only in older versions of Rails.

There is a proposed fix for Rails 3.0, but that obviously wouldn’t help me.

I was wondering if the problem was in all versions of Rails, not just 3.0. It did just appear and neither my web service nor the ActiveResource model has changed recently.

2

That fix was brought into all currently maintained versions of Rails. You should not be symbolizing untrusted input anyways, unless you like opening up a world of hurt.

3

Thanks for the reply, Jordon.

I didn’t quite understand what you mean by “that fix”. Do you mean the security fix which caused my problem or the patch described by the blog post I mentioned above which might relieve my problem?

I’ve tracked down the line that I’m receiving from the web service that is causing the problem:

myvalue

Is my recommended action to change the value returned by the web service to be a string, then change my client so that it expects a string as a return value?

I’m not sure what is dangerous about interpreting a value as a symbol. Can you give me an example of what could replace myvalue that would create havoc?

4

I didn't quite understand what you mean by "that fix". Do you mean the security fix which caused my problem or the patch described by the blog post I mentioned above which might relieve my problem?

I've tracked down the line that I'm receiving from the web service that is causing the problem:

<myattr type="symbol">myvalue</src>

Read: Ruby on Rails — [SEC][ANN] Rails 3.2.11, 3.1.10, 3.0.19, and 2.3.15 have been released!

Is my recommended action to change the value returned by the web service to be a string, then change my client so that it expects a string as a return value?

Yes and use Hash fallbacks AKA Hash.new { } to convert symbol keys that you choose to use yourself (symbols you expect) back to the string keys so you can have indifferent access.

I'm not sure what is dangerous about interpreting a value as a symbol. Can you give me an example of what could replace myvalue that would create havoc?

Symbols are the only constant constant in Ruby. Once they are created they are created. Parsing user input into a symbol is dangerous because now all they need do keep sending you data with different values and eventually you get DOS'd because you've exhausted memory from all the symbols they've created for you.

In a normal situation most good sysadmins will have stuff that catch the rising memory and kill it and restart it long before that happens or has limits in place that prevent excessive memory and CPU usage (to an extent... meaning good sysadmins always make sure there are enough resources to recover from a disaster and leave the rest to the app) but that's a cat mouse game there and it's hard to figure out who is the cat and who is the mouse, it's better to just reject the symbol serialization flat out and save yourself the trouble.

5

Thanks for the explanation. That is useful. My problem now is that it appears that I can no longer use ActiveResource to consume this web service.

Note that this is a trusted web service: my Rails app is initiating the request using ActiveResource and I’m using a hardcoded URL that definitely goes to the trusted site.

I was able to consume the web service with:

doc = curl "#{created_url_by_hand}"

doc = doc.gsub(“type="symbol"”, “”)

doc = Hash.from_xml(doc)

There are some differences between the hash I receive that way and the object that would have been created, so I’m off to debugging land! Sigh.