3 ms·

Our main client has one security agreement in place - anything but Ruby on Fails please! They seem quite happy with Python so far.

jiggy2011 14y ago
Doesn't seem like that solves the fundamental problem though. You could have django issues or whatever just down the pipe. Or issues lower down the stack.
- cstejerean 14y ago
  Let's compare the track record of Django and Rails: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-... http://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199 http://www.cvedetails.com/product/18211/Djangoproject-Django... So far zero remote code execution and zero SQL injection vulnerabilities in Django.
  - jiggy2011 14y ago
    That's not the point. Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data. If you are responsible for such a system, how do you manage that risk in a realistic way? Minimising it by choosing a particular technology is only one dimension of security. Incident response strategies, legal mitigation etc are important here also. It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.
  - joesb 14y ago
    Still more DOS, Directory traversal and CSRF vulnerabilities.
- orionvmjoseph 14y ago
  The philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.

3 ms·

Our main client has one security agreement in place - anything but Ruby on Fails please! They seem quite happy with Python so far.

by static_typed 14y ago

jiggy2011 14y ago
Doesn't seem like that solves the fundamental problem though. You could have django issues or whatever just down the pipe. Or issues lower down the stack.
- cstejerean 14y ago
  Let's compare the track record of Django and Rails: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-... http://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199 http://www.cvedetails.com/product/18211/Djangoproject-Django... So far zero remote code execution and zero SQL injection vulnerabilities in Django.
  - jiggy2011 14y ago
    That's not the point. Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data. If you are responsible for such a system, how do you manage that risk in a realistic way? Minimising it by choosing a particular technology is only one dimension of security. Incident response strategies, legal mitigation etc are important here also. It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.
  - joesb 14y ago
    Still more DOS, Directory traversal and CSRF vulnerabilities.
- orionvmjoseph 14y ago
  The philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.