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

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-19but
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.

On Mon, Jan 14, 2013 at 8:23 AM, Paul [email protected] wrote:

It did just appear and neither my web service nor the ActiveResource model
has changed recently.

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.

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?

On Mon, Jan 14, 2013 at 8:59 AM, Paul [email protected] wrote:

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

Read:
http://weblog.rubyonrails.org/2013/1/8/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.

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs