<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Wolf27</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Wolf27"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Wolf27"/>
	<updated>2026-05-19T09:17:37Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki29_VB&amp;diff=25607</id>
		<title>CSC/ECE 517 Fall 2009/wiki29 VB</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki29_VB&amp;diff=25607"/>
		<updated>2009-10-11T00:24:51Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* AspectR */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ''' Aspect Oriented Programming - An Introduction''' ==&lt;br /&gt;
&lt;br /&gt;
When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines. &lt;br /&gt;
&lt;br /&gt;
Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops. &lt;br /&gt;
&lt;br /&gt;
For example, we develop a  web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with  minimum amount of code.  But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it. &lt;br /&gt;
&lt;br /&gt;
Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]&lt;br /&gt;
&lt;br /&gt;
== Terminologies used in Aspect Oriented Programming ==&lt;br /&gt;
&lt;br /&gt;
Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.&lt;br /&gt;
&lt;br /&gt;
Here are the definitions of some of the standard terms that would be required to understand AOP concepts.&lt;br /&gt;
&lt;br /&gt;
1.'''Cross-cutting concerns''':(For a definition, go to [[http://en.wikipedia.org/wiki/Cross-cutting_concern Appendix 3]].) Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.&lt;br /&gt;
&lt;br /&gt;
2.'''Advice''': Advice is the extra code that we want to add to our already existing model. &lt;br /&gt;
&lt;br /&gt;
3.'''Point-cut''': Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied. &lt;br /&gt;
&lt;br /&gt;
4.'''Aspect''': Aspect is the combination of the point-cut and the advice.&lt;br /&gt;
&lt;br /&gt;
The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]&lt;br /&gt;
&lt;br /&gt;
== AspectJ ==&lt;br /&gt;
&lt;br /&gt;
AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]&lt;br /&gt;
&lt;br /&gt;
Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]&lt;br /&gt;
&lt;br /&gt;
Let's consider the following example to understand this better.&lt;br /&gt;
 source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm&lt;br /&gt;
 public class TestClass {&lt;br /&gt;
  public void sayHello () {&lt;br /&gt;
    System.out.println (&amp;quot;Hello, AOP&amp;quot;);&lt;br /&gt;
  }&lt;br /&gt;
  public void sayAnyThing (String s) {&lt;br /&gt;
    System.out.println (s);&lt;br /&gt;
  }&lt;br /&gt;
  public static void main (String[] args) {&lt;br /&gt;
    sayHello ();&lt;br /&gt;
    sayAnyThing (&amp;quot;ok&amp;quot;);&lt;br /&gt;
  }&lt;br /&gt;
 }&lt;br /&gt;
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:&lt;br /&gt;
1.We would like to print a message before and after any call to the TestClass.sayHello() method. &lt;br /&gt;
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters. &lt;br /&gt;
&lt;br /&gt;
Here  is the AspectJ implementation&lt;br /&gt;
  source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm&lt;br /&gt;
  1: public aspect MyAspect {&lt;br /&gt;
  2:   public pointcut sayMethodCall (): call (public void TestClass.say*() );&lt;br /&gt;
  3:   public pointcut sayMethodCallArg (String str): call&lt;br /&gt;
                     (public void TestClass.sayAnyThing (String))&lt;br /&gt;
                     &amp;amp;&amp;amp; args(str);&lt;br /&gt;
  4:   before(): sayMethodCall() {&lt;br /&gt;
  5:   System.out.println(&amp;quot;\n TestClass.&amp;quot; +&lt;br /&gt;
       thisJoinPointStaticPart.getSignature().getName() +&lt;br /&gt;
       &amp;quot;start...&amp;quot; );&lt;br /&gt;
  6:   }&lt;br /&gt;
  7:   after(): sayMethodCall() {&lt;br /&gt;
  8:   System.out.println(&amp;quot;\n TestClass.&amp;quot; +&lt;br /&gt;
       thisJoinPointStaticPart.getSignature().getName() +&lt;br /&gt;
       &amp;quot; end...&amp;quot;);&lt;br /&gt;
  9:   }&lt;br /&gt;
  10:   before(String str): sayMethodCallArg(str) {&lt;br /&gt;
  11:     if (str .length() &amp;lt; 3) {&lt;br /&gt;
  12:     System.out.println (&amp;quot;Error: I can't say words less than 3&lt;br /&gt;
                             characters&amp;quot;);&lt;br /&gt;
  13:     return;&lt;br /&gt;
  14:     }&lt;br /&gt;
  15:   }&lt;br /&gt;
  16: }&lt;br /&gt;
