Seaside vs Rails article: truth or FUD?

Guys,

Ran across this article this morning via Artima Buzz. Some of his comments raised my eyebrows, and I’d like to have your input on a few of them. Some, like “The Ruby runtime is not stable. I’ve crashed it repeatedly doing floating point math.”, don’t really concern me, as I’m not doing heavy floating point math anyway and can’t say I’ve crashed it yet. But others, like “very Rails form submission can change any attribute on an ActiveRecord
object unless the programmer has taken the affirmative step to filter
out the fields returned from a POST based on the fields put in the form
originally”, scare me…but more importantly, they scared my co-workers. I’ve been making a heavy case for switching from Java to Rails at my day job, but this article has given the naysayers in our group a LOT of fuel this morning.

Could someone help me refute these claims, or, if they’re true, can you help me describe how to protect against them?

Thanks!

Jake

Link to article:
https://www.lostlake.org/blog/index.php?/archives/7-Rails-and-Seaside-Two-new,-great-web-frameworks.html

That article feels decently biased towards SeaSide, so the author comes across as trying to point out every single little flaw with Ruby / Rails, while trying to praise SmallTalk / SeaSide. He completely neglects to mention that Ruby is effectively the next generation of SmallTalk, so the only difference here is that SeaSide seems to take a different philosophy than Rails.

How about this: don’t read people’s ‘experiences’ with Rails, go try it out for yourself. Take a week and spike a Rails site and then spike in another library you’re looking at. See which one you like better, and go with that.

As for that quote on AR objects and POSTing, I have an idea of what he’s talking about, but I don’t know what the author is trying to get at, he’ll have to post an example before I don’t see that quote as FUD. Same with the ‘crashing the Ruby runtime with floating point’.

Yes Ruby is slow, but comparing it to Java is apples and oranges for obvious reasons.

Jason

Could someone help me refute these claims, or, if they're true, can you help
me describe how to protect against them?

A few quick pointers.

Ruby strings are based on 8 bit characters. While there are a variety of UTF-8 libraries for Ruby,
basic methods like 'length' return the number of bytes, not characters, in a string

With Rails 1.2, you can do my_utf8_string.chars.length and get the
proper length. Same with truncate, first, and other character level
manipulations. So now you can easily manipulate UTF-8 in addition to
the fact that you've always been able to easily store and present
UTF-8.

Finally, the Ruby interpreter runs on Green Threads, so it can't make use of more than 1 CPU
on the new wave of SMP machines

With Rails, you run everything on processes, so this is a non-issue for
scaling a web application. The Shared Nothing approach is widely
regarded with excellent scaling properties, which the poster of this
also owns up to. And you get to scrap the pain and bugs of dealing with
threads.

It is almost entirely defined around the concept that a web page request translates into a
database query/update and the resultant display. This is true in the simple case.

I have no idea what this means and he does nothing to offer an
explanation for it. I think he's trying to say that Rails is primarily
for database-backed web applications. I'd agree with that.

...each page must be protected either with code in the controller

Where else should protection happen? The controller is exactly the stop
where requests are coming in and being handled. It's the obvious spot
to deal with access control. And we do. Additionally, we don't believe
that any one access control scheme fits all, so there's no default
access control in Rails. That's considered a feature, not a bug.

Objects pulled from the database must each be checked to see if they belong to the
user that is accessing them

