CSC/ECE 517 Fall 2009/wiki1a 10 RS56
Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.
Ruby and Java from a security perspective.
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”
Ruby
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through XRuby or JRuby which could then be better protected. Please see the Java discussion below for details of this protection.
The data center manager’s view of Ruby is less clear. Ruby does have a robust Issue Tracking System which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1]
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type.
Java
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through obfuscation. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program.
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. Security alerts are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect.
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night.
Conclusion
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.
Glossary
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware.
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer.
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1]
Trusted – An object, not created by the running program that cannot be modified by the program. [1]
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1]
References
- Dave Thomas, Chad Fowler and Andy Hunt. Programming Ruby 1.9, chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5