4 ms·

You're comparing a web app framework to a language and then to encrypted communication software which has been around for over a decade? You're grasping at str

You're comparing a web app framework to a language and then to encrypted communication software which has been around for over a decade? You're grasping at straws here and it is telling you quote the OpenSSH security record but not that of other frameworks. Even comparing it to Go is pretty flawed, because of course Go is a language, not a framework, and it has not been tested extensively or attacked extensively, nor have the apps you have written in it. You can expect those apps to have some vulnerabilities you don't even know about as yet, unless you have had a security audit? Like many projects, Rails is continually discovering potential security problems, though I wouldn't say it is significantly worse than other comparable frameworks/stacks, and some of the flaws they are fixing nowadays are pretty much harmless for normal use (some not, like this one, which is dangerous for the subset of users using these advanced features (probably under 5% of users)). Pick any other widely used app framework, and you will find a similar history of security exploits discovered, though I'm sure some are better than others. It's fine to say that Rails has worse security than project x, backed up by figures, but saying anyone using Rails is shooting themselves in the foot is hyperbole. The worst recent issue in rails I can remember is the JSON parsing incident, which also affected some python users. Just as an example comparison, in Golang if you are lazy and unmarshal into an interface or map[string]interface you might end up with similar problems of unintended data leakage, and if you unmarshal into your own struct without carefully checking what you get, you might end up with unexpected nils which only surface much later or data overwritten which was unintended. You're unlikely to get clobbered just as the Ruby JSON parser was, but you could easily introduce vulns without knowing it. I actually prefer golang to ruby for other reasons, but the frameworks are neither mature nor battle tested, so it's not a great example to compare on security, and neither is OpenSSH.

vesinisa 13y ago
How is it going to help anyone whose web application has been hacked to know that the problem was expected because the platform they were using was so popular/complex/whatever? From a purely practical security point of view, using Rails currently for new applications is taking an aim at your own feet, because there exists less vulnerable solutions as well.
- grey-area 13y ago
  I'm not making excuses for Rails, which is comparable to many other frameworks on security issues in my experience, I'm pointing out (as many others have done) that your argument is based on false premises. If your home-grown solution is based on golang and you've had security audits done with nothing found, congratulations, but if you haven't, it is almost certainly more vulnerable to a wide range of flaws, some in the libraries, some in your code. For example what CSRF protection do you use, what XSS protections? I'm quite willing to believe that most of the golang web libraries are more solid than rails 1.0 ever was, because they were written by far more experienced programmers initially, but this is a complex topic, they do not cover everything you would need, and everyone makes mistakes. As an example, here is an exploit in play.golang.org: http://codearcana.com/posts/2013/04/23/exploiting-a-go-binary.html http://codearcana.com/posts/2013/04/23/exploiting-a-go-binar... You have provided no evidence that other options are significantly less vulnerable, unless you serve your web pages with OpenSSH?
  - vesinisa 13y ago
    You keep putting words to my mouth. I have not compared OpenSSH, Go or Rails as web frameworks. I compared Ruby's speed to Go and Rails' security record to OpenSSH. But I give you misrepresentation is a great way to make someone look stupid. My personal intuition is that Rails is insecure and becoming increasingly insecure. I have cited a high number of CVEs. If you disagree, go ahead and use Rails for your app. You'll save some time, but remember to remain vigilant about security issues.
    - grey-area 13y ago
      The intention wasn't to make you look stupid but to point out the absurdity of the comparison between rails and OpenSSH. I completely agree on speed and (perhaps more importantly) memory size, minimal golang apps far surpass rails. On security, I'm not convinced a home-grown solution in plain go or any of the extant frameworks will be significantly more secure than Rails, nor that Rails is becoming more insecure. If anything I think they're putting more effort and time into security than they did previously.
