[CVE-2015-7581] Object leak vulnerability for wildcard controller routes in Action Pack: Look for routes that contain ":controller" and change it to something else. Hopefully you didn't have this weird name in your routes.
[CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good.
[CVE-2016-0753] Possible Input Validation Circumvention in Active Model: params.permit! is negligence, you should not be doing that anyway
[CVE-2016-0752] Possible Information Leak Vulnerability in Action View: render params[:id] is not defensive programming, so you should not be doing that too
[CVE-2015-7577] Nested attributes rejection proc bypass in Active Record: Only if using nested_attributes and rejection proc. Wasn't my case. Just patch.
[CVE-2016-0751] Possible Object Leak and Denial of Service attack in Action Pack: DoS is bad, just patch.
[CVE-2015-7576] Timing attack vulnerability in basic authentication in Action Controller: Just patch.
-- Doesn't look THAT bad, but need to be patched fast.
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 sanitise, not just rely on the sanitiser doing what the documentation says it should do!" Why?
I have no issue with the wording in the official CVEs. But this attempt at whitewashing the, frankly, pretty serious issues is deplorable.
But hey, you won't do any good complaining in face of this situation. Time to help people fix it. Peace.
And, more concretely, I have no problem with his pointing out that some of--not all, but some--these issues are ones mitigated by decent, security-aware software development practices, like, oh, "don't spit something into a template out of your input parameters". Because tools break. Your libraries break. They will always break. Program defensively in all situations where hostile input is possible and never take for granted any attempts to defuse attacks; always favor braces-and-belt wherever possible and you'll generally do okay. It's entirely unnecessary to be a jerk towards him for saying this.
Fixing security vulnerabilities and writing docs that actually reflect best security practices do not make developers smile.
And accusing to have a terrible attitude does not make a developer smile either, so this is obviously your fault!
/s
So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for the correct context is good, but any applications which don't do that but also use that same dataset are screwed because your application didn't perform proper input validation.
Defense in depth strategies exist for a reason. Input validation, output encoding for every single context (this includes using angular properly, for instance), anti-xss headers, CSP, the list goes on. These aren't all prescribed just to protect that one application. They're prescribed so that when applied correctly across all apps, they're all protected from negligence in one app harming the data.
- 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 you're calling `render params[:something]` with raw user input
- A bunch of potential XSS exploits
The `render` issue looks like it could cause the most harm, but hopefully shouldn't be too prevalent. The XSS issues should be a quick fix as you only have to update `rails-html-sanitizer`, not Rails itself.
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.
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] http://www.levigross.com/2014/02/07/constant-time-comparison...
https://github.com/rails/rails/commit/859ca4474e1608b83d6194...
return false unless a.bytesize == b.bytesize
if a.bytesize != b.bytesize
return false
Thank you Aaron.
…
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!random quote: 'I used to consume cannabis on a daily basis, I suffer no short term memory loss, as far as I can remember....'