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…
Multiple security vulnerabilities in Rails
51–60 of 66 posts
Re: Multiple security vulnerabilities in Rails
#52Re: Multiple security vulnerabilities in Rails
#53Aah Aaron. Thanks. Everywhere he codes he refactors, fixes performance issues, finds bugs, he's so my hero.
Thank you Aaron.
Re: Multiple security vulnerabilities in Rails
#54Nobody'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?
Re: Multiple security vulnerabilities in Rails
#55 …
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
#56Doesn'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.
Re: Multiple security vulnerabilities in Rails
#57I 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...
return false unless a.bytesize == b.bytesize
instead of if a.bytesize != b.bytesize
return false
disclaimer: never programmed in rubyRe: Multiple security vulnerabilities in Rails
#58Earlier 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
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 '!='.Re: Multiple security vulnerabilities in Rails
#59random quote: 'I used to consume cannabis on a daily basis, I suffer no short term memory loss, as far as I can remember....'