&lt;br /&gt;
From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.&lt;br /&gt;
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.&lt;br /&gt;
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the  example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.&lt;br /&gt;
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.&lt;br /&gt;
 public pointcut sayMethodCall (): call (public void&lt;br /&gt;
                                        TestClass.say*() );&lt;br /&gt;
&lt;br /&gt;
In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).&lt;br /&gt;
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.&lt;br /&gt;
Thus pointcuts and advice let us affect the dynamic execution of a program.&lt;br /&gt;
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]&lt;br /&gt;
&lt;br /&gt;
== AspectJ Plugin tool ==&lt;br /&gt;
&lt;br /&gt;
The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].&lt;br /&gt;
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/&lt;br /&gt;
&lt;br /&gt;
== AspectR == &lt;br /&gt;
&lt;br /&gt;
The concepts of Aspect-oriented programming to Ruby is provided by AspectR. Inside the classes, existing methods can be wrapped around by code using AspectR.The design of the code can be improved since it separates different concerns into different parts of the code. It is similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Main features of AspectR: &lt;br /&gt;
&lt;br /&gt;
•       Join points.&lt;br /&gt;
&lt;br /&gt;
•	Object receives method/constructor call. &lt;br /&gt;
&lt;br /&gt;
•	Field accessed (if access is via getter/setter method).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Advices can access:&lt;br /&gt;
&lt;br /&gt;
•	Object and method receiving call.&lt;br /&gt;
&lt;br /&gt;
•	Arguments to call.&lt;br /&gt;
&lt;br /&gt;
•	Return value.&lt;br /&gt;
&lt;br /&gt;
•	exceptions raised.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Aspects: &lt;br /&gt;
&lt;br /&gt;
•	Supports &amp;quot;abstract&amp;quot; Aspects and overriding between advices.&lt;br /&gt;
&lt;br /&gt;
•	Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to&lt;br /&gt;
&lt;br /&gt;
•	Pointcut parameters.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
AspectR lets a module wrap any number of methods in other classes (or objects) with the &amp;quot;advice&amp;quot; methods (in the lingo of Aspect/J) of the module.&lt;br /&gt;
&lt;br /&gt;
        source: http://aspectr.sourceforge.net/&lt;br /&gt;
        require 'aspectr'&lt;br /&gt;
        include AspectR&lt;br /&gt;
        class MyAspect &amp;lt; Aspect&lt;br /&gt;
        def someAdviceMethod(method, object, exitstatus, *args)&lt;br /&gt;
             ...&lt;br /&gt;
        end&lt;br /&gt;
        ... some other advice methods ...&lt;br /&gt;
        end&lt;br /&gt;
        ma = MyAspect.new&lt;br /&gt;
        ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or&lt;br /&gt;
        ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or&lt;br /&gt;
        AspectR.wrap_classes(ma, :preAdvice, :postAdvice,&lt;br /&gt;
       [Class1, Class2], ...methods to wrap...)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:&lt;br /&gt;
&lt;br /&gt;
        source:http://aspectr.sourceforge.net/&lt;br /&gt;
        Array with return value(s) if the method exited normally&lt;br /&gt;
        true if the method exited with an exception&lt;br /&gt;
        nil if the method hasn't yet exited (for preAdvice)&lt;br /&gt;
The rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.&lt;br /&gt;
Domain Specific Language is one of the features provided by Aquarium, which helps you to build your code in a modular way i.e using minimal language possible without repeating yourself all over the code.[[http://aquarium.rubyforge.org/index.html 6]]&lt;br /&gt;
&lt;br /&gt;
For example if you want to implement a behavior in Aquarium where you want to trace all invocations of public,instance methods in classes whose name ends wit &amp;quot;service&amp;quot;. This is how it is done.&lt;br /&gt;
&lt;br /&gt;
 source: http://aquarium.rubyforge.org/index.html&lt;br /&gt;
 class ServiceTracer&lt;br /&gt;
 include Aquarium::DSL before :calls_to =&amp;gt; :all_methods, :in_types =&amp;gt; /Service$/ do |join_point, object, *args log &amp;quot;Entering:    &lt;br /&gt;
 #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}&amp;quot; &lt;br /&gt;
 end&lt;br /&gt;
 after :calls_to =&amp;gt; :all_methods, :in_types =&amp;gt; /Service$/ do |join_point, object, *args|log &amp;quot;Leaving:              &lt;br /&gt;
 #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}&amp;quot; &lt;br /&gt;
 end&lt;br /&gt;
 end&lt;br /&gt;
&lt;br /&gt;
The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.&lt;br /&gt;
The #after advice adds similar behavior the is invoked after each method is invoked.&lt;br /&gt;
&lt;br /&gt;
A better implementation of this can be written as follows:&lt;br /&gt;
&lt;br /&gt;
 source: http://aquarium.rubyforge.org/index.html&lt;br /&gt;
 class ServiceTracer&lt;br /&gt;
 include Aquarium::DSL around :calls_to =&amp;gt; :all_methods, :in_types =&amp;gt; /Service$/ do |join_point, object, *args| log &amp;quot;Entering: &lt;br /&gt;
 {join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}&amp;quot; &lt;br /&gt;
 result = join_point.proceed&lt;br /&gt;
 log &amp;quot;Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}&amp;quot; &lt;br /&gt;
 result  # block needs to return the result of the &amp;quot;proceed&amp;quot;!&lt;br /&gt;
 end&lt;br /&gt;
 end&lt;br /&gt;
&lt;br /&gt;
The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]&lt;br /&gt;
&lt;br /&gt;
== Appendix ==&lt;br /&gt;
&lt;br /&gt;
'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation   open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ&lt;br /&gt;
&lt;br /&gt;
'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/&lt;br /&gt;
&lt;br /&gt;
'''3'''. cross cutting concerns - http://en.wikipedia.org/wiki/Cross-cutting_concern&lt;br /&gt;
&lt;br /&gt;
== References &amp;amp; Resources ==&lt;br /&gt;
&lt;br /&gt;
[1] http://onjava.com/onjava/2004/01/14/aop.html&lt;br /&gt;
&lt;br /&gt;
[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm&lt;br /&gt;
&lt;br /&gt;
[3] http://www.voelter.de/data/articles/aop/aop.html&lt;br /&gt;
&lt;br /&gt;
[4]http://rubyforge.org/projects/aquarium/&lt;br /&gt;
&lt;br /&gt;
[5]http://aspectr.sourceforge.net/&lt;br /&gt;
&lt;br /&gt;
[6]http://aquarium.rubyforge.org/examples.html&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=19031</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=19031"/>
		<updated>2009-09-11T04:23:08Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&amp;lt;br&amp;gt;&lt;br /&gt;
1) Virtual Machine Security &amp;lt;br&amp;gt;&lt;br /&gt;
2) Application Security &amp;lt;br&amp;gt;&lt;br /&gt;
3) Network Security &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Some of the key features regarding the above security issues are discussed in this article.&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Java language security constructs'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Within a Java program, every entity −− that is, every object reference and every primitive data&lt;br /&gt;
element −− has an access level associated with it.&amp;lt;br&amp;gt;&lt;br /&gt;
Private : The entity can only be accessed by code that is contained within the class that defines the entity.&amp;lt;br&amp;gt;&lt;br /&gt;
Protected : The entity can only be accessed by code that is contained within the class that defines the entity, by&lt;br /&gt;
classes within the same package as the defining class, or by a subclass of the defining class.&amp;lt;br&amp;gt;&lt;br /&gt;
Public : The entity can be accessed by code in any class.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby,The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;br /&gt;
[4] Scott Oaks. &amp;quot;Java Security&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[5] Sun website, Security Sections: http://java[dot]sun[dot]com/javase/technologies/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Talk:CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=19030</id>
		<title>Talk:CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Talk:CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=19030"/>
		<updated>2009-09-11T04:17:35Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17682</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17682"/>
		<updated>2009-09-06T00:48:33Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Java Security Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&amp;lt;br&amp;gt;&lt;br /&gt;
1) Virtual Machine Security &amp;lt;br&amp;gt;&lt;br /&gt;
2) Application Security &amp;lt;br&amp;gt;&lt;br /&gt;
3) Network Security &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Some of the key features regarding the above security issues are discussed in this article.&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Java language security constructs'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Within a Java program, every entity −− that is, every object reference and every primitive data&lt;br /&gt;
element −− has an access level associated with it.&amp;lt;br&amp;gt;&lt;br /&gt;
Private : The entity can only be accessed by code that is contained within the class that defines the entity.&amp;lt;br&amp;gt;&lt;br /&gt;
Protected : The entity can only be accessed by code that is contained within the class that defines the entity, by&lt;br /&gt;
classes within the same package as the defining class, or by a subclass of the defining class.&amp;lt;br&amp;gt;&lt;br /&gt;
Public : The entity can be accessed by code in any class.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;br /&gt;
[4] Scott Oaks. &amp;quot;Java Security&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[5] Sun website, Security Sections: http://java[dot]sun[dot]com/javase/technologies/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17680</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17680"/>
		<updated>2009-09-06T00:46:54Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Java Security Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&amp;lt;br&amp;gt;&lt;br /&gt;
