CSC/ECE 517 Fall 2009/wiki1b 8 va

Currently being edited by Salt!

+++ 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 a major problem 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 holes have not yet been addressed. [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 can better handle inputs, but unexpected inputs may be processed, causing the need for greater input testing.
• Largely automated design (Ruby and Rails) - This helps reduce coding errors which mitigates some security issues
• protect_from_forgery command (Rails)
• Active Record for SQL Database Manipulation (Rails)
• 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

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: Tarantula

• 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 specially 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 has SafeErb plugin also which reminds about output escaping if the programmer forgets to code for that.

• 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 that 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. Rail has helper methods to defend this problem. Rails has 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.

Virtual machine: Ruby and Rails are command line interpreted and do not depend on the OS implementation. This helps prevent this error also.

• 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)

• CWE-209: Error Message Information Leak

   _______

Category: Risky Resource Management

 * CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
   ______
 * CWE-642: External Control of Critical State Data
   _______ 
 * CWE-73: External Control of File Name or Path

_______

• 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

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

Use the clearance tool

• 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.

• 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 to be developed and tested.

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 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

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

4. Thomas 2005, pp. 398 - 401

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