CSC/ECE 517 Fall 2009/wiki1b 8 va

+++ Remove these lines between the +++ when done, this is to keep us on track: _________ Note: the blanks are indications of where more work needs to be done () indicates things we need to consider / work on

Wiki topic: Today’s web developers must absolutely consider application security as they develop and deploy web applications. At the start of this year, several organizations jointly released a list of “the 25 Most Dangerous Programming Errors and How to Fix Them.” Show how the design of Ruby and Rails helps mitigate these common errors. How do Ruby and Rails compare to other Web frameworks in defending against these problems? +++

Security errors are one of the most serious problems in today's applications. These errors can result in many undesirable effects, including lost profits, comprimise of sensitive information, or even damage to the system. Ruby on Rails has many features that automatically prevent security holes. There are additional tools and plugins for Ruby and Rails that can further reduce the risks. Some of the security errors have not yet been addressed by Ruby and Rails. [3]

Built in features that can enhance security

• Safety levels (Ruby) - Ruby can limit how tainted (externally supplied) data is supplied. Meaningful values range from 0 to 4, with 0 being no safety check and increasing levels of security to 4 being the most secure (and most restrictive). Set with $SAFE = number in the Ruby program or the -T command from the command line. [4]
• Parametric Polymorphism (Ruby) - This language feature can handle a wide variety of inputs without crashing, but unexpected inputs may be processed in unexpected ways, causing the need for greater input testing. Tools have been developed to perform this testing.
• protect_from_forgery command (Rails)
• Active Record for SQL Database Manipulation (Rails) - This is a built in class for securely acessing the SQL database.
• Automatically generated finder methods (Rails) - These methods access the database and are secure against SQL injection attacks [6]
• Largely automated design (Ruby and Rails) - This helps reduce coding errors which mitigates some security issues
• Virtual machine (Ruby and Rails)
• Test case tools such as Test unit built in to Aptana's Ruby plug-in for Eclipse (Ruby and Rails)

Tools and plugins

• Tarantula - A tool that tests applications for common vulnerabilities. This is new and is still in development.
• R-spec - Another testing unit built in with eclipse which provides documentation capabilities
• Clearance - A gem used to perform user login with hashed passwords
• Safe-ERB - A plugin used to counteract the Cross Site Scripting attack.
• Sandbox (Ruby) - Prevents damage to other applications

Common security errors and their mitigations [1]

Category: Insecure Interaction Between Components

• CWE-20: Improper Input Validation ///ref http://github.com/relevance/tarantula

Ruby and Rails provides Test Unit which should be used to test for this. Polymorphism in Rails makes it very important to perform these checks. Rails has a plugin tarantula, a fuzzy spider. It crawls the rails application, fuzzing inputs and analyzing what comes back.

• CWE-116: Improper Encoding or Escaping of Output /////ref http://guides.rubyonrails.org/security.html

It is important to escape the output of web applications especially when redisplaying user input that was not input-filtered. Ruby uses escapeHTML() method to replace the HTML input characters &, ", <, > by their uninterpreted representations in HTML (&, ", <, and >). Rails' sanitize() method is a good solution to fend off encoding attacks. Output escaping is easily forgotten by programmer to code. Rail also has the SafeErb plugin which reminds the programmer about output escaping if this is forgotten.

• CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')

Ruby has a solution for this. Popular goals of SQL injection attacks are to bypass authorization or carry out data manipulation or reading arbitrary data. SQL injection can also happen by influencing database queries by manipulating web application parameters. Ruby on Rails has a built in filter for special SQL characters, which will escape ’, ", NULL character and line breaks. Instead of passing a string to conditions options an array or an hash can be passed to sanitize tainted strings. Furthermore, Rails has predefined Active Record functions to access the database. These functions are designed to prevent SQL injection attacks from succeeding.

• Example: How ruby mitigates problem of bypassing authorization: /////ref http://guides.rubyonrails.org/security.html

   Use of User.find(:first, "login = '#{params[:name]}' AND password = '#{params[:password]}'") 

Input of ’ OR ‘1’=‘1 as name, and ’ OR ’2’>’1 as password will create the following query:

   "SELECT * FROM users WHERE login =  OR '1'='1' AND password =  OR '2'>'1' LIMIT 1"  

The above query will find first record from user table and grant access to the user. In Ruby, Model.find(id) can be used in model to mitigate the problem of bypassing authorization. Array and hash are only available in model. There is one function sanitize_sql() which can be used in other places for this purpose.

   Model.find(:first, :conditions => {:login => entered_user_name, :password => entered_password})  

• CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting(XSS)')

This attack injects client side executable code. Cross site scripting can hijack the session, steal the cookie, display advertisements for the benefit of the attacker, change elements on the web site to get confidential information, redirect the victim to a fake website or install malicious software through security holes in the web browser.

To avoid XSS it is important to filter out malicious inputs and escape output of web application. Rather than blacklisting inputs it is good to create a white list describing the allowed values because blacklist never ends. Rails has helper methods to defend against this problem. Rails has the sanitize() method for this whitelist approach. sanitize() also defends encoding injection attacks.

• Example:: /////ref http://guides.rubyonrails.org/security.html

   Attacker injects code to show an alert as follows
   strip_tags("some<script>alert('hello')</script>") 
   Use of Rail's sanitize method
   tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br cite sub sup ins p) 
   s = sanitize(user_input, :tags => tags, :attributes => %w(href title)) 

Safe-ERB is another plugin developed specifically to counter this threat.

• CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')

Ruby has system(command, parameters) method which defends this attack.

• Example::

   system("/bin/echo","Hello Sam; rm *")

