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 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
   Same as above 
 * CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
   This is hardly a problem in most Rails applications. A popular goal of SQL injection attacks is to bypass authorization. SQL injection can also happen by influencing database queries by manipulating web application parameters.    

Automated handling of SQL databases

 * CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting') 
   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

• CSC 517

External Links

• http://www.sans.org/top25errors/#s4 - Lists top 25 errors by category
• http://guides.rubyonrails.org/security.html
• _____ Add links for plugins