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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On 11/20/06, Jake Cutter <cutter38-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > 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 > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 stringWith 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 machinesWith 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 controllerWhere 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 themBut 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 othersKeh? 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 difficultContinuously 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 keyNo, 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 solutionAny 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". --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 :-) http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000873 -Pratik -- rm -rf / 2>/dev/null - http://null.in Dont judge those who try and fail, judge those who fail to try.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jakob Skjerning
2006-Nov-20 20:02 UTC
Re: [POSSIBLE SPAM] [Rails] Seaside vs Rails article: truth or FUD?
On Nov 20, 2006, at 15:59 , Jake Cutter 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 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 - http://mentalized.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Daniel Collis-puro
2006-Nov-20 22:10 UTC
Re: [POSSIBLE SPAM] [Rails] Seaside vs Rails article: truth
Jakob Skjerning wrote:> On Nov 20, 2006, at 15:59 , Jake Cutter 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. -DJCP -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Bob Hutchison
2006-Nov-26 17:46 UTC
Re: [POSSIBLE SPAM] [Rails] Seaside vs Rails article: truth
On 20-Nov-06, at 5:10 PM, Daniel Collis-puro wrote:> > Jakob Skjerning wrote: >> On Nov 20, 2006, at 15:59 , Jake Cutter 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> > -DJCP > > > -- > Posted via http://www.ruby-forum.com/. > > >---- Bob Hutchison -- blogs at <http://www.recursive.ca/ hutch/> Recursive Design Inc. -- <http://www.recursive.ca/> Raconteur -- <http://www.raconteur.info/> xampl for Ruby -- <http://rubyforge.org/projects/xampl/> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Brian Hogan
2006-Nov-27 03:24 UTC
Re: [POSSIBLE SPAM] [Rails] Seaside vs Rails article: truth
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. :) 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. On 11/26/06, Bob Hutchison <hutch-QkQvdf7W/+5AFePFGvp55w@public.gmane.org> wrote:> > > > On 20-Nov-06, at 5:10 PM, Daniel Collis-puro wrote: > > > > > Jakob Skjerning wrote: > >> On Nov 20, 2006, at 15:59 , Jake Cutter 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 > > > > > -DJCP > > > > > > -- > > Posted via http://www.ruby-forum.com/. > > > > > > > ---- > Bob Hutchison -- blogs at <http://www.recursive.ca/ > hutch/> > Recursive Design Inc. -- <http://www.recursive.ca/> > Raconteur -- <http://www.raconteur.info/> > xampl for Ruby -- <http://rubyforge.org/projects/xampl/> > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Bob Hutchison
2006-Nov-28 14:04 UTC
Re: [POSSIBLE SPAM] [Rails] Seaside vs Rails article: truth
On 26-Nov-06, at 10:24 PM, Brian Hogan wrote:> 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. :)Sounds to me as though they already are pretty scared, this just got them going :-)> > 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> > On 11/26/06, Bob Hutchison <hutch-QkQvdf7W/+5AFePFGvp55w@public.gmane.org> wrote: >> >> >> >> On 20-Nov-06, at 5:10 PM, Daniel Collis-puro wrote: >> >>> >>> Jakob Skjerning wrote: >>>> On Nov 20, 2006, at 15:59 , Jake Cutter 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 >> >>> >>> -DJCP >>> >>> >>> -- >>> Posted via http://www.ruby-forum.com/. >>> >>>> >> >> ---- >> Bob Hutchison -- blogs at <http://www.recursive.ca/ >> hutch/> >> Recursive Design Inc. -- <http://www.recursive.ca/> >> Raconteur -- <http://www.raconteur.info/> >> xampl for Ruby -- <http://rubyforge.org/projects/ >> xampl/> >> >> >> >> >>> >> > > >---- Bob Hutchison -- blogs at <http://www.recursive.ca/ hutch/> Recursive Design Inc. -- <http://www.recursive.ca/> Raconteur -- <http://www.raconteur.info/> xampl for Ruby -- <http://rubyforge.org/projects/xampl/> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---