It prints "Hello Sam; rm*". rm* doesn't work here.

Increasing the $SAFE parameter to 1 or greater should also reduce the potential damage of these attacks.

• CWE-319: Cleartext Transmission of Sensitive Information

_______

• CWE-352: Cross-Site Request Forgery '(CSRF)'

Ruby on Rails is pretty strong to prevent this attack. Rails 2 or higher has a feature called protect_from_forgery which is specifically designed to combat attacks such as this. Use of GET and POST can prevent CSRF. Ruby has a verify method which is defined in controller to make sure that specific actions may not be used over GET.

• Example:: /////ref http://guides.rubyonrails.org/security.html

   verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}

In the above example if transfer action comes from any other web it redirects to action list. So, CSRF will never happen.

• CWE-362: Race Condition

Ruby and Rails has testing tools (test unit / R-spec) which may be able to detect this. However, these testing tools may not catch such errors in all cases.

Example::

   Assume these two pieces of code can run in parallel
   Code section A    Code Section B
   @balance = 500     @balance = @balance + 100
   @puts balance

In the above example, the balance will usually read 500 from code section A. However, if the first line of code section A executes, then the Code Section B executes, then the print statement in A executes, the balance would read 600. The standard testing tools would most likely miss this error because it would happen very rarely. _______ verify

• CWE-209: Error Message Information Leak

_______

Category: Risky Resource Management

• CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer

Ruby doesn't give direct access to memory in comparison to other languages like C or C++. This feature of Ruby defends this kind of attack.

• CWE-642: External Control of Critical State Data

_______

• CWE-73: External Control of File Name or Path

The Ruby $SAFE parameter may be used to protect against this

• CWE-426: Untrusted Search Path

_______

• CWE-94: Failure to Control Generation of Code (aka 'Code Injection')

Ruby allows this, but only if the developer writes the program to allow it. If such functionality is provided in an application, it should be tested extensively. Another mitigation is that Ruby is run in a virtual machine. This somewhat limits the damage that could be done (e.g. someone should not be able to format your C: drive (erase everything) from a remote site through a ruby application. There is still significant risk in allowing users to add their own code, and this functionality should be used sparingly, and tested thoroughly.

• CWE-494: Download of Code Without Integrity Check

One way to fend off this attack is to digitally sign all binaries the programmer ship to customers with a private key and certificate issued by a trusted certification authority. Ruby has features to prevent this [5]. Sandboxes may be used to limit what damage the code can do, and parsers may be used to check the code before executing it.

• CWE-404: Improper Resource Shutdown or Release

_______ Garbage collection?

• CWE-665: Improper Initialization

Test unit / R-spec, Tarantula

• CWE-682: Incorrect Calculation

Test tools may be used to spot these errors. Test unit is provided with Rails, and R-spec is another test tool which may be used.

Category: Porous Defenses

• CWE-327: Use of a Broken or Risky Cryptographic Algorithm

This is up to the developer, but there are tools such as clearance (a password utility) that can work with this.

• CWE-259: Hard-Coded Password

Rail has Clearance and Cucumber for this. Clearance is a tool for authentication with e-mail and password. Authentication check may be required as the application evolves and cucumber is used for that.

• Example:: /////Ref http://github.com/thoughtbot/clearance/

   def path_to(page_name)
   case page_name
   ...
   when /sign up page/i
   new_user_path
   when /sign in page/i
   new_session_path
   when /password reset request page/i
   new_password_path
   ...
   end

• CWE-732: Insecure Permission Assignment for Critical Resource

________

• CWE-330: Use of Insufficiently Random Values

_______ (Does Ruby have a good default random number generator?)

• CWE-250: Execution with Unnecessary Privileges

Developers should use the minimum set of privileges required and reduce privileges when they are no longer needed. ______ Are there any tools to specifically help with this?

• CWE-602: Client-Side Enforcement of Server-Side Security

Active record (within rails) provides the attr_protected method which is used to protect records of the database. This allows the developer to specify which attributes to protect. Alternatively, attr_accessible can be used to protect everything except the values listed. Tarantula may detect this vulnerability through its fuzzed inputs test.

How Ruby and Rails security compares to other platforms

______ (Fill in information on a few of the more common platforms.) Ruby and Rails are fairly new. Security tools are currently being developed to combat many of the common security errors, but many of these tools have not reached maturity. Some are difficult to locate, install or use. Some are not yet well developed and are likely to miss common flaws. Most other languages have been around for longer so security tools have had more time for improvement.

One positive thing about Ruby and Rails is that they were built with security in mind. If security tools continue to be developed and incorporated into Ruby and Rails, the applications developed on them are likely to become more secure than those developed in other languages. Many languages were not originally developed with security in mind.

References

1. http://www.sans.org/top25errors/#s4 - Lists top 25 errors by category

2. http://guides.rubyonrails.org/security.html - Security features of Ruby

3. http://www.quarkruby.com/2007/9/20/ruby-on-rails-security-guide - Security features of Ruby

4. http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=5054914&isnumber=5054895 - Top 25 errors

5. http://www.example-code.com/ruby/rubycerts.asp

6. Thomas 2006, pp. 398 - 401

7. Ruby 2009, pp. 637 - 650

Books referenced

• Thomas, Dave (2006). Programming Ruby, The Pragmatic Programmers' Guide.
• Ruby, Sam et al. (2009). Agile Web Development with Rails, Third Edition.

External Links

• http://guides.rubyonrails.org/security.html
• http://www.securityinnovation.com/application-security-testing-analysis-training.htm - Security tools for other languages (C++, C#, Java)
• http://www.owasp.org/ - Open Web Security Application Project