1) Virtual Machine Security &amp;lt;br&amp;gt;&lt;br /&gt;
2) Application Security &amp;lt;br&amp;gt;&lt;br /&gt;
3) Network Security &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Some of the key features regarding the above security issues are discussed in this article.&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Java language security constructs'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Within a Java program, every entity −− that is, every object reference and every primitive data&lt;br /&gt;
element −− has an access level associated with it.&amp;lt;br&amp;gt;&lt;br /&gt;
Private : The entity can only be accessed by code that is contained within the class that defines the entity.&amp;lt;br&amp;gt;&lt;br /&gt;
Protected : The entity can only be accessed by code that is contained within the class that defines the entity, by&lt;br /&gt;
classes within the same package as the defining class, or by a subclass of the defining class.&amp;lt;br&amp;gt;&lt;br /&gt;
Public : The entity can be accessed by code in any class.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;br /&gt;
[4] Scott Oaks. &amp;quot;Java Security&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[5] Sun website, Security Sections: http://java[dot]sun[dot]com/javase/technologies/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17678</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17678"/>
		<updated>2009-09-06T00:40:46Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&amp;lt;br&amp;gt;&lt;br /&gt;
1) Virtual Machine Security &amp;lt;br&amp;gt;&lt;br /&gt;
2) Application Security &amp;lt;br&amp;gt;&lt;br /&gt;
3) Network Security &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Some of the key features regarding the above security issues are discussed in this article.&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;br /&gt;
[4] Scott Oaks. &amp;quot;Java Security&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[5] Sun website, Security Sections: http://java[dot]sun[dot]com/javase/technologies/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17674</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17674"/>
		<updated>2009-09-06T00:30:55Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&lt;br /&gt;
1) Virtual Machine Security &lt;br /&gt;
2) Application Security&lt;br /&gt;
3) Network Security&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;br /&gt;
[4] Scott Oaks. &amp;quot;Java Security&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[5] Sun website, Security Sections: http://java[dot]sun[dot]com/javase/technologies/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17673</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17673"/>
		<updated>2009-09-06T00:25:22Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Java Security Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&lt;br /&gt;
