CSC/ECE 517 Fall 2009/wiki1b 8 va

From Expertiza_Wiki
Jump to navigation Jump to search

+++ 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 reduce the risks.

Built in features that can enhance security

  • Largely automated design
  • Virtual machine (lack of direct access to OS commands)
  • duck typing ______ (this can be a good or bad thing)
  • Test case tools such as Test unit built in to Aptana's ruby plug-in for Eclipse
  • protect_from_forgery command

Tools and plugins

(Is this outside the scope, revisit later, lets get the basics down first) _______

  • 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

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.

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: 
   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})

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:: 
   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')

Virtual machine: Ruby and Rails are command line interpreted and do not depend on the OS implementation. This helps prevent this error as well as preventing other errors.

  • CWE-319: Cleartext Transmission of Sensitive Information
  • CWE-352: Cross-Site Request Forgery (CSRF)

Rails 2 or higher has a feature called protect_from_forgery which is specifically designed to combat attacks such as this.

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

References

External Links

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_8_va&oldid=19846"