6 ms·

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineerin

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.

ef4 14y ago
The problem isn't "magic" per se, and the problematic components already have very clearly defined singular responsibilities (an API doesn't get much simpler than "dump" and "parse"). Security problems often happen when two components that are perfectly safe in their original contexts are tied together in a way that their designers didn't intend. These parser problems are examples of that. So it's actually a good thing that frameworks like Rails try to tie together many components for you "magically". The integration of all those little simple pieces is always a chance to screw up security. It's better to do that hard work once, collaboratively as a community, than to have every developer make those risky choices separately every single time. It's the same cost/benefit analysis that explains why you should never roll your own crypto. Anybody can make a system that's "secure" enough to keep themselves from breaking it, but that's not nearly good enough. You increase security by increasing scrutiny.
bithive123 14y ago
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".
- metaphorm 14y ago
  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.
  - bithive123 14y ago
    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".
    - adamors 14y ago
      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.
    - metaphorm 14y ago
      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.
  - batiste 14y ago
    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.
  - deleted 14y ago
    [deleted]
  - hackinthebochs 14y ago
    "Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
- papsosouid 14y ago
  >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.
  - adamors 14y ago
    > 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.
    - tedunangst 14y ago
      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.
    - papsosouid 14y ago
      No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
    - 14y ago
- sanderjd 14y ago
  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.
  - bithive123 14y ago
    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.
    - sanderjd 14y ago
      I think we agree on all points. People with less experience with Rails see "magic" where people with more experience see abstractions with all the trade-offs implied, and importantly, know how to dig into those abstractions to understand what is really going on. But that digging in process tends to be spurred by surprising behavior, rather than security consciousness. I like your analogy to toys and children, except that the danger of these toys is not immediately apparent to adults either. But the toy company has been very prompt and transparent in finding ways for people to avoid the danger once it becomes apparent.
catch23 14y ago
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.
tptacek 14y ago
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.
- rambot 14y ago
  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.
  - tptacek 14y ago
    I'm responding to the comment above, not the post.
    - ScottBurson 14y ago
      I don't read the comment in question as picking on Rails either ("... frameworks like Rails", it says). Please see my comment downthread.
      - tptacek 14y ago
        "Frameworks like every framework" seems like an unintended but accurate generalization that was worth pointing out.
ScottBurson 14y ago
Let's get specific, because there's a point here that I think a lot of people are missing (including tptacek). ActionDispatch::Routing::RouteSet::NamedRouteCollection.add calls 'eval' on the property name passed to it. This invites exploitation. It also fails 'static_typed's desideratum of each component having a single responsibility. And I don't think calling it "magic" is too strong. I don't know to what extent the Ruby culture encourages calling 'eval' in random API routines like this, but when I previously argued here on HN that that had to be a bad idea, I got some pushback. I would certainly call this a dangerous anti-pattern. EDITED to add: reference: http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/ http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look...
- stouset 14y ago
  I consider myself an expert in Ruby style and best practices. And I have never and would never write code that uses `eval`, outside of toy projects. There are probably ways you can use it safely. But it's not worth the risk.

ef4 14y ago

The problem isn't "magic" per se, and the problematic components already have very clearly defined singular responsibilities (an API doesn't get much simpler than "dump" and "parse"). Security problems often happen when two components that are perfectly safe in their original contexts are tied together in a way that their designers didn't intend. These parser problems are examples of that. So it's actually a good thing that frameworks like Rails try to tie together many components for you "magically". The integration of all those little simple pieces is always a chance to screw up security. It's better to do that hard work once, collaboratively as a community, than to have every developer make those risky choices separately every single time. It's the same cost/benefit analysis that explains why you should never roll your own crypto. Anybody can make a system that's "secure" enough to keep themselves from breaking it, but that's not nearly good enough. You increase security by increasing scrutiny.

bithive123 14y ago

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

metaphorm 14y ago
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.
- bithive123 14y ago
  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".
  - adamors 14y ago
    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.
  - metaphorm 14y ago
    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.
- batiste 14y ago
  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.
- deleted 14y ago
  [deleted]
- hackinthebochs 14y ago
  "Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
papsosouid 14y ago
>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.
- adamors 14y ago
  > 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.
  - tedunangst 14y ago
    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.
  - papsosouid 14y ago
    No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
  - 14y ago
sanderjd 14y ago
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.
- bithive123 14y ago
  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.
  - sanderjd 14y ago
    I think we agree on all points. People with less experience with Rails see "magic" where people with more experience see abstractions with all the trade-offs implied, and importantly, know how to dig into those abstractions to understand what is really going on. But that digging in process tends to be spurred by surprising behavior, rather than security consciousness. I like your analogy to toys and children, except that the danger of these toys is not immediately apparent to adults either. But the toy company has been very prompt and transparent in finding ways for people to avoid the danger once it becomes apparent.

catch23 14y ago

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.

tptacek 14y ago

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.

rambot 14y ago
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.
- tptacek 14y ago
  I'm responding to the comment above, not the post.
  - ScottBurson 14y ago
    I don't read the comment in question as picking on Rails either ("... frameworks like Rails", it says). Please see my comment downthread.
    - tptacek 14y ago
      "Frameworks like every framework" seems like an unintended but accurate generalization that was worth pointing out.

ScottBurson 14y ago

Let's get specific, because there's a point here that I think a lot of people are missing (including tptacek). ActionDispatch::Routing::RouteSet::NamedRouteCollection.add calls 'eval' on the property name passed to it. This invites exploitation. It also fails 'static_typed's desideratum of each component having a single responsibility. And I don't think calling it "magic" is too strong. I don't know to what extent the Ruby culture encourages calling 'eval' in random API routines like this, but when I previously argued here on HN that that had to be a bad idea, I got some pushback. I would certainly call this a dangerous anti-pattern. EDITED to add: reference: http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/ http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look...

stouset 14y ago
I consider myself an expert in Ruby style and best practices. And I have never and would never write code that uses `eval`, outside of toy projects. There are probably ways you can use it safely. But it's not worth the risk.