Live data from Hacker News

Why the Latest Rails Exploit Is Indicative of a Bigger Problem

blog.sdelements.com

11–20 of 52 posts

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#11

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#12

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

weren't some of the security holes found in the json & yaml libraries? Those weren't rails specific and could have just as easily happened in a Sinatra-like framework too.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#13

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#15

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

>There is no magic in Rails, it's just Ruby code

In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware.

Pointing out that doing really bad things like this is bad is no more transparently self-serving that you claiming "oh rails is totally fine and doing stupid shit is cool because its not really magic". Yes, it is a systemic fundamental flaw in the framework. The entire framework is built from the ground up on the idea that doing this kind of nonsense is good.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#16

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured.

All software deals in layers of abstraction, which makes it easier to reason about general function, but obscures specific function. All users of all software must make a constant trade-off between assuming abstractions are functioning properly and personally verifying their function, and all software must decide where the line between too little abstraction and too much obscurity should be drawn. When people talk about the "magic" in Rails, they mean that Rails has drawn that line quite far toward the abstraction side, which is true.

There are some abstractions that are a net positive for security, and some that hinder it. While I don't agree with the condescending attitude of your parent and the many similar commenters, who seem to think no software they've ever written or integrated with has ever had a security issue, I think it is fair at this point to say that the level of abstraction in Rails' handling of user data has been a hindrance to its security. I think that is probably also a fair thing to say about most pieces of software that have ever handled potentially-malicious user data.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#17
post #3

Their server is down. Here's the content: -- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/ The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries. The iss…

Doesn't this get into the issue of whether XML dependency injection is a good idea? All of the wiring and some logic is built up in some files that are outside of the build/compilation process. Doing "proper dependency injection" (quotes for sarcasm) to me has always made me worry that I've lost control of how my application works, and somehow based on the right XML/JSON/etc config magic it will work perfectly and me…

Dependency injection and mass assignment/run-time execution of new code are two separate issues.

Although both are convenience niceties, the latter is based on user input while the former is not.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#18

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

Yes. No other security framework has ever had problems like Rails had. It's definitely not like enterprise Java frameworks that were designed from the outset to satisfy security demands from F-500 appsec teams have had repeated remote code execution flaws. And if they did, they definitely weren't as simple to trigger as "hitting a URL that maps to an embedded Java scripting language". No, only Rails has bugs like these.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#19

Earlier quoted context omitted.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

Then it's a meaningless term. The fact that iTunes doesn't need to ship with drivers for my sound card is the same kind of "magic".

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#20

Earlier quoted context omitted.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured. All software deals in layers of abstraction, which makes it easier to reason about general…

I would tend to agree, except that Rails can't be all things to all people. Experienced developers don't find it nearly as magical as most of the people being told to "just learn Rails" when they get interested in web development. I totally get that abstractions can obscure security issues, but some of the reactions I've been seeing to Rails having security issues are akin to a parent giving a child a dangerous toy without reading the instructions and then getting mad at the toy company when the child hurts itself.
Post reply on HN