But of course. Any access control would check whether the user has
access to the content. That's the nature and purpose of access control.
Rails makes this dead easy with patterns like:

  @current_user.tasks.find(params[:id]

Which restricts task-finding to those tasks that are available to only
the current user. Pretty simple idea, which is both transparent, easy,
and very secure.

Further, the Rails methodology of including database primary keys as part of the URL
perpetuates the issue because it's very easy to change the ID in the URL and see data
that belongs to others

Keh? Again, you should of course make sure that private records are
only accessible to the current user. The URL is not really part of that
equation. And it's done as simple as the example above.

[ Only user id in session ]. This means that making multi-step processes (e.g., checking out of
a store, managing a shopping cart) is very difficult and prone to failure.

First, that's a pattern of best practice, not a programming constraint.
If you want to keep more stuff in the session, go ahead. But it's
usually easier to scale and easier to maintain when you don't do that.
There are plenty of patterns for storing shopping carts in the database
that work very well.

COMET style web app development is very, very difficult

Continuously updating a page? Rich Killmer and I (mostly him) flicked
together a proof of concept for this at Etech during a COMET
presentation. I've demoed this a few times at conferences, but never
needed it for real, so it didn't move much. Sufficient to say, it was
not "very, very difficult". (Again, this is FUDing big time as he
offers no evidence, or even argument, as to why that should be so).

Rails also has a bunch of security vulnerabilities...

He goes on to mention 1 issue. One does not many make. And even if
there undoubtedly have been more, and will be more, this statement is
meaningless without context. He says he comes from Java. Has there
never been a security issue with Java or any of the frameworks in that
language? (Yes, just like any other language and framework).

This means that an attacker can change the primary key of an object by
appending ?foo_id=44 to a web post and voila, the object has a new primary key

No, it doesn't. Primary keys can't be set by bulk assignment. And any
other attribute you wish should remain protected from bulk assignment
can easily be done so through attr_protected (see
http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M000873).
(His example seems to confuse foreign and primary keys as well, so it's
pretty obvious he's out of depth.)

And even if you didn't know about that feature, you could still do as
you would in any framework that didn't do bulk-assignment. Just assign
by hand one-by-one.

There are other lurking vulnerabilities as well. But at this point in time,
Rails is as insecure as PHP was 5 years ago.

FUD-mongering at its best. Point to 1 incident, wave your hands about a
feature you didn't understand, and then allure to other mysterious
vulnerabilities.

For any application requiring complex user interaction or multiple user interaction,
Rails is not the best solution

Any assignment of medal is void without a definition of "best". Suffice
to say, lots of applications on Rails could be described under those
two labels. But whatever.

All that being said, Seaside is cool. I encourage you to check it out.
But hardly because of this "evaluation".

But others,
like "very Rails form submission can change any attribute on an ActiveRecord
object unless the programmer has taken the affirmative step to filter out
the fields returned from a POST based on the fields put in the form
originally",

Just use attr_protected for sensitive fields. That's the rails way to
handle sensitive data :slight_smile:
http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000873

-Pratik

I haven't looked at the other claims, however this one is true. It's part of why AR is so easy to work with and allows for magic like user = User.new(params[:user]). And it's very easy to secure, look at attr_protected and attr_accessible. The part about being able to overwrite ids is wrong, though, as far as I can tell.

Jakob Skjerning wrote:

But others, like "very Rails form submission can change any
attribute on an ActiveRecord object unless the programmer has taken
the affirmative step to filter out the fields returned from a POST
based on the fields put in the form originally", scare me...but
more importantly, they scared my co-workers.

I haven't looked at the other claims, however this one is true.

It's only true if you do stupid stuff and don't restrict the
universe of
what can be POST'd to an object. This isn't a vulnerability.

I have to disagree a little bit with you. It wouldn't be a
vulnerability if the default was to have attributes either
'attr_accessible' or 'attr_protected' and require the programmer to
over-ride this. Isn't it a problem that a programmer new to Rails has
to be aware of the problem then aware of the solution before
effective protection can be put in place? Keeping in mind that Rails,
with wonderful success, has made it very very easy to get started
without knowing a lot about Rails. I program in Rails but I don't use
ActiveRecord (at least not yet) so, maybe something is in place
already -- like a configuration item for AR and I just don't know
about it.

This seems to be a lot like the buffer overflow vulnerabilities we've
become so familiar with.

Cheers,
Bob

Here's a nice weblog post by Mathew Bass that seems appriate:

<http://www.matthewbass.com/blog/2006/11/26/using-protected-attributes-in-your-rails-models/>

Cheers,
Bob

Not sure I understand why this is really an issue. Sure, it’s wide-open
and forms just magically map to models if you use scaffolding. If you
don’t rely on scaffolding, then you’re free to implement things as you
see fit. Nobody forces you to pass the form collection to the model’s update_attributes or new methods. It’s good practice to protect fields in your database from
improper modification in any programming language; Rails is no
exception.

As for coworkers getting “scared” about this feature of Rails, they’d
probably do well to stay away then, because there’s bound to be even
more things that will scare them even more. :slight_smile:

A tablesaw cuts boards much faster than a handsaw. It’s also easier
once you learn how to use it. And if you use it improperly it can be
extremely dangerous. Very much like Rails, except Rails won’t cut your
hand off if you fail to pay attention.

Not sure I understand why this is really an issue. Sure, it's wide-
open and
forms just magically map to models if you use scaffolding. If you
don't rely
on scaffolding, then you're free to implement things as you see
fit. Nobody
forces you to pass the form collection to the model's
update_attributes or
new methods. It's good practice to protect fields in your database
from
improper modification in *any* programming language; Rails is no
exception.

I'm not sure how big an issue this is either. But consider a few
things. Rails is attracting a lot of attention, and good programmers
are trying it out. One of the really nice things about Rails is how
fast you can get going in it without really knowing a lot about
Rails. One of the nice things about Rails and Ruby is the nice high
level at which you are able to work and how 'safe' things are. I can
easily imagine it never crossing the mind of a good programmer that
that really cool and helpful idiom is potentially a Very Bad Thing.

I guess maybe the problem is not so much that there is a way to do
something stupid in Rails, but that it is so well disguised. It isn't
good enough to say that if the programmer was paying attention
there'd be no problem. If the programmer was paying attention in C
then we'd never have buffer overflow errors. Why do we have buffer
overflow errors anyway? *Everybody* working in C with any level of
competence knows all about buffer overflows, but they still happen.

I guess another problem is that if this ever happens in a prominent
Rails application then that really will be very bad press.

As for coworkers getting "scared" about this feature of Rails, they'd
probably do well to stay away then, because there's bound to be
even more
things that will scare them even more. :slight_smile:

Sounds to me as though they already are pretty scared, this just got
them going :slight_smile:

A tablesaw cuts boards much faster than a handsaw. It's also easier
once you
learn how to use it. And if you use it improperly it can be extremely
dangerous. Very much like Rails, except Rails won't cut your hand
off if
you fail to pay attention.

Cheers,
Bob