Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Latest Rails Exploit Is Indicative of a Bigger Problem

blog.sdelements.com

Post reply on HN
Print view View original

21–30 of 52 posts

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

#21

Post by adamors »

papsosouid wrote: post #15
bithive123 wrote: post #11

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".

>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…

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware

But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up?

Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.

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

#23

Post by ehsanf »

I believe over-engineering is also a culprit here. We had a similar situation in JSON handling in browser. Some over engineered feature allows custom objects to replace built in object for lists, allowing XSS through JSON parser. The solution was to make every REST API to start with a top level dictionary object. It just sounds arbitrary over engineering!!

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

#24

Post by alinajaf »

sanderjd wrote: post #16
bithive123 wrote: post #11

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…

> they mean that Rails has drawn that line quite far toward the abstraction side, which is true

Can you give a concrete example of this?

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

#25

Post by adamors »

bithive123 wrote: post #19
metaphorm wrote: post #13

Earlier quoted context omitted.

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".

It is meaningless and I have a growing suspicion that it was coined by people who came from writing (PHP) websites from scratch.

I remember being pleasantly surprised when I wrote my first website with a framework after a couple of years building sites from practically nothing.

Compared to frameworkless PHP, Rails is magic but then so is Django or ASP.NET MVC.

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

#26

Post by batiste »

metaphorm wrote: post #13
bithive123 wrote: post #11

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.

I thought the magic term had something to do with explicit vs implicit. Some framework just don't call that much code behind your back without explicitly calling stuff.

Rails is more oriented in a "convention over configuration" mindset, in this sense it might be more "magic" than others.

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

#27

Post by rambot »

tptacek wrote: post #18
static_typed wrote: post #5

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 the…

Where does the post suggest Rails is the only framework with bugs like this? The article opens with: "The latest Rails security flaw is example of a common anti-pattern. ... a similar issue may also exist in Python’s YAML parser ... I am reminded of similar flaws in other frameworks and libraries." I don't think the goal here was to pick on Rails, but to highlight that its recent security woes might be a sign of a bigger common issue.

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

#28

Post by metaphorm »

bithive123 wrote: post #19
metaphorm wrote: post #13

Earlier quoted context omitted.

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".

this isn't a good analogy. Rails is a software development framework whose users are programmers. iTunes is a media player whose users are non-technical. in other words Rails is a tool while iTunes is a finished product. you wouldn't compare a hammer with a cabinet, would you?

if zero-framework development is a hammer, then development with a framework is a power-tool combination drill/hammer/driver. the power-tool does so much more then the basic tool that it feels "magical". its not a meaningless term then. its a description of the power of the tool.

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

#29

Post by sanderjd »

alinajaf wrote: post #24
sanderjd wrote: post #16

Earlier quoted context omitted.

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…

> they mean that Rails has drawn that line quite far toward the abstraction side, which is true Can you give a concrete example of this?

Yes. When you write a controller action, you have access to what appears to be a hash called `params`, which is a representation of the parameters that the user passed in their request. It could be GET query parameters, or POST parameter data, or a parsed representation of JSON data. All of those different mechanisms are abstractions that Rails transparently provides. There are perhaps better examples in ActiveRecord, but that one seems more relevant.

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

#30

Post by tedunangst »

adamors wrote: post #21
papsosouid wrote: post #15

Earlier quoted context omitted.

>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…

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable…

I want my framework to do the boring stuff I don't want to do myself. That doesn't imply I want it running off and doing other things I don't even know about.
Post reply on HN