batiste 13y ago
> Like many projects, Rails is continually discovering potential security problems, though I wouldn't say it is significantly worse than other comparable frameworks/stacks Compared to Django, a framework similar both in feature and popularity, Rails is definitely worse. Especially compared with the most serious flaws (code execution, SQL injections). http://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199 http://www.cvedetails.com/product/18211/Djangoproject-Django... http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-... Not sure about the JSON incident you mention. Maybe you thought about YAML?
- grey-area 13y ago
  Thanks for the links, which I think would lead to a more productive discussion because they are a comparison of similar frameworks. There are of course difficulties with gauging how much attention each gets (a lower CVE count is not proof of security), but overall Django looks better here. I was thinking of the third one on this page (I suppose strictly speaking a vuln in a gem outside rails) which was pretty serious: http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12-3-1-11-and-2-3-17-have-been-released/ http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12... but there was a related YAML bug too at the same time with serialize, which also allowed users to supply input that was then instantiated (madness!). Do lots of people use serialize? I've never explicitly used it, unless it is used behind the scenes somewhere. I remembered the fuss being over JSON because of broader impact but may have misremembered.

vesinisa 13y ago

How is it going to help anyone whose web application has been hacked to know that the problem was expected because the platform they were using was so popular/complex/whatever? From a purely practical security point of view, using Rails currently for new applications is taking an aim at your own feet, because there exists less vulnerable solutions as well.

grey-area 13y ago
I'm not making excuses for Rails, which is comparable to many other frameworks on security issues in my experience, I'm pointing out (as many others have done) that your argument is based on false premises. If your home-grown solution is based on golang and you've had security audits done with nothing found, congratulations, but if you haven't, it is almost certainly more vulnerable to a wide range of flaws, some in the libraries, some in your code. For example what CSRF protection do you use, what XSS protections? I'm quite willing to believe that most of the golang web libraries are more solid than rails 1.0 ever was, because they were written by far more experienced programmers initially, but this is a complex topic, they do not cover everything you would need, and everyone makes mistakes. As an example, here is an exploit in play.golang.org: http://codearcana.com/posts/2013/04/23/exploiting-a-go-binary.html http://codearcana.com/posts/2013/04/23/exploiting-a-go-binar... You have provided no evidence that other options are significantly less vulnerable, unless you serve your web pages with OpenSSH?
- vesinisa 13y ago
  You keep putting words to my mouth. I have not compared OpenSSH, Go or Rails as web frameworks. I compared Ruby's speed to Go and Rails' security record to OpenSSH. But I give you misrepresentation is a great way to make someone look stupid. My personal intuition is that Rails is insecure and becoming increasingly insecure. I have cited a high number of CVEs. If you disagree, go ahead and use Rails for your app. You'll save some time, but remember to remain vigilant about security issues.
  - grey-area 13y ago
    The intention wasn't to make you look stupid but to point out the absurdity of the comparison between rails and OpenSSH. I completely agree on speed and (perhaps more importantly) memory size, minimal golang apps far surpass rails. On security, I'm not convinced a home-grown solution in plain go or any of the extant frameworks will be significantly more secure than Rails, nor that Rails is becoming more insecure. If anything I think they're putting more effort and time into security than they did previously.

batiste 13y ago

> Like many projects, Rails is continually discovering potential security problems, though I wouldn't say it is significantly worse than other comparable frameworks/stacks Compared to Django, a framework similar both in feature and popularity, Rails is definitely worse. Especially compared with the most serious flaws (code execution, SQL injections). http://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199 http://www.cvedetails.com/product/18211/Djangoproject-Django... http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-... Not sure about the JSON incident you mention. Maybe you thought about YAML?

grey-area 13y ago
Thanks for the links, which I think would lead to a more productive discussion because they are a comparison of similar frameworks. There are of course difficulties with gauging how much attention each gets (a lower CVE count is not proof of security), but overall Django looks better here. I was thinking of the third one on this page (I suppose strictly speaking a vuln in a gem outside rails) which was pretty serious: http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12-3-1-11-and-2-3-17-have-been-released/ http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12... but there was a related YAML bug too at the same time with serialize, which also allowed users to supply input that was then instantiated (madness!). Do lots of people use serialize? I've never explicitly used it, unless it is used behind the scenes somewhere. I remembered the fuss being over JSON because of broader impact but may have misremembered.