1) Virtual Machine Security &lt;br /&gt;
2) Application Security&lt;br /&gt;
3) Network Security&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Java Security Features ==&lt;br /&gt;
&lt;br /&gt;
'''''Programs are not allowed to access arbitrary memory locations'''''&amp;lt;br&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''''Variables may not be used before they are initialized'''''&amp;lt;br&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
'''''Objects cannot be arbitrarily cast into other objects'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&lt;br /&gt;
 public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
 CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
 System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
 Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
 CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''The Bytecode Verifier'''''&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
 public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
      public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
      public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
      CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
      System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
      }&amp;lt;br&amp;gt;&lt;br /&gt;
 }&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Cryptographic Extension(JCE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Authentication and Authorization Service (JAAS)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JAAS , as the name suggests is used for &amp;lt;br&amp;gt;&lt;br /&gt;
1) For authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet. &amp;lt;br&amp;gt;&lt;br /&gt;
2) For authorization of users, to ensure they have the access control rights (permissions) required to perform the actions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Java Secure Socket Extension (JSSE)'''''&amp;lt;br&amp;gt;&lt;br /&gt;
JSSE enables secure Internet communications.It provides a framework and an implementation for the Socket Security Layer(SSL) and Transport Layer Security(TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.&lt;br /&gt;
&lt;br /&gt;
The Secure Sockets Layer(SSL) and Transport Layer Security(TLS) protocols are used to protect the privacy and integrity of data while it is transferred across a network.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17592</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17592"/>
		<updated>2009-09-05T09:26:30Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Ruby */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&lt;br /&gt;
1) Virtual Machine Security &lt;br /&gt;
2) Application Security&lt;br /&gt;
3) Network Security&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Java Security Features&amp;lt;/b&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Programs are not allowed to access arbitrary memory locations.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Variables may not be used before they are initialized.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Objects cannot be arbitrarily cast into other objects.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;The Bytecode Verifier&amp;lt;/b&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute. &lt;br /&gt;
 &lt;br /&gt;
For example, consider the following classes&lt;br /&gt;
&lt;br /&gt;
public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
public String acctNo = &amp;quot;0001 0002 0003 0004&amp;quot;;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
public class Test {&amp;lt;br&amp;gt;&lt;br /&gt;
public static void main(String args[]) {&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCard cc = new CreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
System.out.println(&amp;quot;Your account number is &amp;quot; + cc.acctNo);&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of&lt;br /&gt;
acctNo to be private and recompile only the CreditCard class. We then have two class files and the&lt;br /&gt;
Test class file contains Java code that illegally accesses the private instance variable acctNo of the&lt;br /&gt;
CreditCard class and hence will not be allowed to execute.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17591</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17591"/>
		<updated>2009-09-05T07:39:42Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Ruby */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&lt;br /&gt;
1) Virtual Machine Security &lt;br /&gt;
2) Application Security&lt;br /&gt;
3) Network Security&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Java Security Features&amp;lt;/b&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Programs are not allowed to access arbitrary memory locations.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Variables may not be used before they are initialized.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Objects cannot be arbitrarily cast into other objects.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Talk:CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17586</id>
		<title>Talk:CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Talk:CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17586"/>
		<updated>2009-09-05T07:13:12Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: Java Security Features&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;b&amp;gt;Programs are not allowed to access arbitrary memory locations.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
For example, casting between an&lt;br /&gt;
int and an Object is strictly illegal in Java.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Variables may not be used before they are initialized.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
If a program were able to read the value of an uninitialized variable, the effect would be the same as if&lt;br /&gt;
it were able to read random memory locations. A Java class wishing to exploit this defect might then&lt;br /&gt;
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the&lt;br /&gt;
user's machine. To prevent this type of attack, all local variables in Java must be initialized before&lt;br /&gt;
they are used, and all instance variables in Java are automatically initialized to a default value.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Objects cannot be arbitrarily cast into other objects.&amp;lt;br&amp;gt;&amp;lt;/b&amp;gt;&lt;br /&gt;
Consider the below example.&lt;br /&gt;
&lt;br /&gt;
public class CreditCard {&amp;lt;br&amp;gt;&lt;br /&gt;
private String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
public class CreditCardSnoop {&amp;lt;br&amp;gt;&lt;br /&gt;
public String acctNo;&amp;lt;br&amp;gt;&lt;br /&gt;
}&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then the following code will not be allowed execute:&lt;br /&gt;
&lt;br /&gt;
CreditCard cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
System.out.println(&amp;quot;Ha! Your account number is &amp;quot; + snoop.acctNo);&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Java does not allow arbitrary casting between objects; an object can only be cast to one of its&lt;br /&gt;
superclasses or its subclasses.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To satisfy the compiler code can be changed as follows:&amp;lt;br&amp;gt;&lt;br /&gt;
Object cc = Wallet.getCreditCard( );&amp;lt;br&amp;gt;&lt;br /&gt;
CreditCardSnoop snoop = (CreditCardSnoop) cc;&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case, the virtual machine will throw a ClassCastException when the&lt;br /&gt;
snoop variable is assigned to thwart the attack.&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17311</id>
		<title>CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_10_wolf27-Manhattan&amp;diff=17311"/>
		<updated>2009-09-04T17:12:58Z</updated>

		<summary type="html">&lt;p&gt;Wolf27: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Ruby and Java from a Security Perspective&amp;lt;br&amp;gt;&lt;br /&gt;
Students: wolf 27 and Manhattan&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity.  That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected.  There are many techniques, algorithms, and methods available to ensure these three pillars.  The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data.  This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Java, Security can be considered in three contexts :&lt;br /&gt;
1) Virtual Machine Security &lt;br /&gt;
2) Application Security&lt;br /&gt;
3) Network Security&lt;br /&gt;
&lt;br /&gt;
== Ruby ==&lt;br /&gt;
&lt;br /&gt;
'''''“Safe Levels” in Ruby'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Arguable one of Ruby’s features with respect to security is its “Safe Levels”.  Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.&lt;br /&gt;
&lt;br /&gt;
All objects in Ruby are marked as “tainted” if they are derived from some external source.  For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc.  Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.&lt;br /&gt;
&lt;br /&gt;
The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not.  Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object.  The code below shows a simple example of a String object becoming tainted.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 #Tainted vs. Untainted&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = String.new             # A new string is created&lt;br /&gt;
 =&amp;gt; &amp;quot;&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?	              # The string is not tainted; there has been no external influence&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = &amp;quot;Hello&amp;quot;	              # Still no external influence&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; false&lt;br /&gt;
 &amp;gt;&amp;gt; my_string = my_string + gets       #Since part of the string now came from the console, it is tainted&lt;br /&gt;
 World!&lt;br /&gt;
 =&amp;gt; &amp;quot;Hello World!\n&amp;quot;&lt;br /&gt;
 &amp;gt;&amp;gt; my_string.tainted?&lt;br /&gt;
 =&amp;gt; true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”.  The $SAFE variable is simply set at the beginning of the program in the way any other variable would be.  For example,&lt;br /&gt;
 $SAFE = 3&lt;br /&gt;
