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. 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, however not all items are covered 3

Built in features that can enhance security

• Largely automated design - This helps reduce coding errors which mitigates some security issues
• Virtual machine (lack of direct access to OS commands)
• Polymorphism
• Test case tools such as Test unit built in to Aptana's Ruby plug-in for Eclipse
• protect_from_forgery command

Tools and plugins

• Cucumber - Outside in test: (elaborate, add link) ________
• Tarantula - A web site that tests applications for common vulnerabilities (add link) _____
• R-spec - Another testing unit built in with eclipse which provides documentation capabilities
• Clearance - A gem used to perform user login with hashed passwords

Common security errors and their mitigations

____ (Should we summarize the list later? This may be copying too much from the site http://www.sans.org/top25errors/#s4. Perhaps we don't need to show the mitigation of each error, just how certain features mitigate certain errors. Perhaps we could make a table)

Category: Insecure Interaction Between Components

• CWE-20: Improper Input Validation

duck typing? Ruby and Rails: Test case tools 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.

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

Tarantula

• 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
 _______ No mitigation?
 * CWE-404: Improper Resource Shutdown or Release
 _______ Garbage collection?
 * CWE-665: Improper Initialization
 Test unit / R-spec, Tarantula 
 * CWE-682: Incorrect Calculation 
 Test unit / R-spec

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
 Tarantula
 * CWE-330: Use of Insufficiently Random Values 
 _______ (Does Ruby have a good default random number generator?)
 * CWE-250: Execution with Unnecessary Privileges 
 _______
 * CWE-602: Client-Side Enforcement of Server-Side Security 
 _______

How Ruby and Rails security compares to other platforms

______ (Fill in with a few of the more common platforms. It appears on the surface that ruby and rails has many more tools to assist in security than other platforms, but we need to research this)

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

External Links

• http://guides.rubyonrails.org/security.html
• http://www.sans.org/top25errors/#s4
• _____ Add links for plugins