Hacker News Reader

Comment by timr | Hacker News Reader

"this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerability in apps written using a certain style, or perhaps a vulnerability by default in apps written using the generators and scaffolding baked into rails."

Well, gee...so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a more experienced developer might have avoided by doing extra work, and you say that's not a security problem in Rails?

Maybe it isn't a "vulnerability", per se, but it sure seems like a poor design choice. A "hardened" framework is going to make parameter whitelisting the default behavior, even if it's a little less convenient. If the github developers (who are presumably experienced) can make this mistake, then anyone can make this mistake.

View on HN

so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a more experienced developer might have avoided by doing extra work, and you say that's not a security problem in Rails?

Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM. If you want a framework that produces secure applications for inexperienced developers who do not read the fine manual, you are setting a laudable goal for Rails, but I hardly think that “Secure even for people who are 1. novices and 2. compound their ignorance by refusing to RTFM” is synonymous with “security problem.”

If you open your history book to when Rails was first becoming popular, there were many people grumbling that because it was built on top of a dynamic language that it was vulnerable to all sorts of bugs caused by novice developers getting their types wrong. The argument at the time was that Rails provided a certain type of freedom and power at the expense of certain safeguards. The same argument was played out when people started noticing that monkey-patching run amuck caused certain problems.

I agree with you that this is a design choice. If you want to say that you disagree with the choice as it was originally made, I agree with that too. I won’t say that I would have made a different choice back when that feature was first baked in, I did not write the framework. But here we are today, and it seems like a very good time to make a different choice.

Scott Meyers (author of Effective C++ et al.) has talked about this subject many times (including in the aformentioned book) and it puts the ball squarely in the Rails team's court.

Let's make the reasonable assumption that your clients—the people using your interfaces— are trying to do a good job. They're smart, they're motivated, they're conscientious. They're willing to read some documentation to help them understand the system they're using. They want things to behave correctly.

That being the case, if they make a mistake when using your interface, it's your fault. We're assuming they're doing their best—they want to succeed. If they fail, it's because you let them. So, if somebody uses your interface incorrectly, either they're working hard at it (less likely) or your interface allowed them to do something easy that was not correct (more likely). This puts the shoe on the foot not used to wearing it: it means that responsibility for interface usage errors belongs to the interface designer, not the interface user.

Source: Scott Meyers: The Most Important Design Guideline? http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_rev...

I think we’re in agreement. I don’t like the design, I don’t use it myself. I just think that it’s not correct to say that Rails has a security vulnerability and especially that Rails is vulnerable by default. Both of these expressions carry the false connotation that all rails apps are vulnerable and that the fix for the vulnerability lies in patching Rails, when in actuality Rails has a questionable design problem, and every developer has the power in their own hands to secure their application.

If I make something and it has a property that can be directly traced to recurring security problems, then that is a vulnerability. That it might not be cut out of whatever neat template you've built in your mind doesn't change that fact.

Scaffolding is part of rails, so fixing the bug does involve patching rails.

"Windows has no security vulnerabilities itself, since you can edit the exe of any malfunctioning app. A security conscious app developer is responsible for auditing Windows and making necessary changes. Heck, most vulnerabilities have already been documented, and sometimes the workaround doesn't even involve coding. " See how silly that is?

So in other words: bad design is justified by the notion that people shouldn't make mistakes. Praise the lord you don't design anything that can burn, irradiate or cut people.

I don’t think you should try to rephrase my words in your words, because in doing so you are completely misrepresenting what I said. So please, stick to just reading my words, and if you want to disagree with what I actually write, do that. What I said was:

If you want to say that you disagree with the choice as it was originally made, I agree with that too. Meaning, I disagree with the design. At no time did I say that this or any design was “justified.” That’s your word, not mine. So I think you should stick to espousing your opinions, not disagreeing with things I didn’t say.

I’m very clear that I don’t like the design and don’t use the feature myself. But as I posted elsewhere, I just think that it’s not correct to say that Rails has a security vulnerability and especially that Rails is vulnerable by default. Both of these expressions carry the false connotation that all rails apps are vulnerable and that the fix for the vulnerability lies in patching Rails, when in actuality Rails has a questionable design problem, and every developer has the power in their own hands to secure their application.

My issue is entirely with the nomenclature, not with whether I like or dislike mass assignment.

I'm not interested in your sophistry. You're saying it is not a vulnerability in rails, on the basis that it can be fixed by users. That's tantamount to justifying it, regardless of the degree. Rails is dead wrong here and I'm not interested in playing the "try to be right on the Internet" game with you.

Downvoted once again by people who have no reply.

It's not sophistry, the distinction raganwald is making is relevant.

However, even if it is not technically accurate, in the interest of getting the topic in front of as many Rails developers as possible, it's probably better to sweep that distinction under the rug and let them figure out for themselves whether it applies to them.

So your contention is that because something is "relevant" that prohibits the possibility of it being sophistic? The distinction is completely artificial. This bug in rails can be directly traced to recurring security problems. If that's not a vulnerability, then we speak a different dialect of English.

Ok, look, I actually think it is a vulnerability to most approximations which isn't what comes across in what I wrote.

That said, I don't think what raganwald was saying was sophistry at all. Sophistry implies an attempt to deceive. He was just being pedantic and a little narrow with his definition of vulnerability.

So when you say his argument sophistry, and then follow up with "... and I'm not interested in playing the "try to be right on the Internet" game with you." you're just lashing out. So that's probably why people (not me) where downvoting without replying.

  I'm not interested in playing the "try to be right on the Internet" game with you.

Just as well, it seems that we agree on so much that focusing on where we are saying different things devolves into pedantry precisely because we agree on the important matters.

As I said elsewhere:

We probably agree that this feature should be taken out and shot, but are quibbling over which charge should be read off the indictment before giving the order to fire ;-)

By the way, this is the perfect example of modernistic trash-thought that focuses on details and not behaving usefully. You navel gaze over the "correct" usage and nitpick my argument instead of getting behind the position that is going to prevent harmful behaviour.

raganwald likes to put all the blame on "novices" and tell people to "RTFM" then take umbrage to the suggestion that he's defending the existence of bad design based on an idiotic, legalistic approach to conversation.

Especially ironic considering the thing that sparked this whole discussion was a vunerability on GitHub, of all places. If the developers at GitHub are lumped in with the uneducated "novices", who exactly are the experts?

"Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM."

I suppose that the github developers all failed to RTFM, too, right? So either they're all n00bs, or we can safely assume that everyone makes mistakes when the framework makes mistakes easy to make.

(Also, I suspect that you're joking about the "young man" thing, but it's probably worth pointing out that I've been coding for a long time. I may even be older than you. But I still make mistakes, and I definitely appreciate it when my frameworks make the Right Way the Only Way. It's not just about novices.)

Of course I was joking about the young man thing. As I suspected you were with the “Gee” thing. It’s not a formal debate, a little “local” colour makes comments like this more enjoyable to read.

I used to see this argument a lot from PHP people. You know, it's not PHP that's insecure, it's all those novices writing insecure PHP code.

Except that PHP makes it so easy to write insecure code that novices are pretty much guaranteed to produce vulnerabilities and even experts have to be vigilant to avoid accidentally stepping on one of the many landmines in the language.

If the designers of the language (or framework) put a landmine in it, and a developer steps on it, the designers of the language absolutely bear some responsibility for the fact that the landmine was there to be stepped on.

sounds like pointers in C vs C++

Reply on news.ycombinator.com