sets Ruby’s “safe level” to 3.&lt;br /&gt;
&lt;br /&gt;
Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted.  There are a few other operations that are also disallowed by Ruby at the various safe levels.  Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object.  The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level.  Below are some highlight of each safe level.&lt;br /&gt;
&lt;br /&gt;
 $SAFE = 0&lt;br /&gt;
    Default “Safe Level”&lt;br /&gt;
    No additional security features&lt;br /&gt;
    All operations allowed on all untainted and tainted variables&lt;br /&gt;
 $SAFE &amp;gt;= 1&lt;br /&gt;
    Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.&lt;br /&gt;
    Loading a file using a string that is tainted is disallowed.&lt;br /&gt;
    Executing system commands using a tainted string is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 2&lt;br /&gt;
    Loading a file from a source that is writable by ‘world’ is disallowed.&lt;br /&gt;
 $SAFE &amp;gt;= 3&lt;br /&gt;
    All object created are tainted and no object may not be untainted using the untaint method.&lt;br /&gt;
 $SAFE &amp;gt;= 4&lt;br /&gt;
    Essentially creates a Sandbox (an isolated, safe, place to run untrused code)&lt;br /&gt;
    Writing to files is disallowed&lt;br /&gt;
    Modifying global variable is disallowed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby’s unbounded polymorphism functionally is arguably very powerful.  However this power functionally could also create a potential problem with code developed.  Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type.  If that object looks like another object, it can be treated as that object.&lt;br /&gt;
&lt;br /&gt;
If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism.  Consider the code below.&lt;br /&gt;
&lt;br /&gt;
 Class Good_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... # some good code&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... # some more good code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 Class Bad_code&lt;br /&gt;
      def good_method&lt;br /&gt;
           ... #some BAD code, that looks good&lt;br /&gt;
      end&amp;lt;br&amp;gt;&lt;br /&gt;
      def another_good_method&lt;br /&gt;
           ... #some more bad code&lt;br /&gt;
      end&lt;br /&gt;
 end&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
 def my_method(good_code)&lt;br /&gt;
      good_code.good_method&lt;br /&gt;
      good_code.another_good_method&lt;br /&gt;
 end&amp;lt;br&amp;gt;&lt;br /&gt;
 my_method(Bad_code.new)&lt;br /&gt;
&lt;br /&gt;
In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object.  The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.&lt;br /&gt;
&lt;br /&gt;
'''''Automatic Bounds Checking'''''&amp;lt;br&amp;gt;&lt;br /&gt;
Ruby automatically checks bounds of data structures such as arrays.  Bounds checking is very important to creating a secure system.  If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.&lt;br /&gt;
&lt;br /&gt;
'''''Cryptographic Libraries'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash).  Ruby provides, built in, only a very limited set of cryptographic functionally.  One such function is the String classes crypt method.&lt;br /&gt;
&lt;br /&gt;
There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2].  The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.&lt;br /&gt;
&lt;br /&gt;
'''''Survey of Current and Past Publish Security Vulnerabilities'''''&amp;lt;br&amp;gt;&lt;br /&gt;
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[1] Hunt, Andrew and Thomas David.  &amp;quot;Programming Ruby, The Pragmatic Programmer's Guide&amp;quot;.&amp;lt;br&amp;gt;&lt;br /&gt;
[2] &amp;quot;Crypt&amp;quot; Library Website: http://crypt[dot]rubyforge[dot]org/&amp;lt;br&amp;gt;&lt;br /&gt;
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Wolf27</name></author>
	</entry>
</feed>