Live data from Hacker News

Multiple security vulnerabilities in Rails

groups.google.com

51–60 of 66 posts

Re: Multiple security vulnerabilities in Rails

#51
post #14

Earlier quoted context omitted.

Wow you have a terrible attitude about security. "None of these are an issue, just program in this [very specific way that requires pre-knowledge of these vulnerabilities] and you're safe, anything else is basically negligence." Your opinions about rails-html-sanitizer are particularly troubling as even if you use the sanitizer as suggested in the docs you're vulnerable and your retort is "well you should encode AND…

I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours? And, more concretely, I have no problem with his pointing out that some of--not all, but so…

Such arguments are nonsense. Sure the criticism might be a bit harsh but what on earth do one's credentials matter in such situations? Oh so if I'm not some superstar open source contributor I can't try to point out what could be better in the approaches of another guy who's famous and made huge contributions? We should only look at facts case by case and such a fame-based logic can only be detrimental.

Re: Multiple security vulnerabilities in Rails

#53
post #52

Aah Aaron. Thanks. Everywhere he codes he refactors, fixes performance issues, finds bugs, he's so my hero.

tenderlove is the best. Not only does he work on both Ruby and Ruby on Rails, he's also very active in the community (conferences, workshops, talks) and working hard on promoting a spirit of humility and respect (see the humorous Adequate HQ, the Friday Hug, the overwhelmingly positive and generous attitude he's always had towards anyone, famous or not, in the Ruby community). I have nothing but respect for that man and I'm glad he's working hard everyday on the language I so love.

Thank you Aaron.

Re: Multiple security vulnerabilities in Rails

#54

Nobody's actually still exposing rails sites to the internet are they? I mean except as a honeypot. The rails team's approach to security (it's the application's problem) has been consistent. At this point if you're letting the wild Internet touch your rails apps it's probably your own fault.

Is this the general view? What is the best course of action here? Stop using Rails or somehow protect it better?

The HN handle is "trollian". Enough said.

Re: Multiple security vulnerabilities in Rails

#55
A quick `bundle update` appears to be just the ticket:

    …
    Installing rails-html-sanitizer 1.0.3 (was 1.0.2)
    Installing actionmailer 4.2.5.1 (was 4.2.5)
    Installing activemodel 4.2.5.1 (was 4.2.5)
    Installing activerecord 4.2.5.1 (was 4.2.5)
    Installing railties 4.2.5.1 (was 4.2.5)
    Installing rails 4.2.5.1 (was 4.2.5)
    …
    Bundle updated!

Re: Multiple security vulnerabilities in Rails

#56
post #9
post #5

Doesn't look too bad, although there are a lot of CVEs to go through: - A timing attack if you're using HTTP basic auth - A couple of GC related DoS attacks - An issue with `accepts_nested_attributes_for` if you're using both the `allow_destroy` and `reject_if` options - A validation bypass exploit if you're calling `SomeModel.new(params[:some_model])` instead of using StrongParams - An information leak exploit if yo…

>- A timing attack if you're using HTTP basic auth I'd say that qualifies as pretty bad. How the hell does that even happen? Using time constant string comparison is authentication 101. That's really not something you can mess up by mistake, it's something you mess up by not understanding what you're doing. And that's is all ignoring the fact that there's no reason to not use hashing here.

It's literally Rule #1

https://cryptocoding.net/index.php/Coding_rules

Re: Multiple security vulnerabilities in Rails

#57

I see a timing attack in the list. It's fairly trivial to mitigate against this in the majority of languages nowadays [1] [2] [3] etc.. I presume this can also be mitigated by implementing rate limiting on your authentication endpoints, although that should also be implemented for other reasons. [1] https://golang.org/pkg/crypto/subtle/#ConstantTimeCompare [2] http://php.net/manual/en/function.hash-equals.php [3] htt…

The current implementation is here: https://github.com/rails/rails/commit/859ca4474e1608b83d6194...

why

    return false unless a.bytesize == b.bytesize
instead of

    if a.bytesize != b.bytesize
        return false
disclaimer: never programmed in ruby

Re: Multiple security vulnerabilities in Rails

#58
post #57

Earlier quoted context omitted.

The current implementation is here: https://github.com/rails/rails/commit/859ca4474e1608b83d6194...

why return false unless a.bytesize == b.bytesize instead of if a.bytesize != b.bytesize return false disclaimer: never programmed in ruby

It's idiomatic ruby.

First as the conditional only has one statment it's preferred to write it in its shorthand way, so instead of

  if a.bytesize != b.bytesize
    return false
We start by writing

  return false if a.bytesize != b.bytesize
And then unless is the negated conditional, so we rewrite it as

  return false unless a.bytesize == b.bytesize
Which some peolpe (myself included) consider easier to read, the 'unless' is easier to note (more chars) than the '!='.
Post reply on HN