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

Github Is Classy

jtimberman.housepub.org

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Github Is Classy

#41

Post by javascriptlol »

javascriptlol wrote: post #37
raganwald wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Github Is Classy

#42

Post by timr »

raganwald wrote: post #17
timr wrote: post #10

Earlier quoted context omitted.

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

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

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

Re: Github Is Classy

#43

Post by tylermenezes »

raganwald wrote: post #5

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

> or that it is technically true that Rails is insecure by default

PHP learned their lesson a while ago with register_globals: if you need to specifically disable people from attacking your site in many places, it's inevitable that you'll miss one or two.

Re: Github Is Classy

#44

Post by jamesgeck0 »

raganwald wrote: post #5

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

I'm a just a fool with a simple Rails app and copy of _The Design of Everyday Things_, but this seems like a usability issue.

The default scaffolding doesn't contain an attr_accessible property, so it's not visible to the user that there's something missing. There's also no feedback from Rails that your attributes are insecure; only feedback if one tries to change an attribute explicitly made non-accessible. Figuring out which attributes must be private is a problem possibly beyond the scope of core Rails, though.

Perhaps a command like `rake routes` for publicly accessible model attributes might be of benefit.

Re: Github Is Classy

#46

Post by javascriptlol »

raganwald wrote: post #36
hartror wrote: post #24

Earlier quoted context omitted.

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

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

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.

Re: Github Is Classy

#47

Post by aptwebapps »

javascriptlol wrote: post #37
raganwald wrote: post #35

Earlier quoted context omitted.

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

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.

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.

Re: Github Is Classy

#48

Post by javascriptlol »

aptwebapps wrote: post #47
javascriptlol wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Github Is Classy

#49

Post by javascriptlol »

raganwald wrote: post #11
jtimberman wrote: post #7

Earlier quoted context omitted.

My point is that Rails does not take the high road of providing better, sane, secure defaults for people to build their applications. While the proposed solutions in the issues I linked to were denied, it doesn't mean there shouldn't be some solution added to Rails. This is definitely a case of convenience favored over security.

I think it’s like .find_by_sql and .where and everywhere else Rails provides a way to write SQL fragments. You can compose strings and open yourself to SQL Injection, or you can have ActiveRecord insert sanitized parameters for you. There’s no “vulnerability by default” in ActiveRecord’s handling of SQL snippets. There’s a right way and a wrong way. Likewise with mass assignment. There’s a right way to use it and a w…

Yes, construction of raw SQL queries outside library code is a security hole. The same with writing browsers in C or C++. These bad design choices can be traced to countless security issues. The same for generating HTML using string manipulation. These are all stupid ideas, and until people realise that they're holes we will be stuck with endless security problems. And it's the coward's way out to hide behind the "sharper tools" nonsense. You don't hear chainsaw vendors wearing safety flaws as a badge of pride.

Re: Github Is Classy

#50

Post by xentronium »

kenneth_reitz wrote: post #3

The amount of bad press GitHub has received from this has blown me away. If anyone should be getting flamed for this, it should be the Rails maintainers that weren't open to the discussion.

> If anyone should be getting flamed for this, it should be the Rails maintainers that weren't open to the discussion.

A bad workman always blames his tools.

Post reply on HN