From: Phillip Gawlowski Date: 2008-05-08T22:07:06+09:00 Subject: Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clifford Heath wrote: |> If I'm able to read source code in a, hopefully, protected directory, |> I'm not going to bother with code injection. | | Completely disagree there. As soon as I see that mongrel's running, | I have a plan of attack. Well, of course. But to exploit something, it has to be exposed first. And once something is exposed, almost all bets are off. Sanitize your input from injection attacks, make sure CSRF and XSS won't hurt you, and keep your server (for lack of a better term for an exposed service) up to date on security patches, too. However, if an attacker doesn't see the source because it is compiled it object code/ byte code, or because the server only emits HTML, the barrier to exploiting the system is about the same. |> I'd be doing something like |> $ passwd |> Type the new password for root: | | If you already have shell access, yes. But security's already broken | then. Yeah, but to read the sources of a Merb, Rails, or Ruby-CGI application, I'll have to have shell access already (unless, of course, I hand over my source code, and neglected to code software safe in the first place). In that, it doesn't differ from running IIS or Apache, PHP or Perl. All these packages have to be written safe, sane, and secure. That IIS and Apache are compiled to object code is, in this regard, an implementation detail. | It hasn't. It's introduced different versions of the same thing, | but all of these are easier than the equivalent attacks on object | code. Object code adds one step to the process: Disassemble the binary. No language is inherently secure or insecure, be it interpreted or compiled. It's the coding that is secure or insecure. (I currently work on a Rails app that I wouldn't dare putting online, since there is next to no input sanitation (?) of input going on. |> Or with a hexeditor. Heck, download one from someplace, if you are able |> to see the sources of a Ruby app. | | If you have the app to begin with. If you only have a web interface, | you don't have the app yet. You need to inject code to get it, or to | do worse. Of course. But you always have to sanitize input. No matter how the end product is run. The attack vector more depends on what the application does, rather on what the application is written in. |> In short: Ruby makes the defense as shallow as Perl or Python. | | Agree. But that's shallower than an object-code only system. By half an inch, maybe. And it is easier to write a secure application, IMO, if there is no need to hunt down corrupted pointers, too. ;) - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan Blog: http://justarubyist.blogspot.com ~ I'm just very selective about the reality I choose to accept. ~ --- Calvin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgi+vwACgkQbtAgaoJTgL/ELACgjWvgi1hsZBwSs9tuMhWbiUxo FZoAniqDmr1A1v8c/B7ByyWobd09uGO6 =6NP3 -----END PGP SIGNATURE-----