Security on Rails Jonathan Weiss, 03.09.2008 Peritor GmbH Who are - - PowerPoint PPT Presentation

▶
security on rails
SMART_READER_LITE
LIVE PREVIEW

Security on Rails Jonathan Weiss, 03.09.2008 Peritor GmbH Who are - - PowerPoint PPT Presentation

Feb 02, 2024 328 likes •816 views

Security on Rails Jonathan Weiss, 03.09.2008 Peritor GmbH Who are we? Jonathan W Jonathan Weiss eiss Consultant for Peritor GmbH in Berlin Specialized in Rails, Scaling, Security, and Code Review Webistrano - Rails deployment tool

slide-1
SLIDE 1

Security on Rails

Jonathan Weiss, 03.09.2008 Peritor GmbH

slide-2
SLIDE 2

2

Who are we?

Jonathan W Jonathan Weiss eiss

  • Consultant for Peritor GmbH in Berlin
  • Specialized in Rails, Scaling, Security, and Code Review
  • Webistrano - Rails deployment tool
  • FreeBSD Rubygems and Ruby on Rails maintainer

http://www.peritor.com http://blog.innerewut.de

slide-3
SLIDE 3

3 3

Agenda

Application code Setup and deployment Framework code Rails Application Stack

Follow the application stack Follow the application stack and look for and look for

  • Information leaks
  • Possible vulnerabilities
  • Security best practices
slide-4
SLIDE 4

4

Rails Application Setup

slide-5
SLIDE 5

5

Rails Setup

slide-6
SLIDE 6

6

Rails Setup - FastCGI

slide-7
SLIDE 7

7

Rails Setup - Mongrel

slide-8
SLIDE 8

8

Rails Setup – mod_rails

slide-9
SLIDE 9

9

Information leaks and vulnerabilities

slide-10
SLIDE 10

10

Information leaks

Is the target application a Rails application?

  • Default setup for static files:

/javascripts/application.js /stylesheets/application.css /images/foo.png

  • Pretty URLs

/project/show/12 /messages/create /folder/delete/43 /users/83

slide-11
SLIDE 11

11

Information leaks

Is the target application a Rails application?

  • Rails provides default templates for 404 and 500 status pages
  • Different Rails versions use different default pages
  • 422.html only present in applications generated with Rails >= 2.0
slide-12
SLIDE 12

12

Sample Status Pages

http://www.twitter.com/500.html http://www.43people.com/500.html http://www.strongspace.com/500.html Rails >= 1.2 status 500 page

slide-13
SLIDE 13

13

Server Header

GET http://www.43people.com Date: Wed, 03 Sep 2008 11:23:24 GMT Server: Apache/1.3.34 (Unix) mod_deflate/1.0.21 mod_fastcgi/2.4.2 mod_ssl/2.8.25 OpenSSL/0.9.7e-p1 Cache-Control: no-cache … GET https://signup.37signals.com/highrise/solo/signup/new Date: Wed, 03 Sep 2008 11:54:24 GMT Server: Mongrel 1.1.5 Status: 200 OK … # httpd.conf Header unset Server

Disable Server header

slide-14
SLIDE 14

14

Information leaks

Subversion metadata

  • Typically Rails applications are deployed with Capistrano / Webistrano
  • The default deployment will push .svn directories to the servers

GET http://www.strongspace.com/.svn/entries … dir 25376 http://svn.joyent.com/joyent/deprecated_repositories/www.strongspace/trunk/public http://svn.joyent.com/joyent 2006-04-14T03:06:39.902218Z 34 justin@joyent.com …

<DirectoryMatch "^/.*/\.svn/"> ErrorDocument 403 /404.html Order allow,deny Deny from all Satisfy All </DirectoryMatch>

Prevent .svn download

slide-15
SLIDE 15

15

Cookie Session Storage

Since Rails 2.0 by default the session data is stored in the cookie

Base64(CGI::escape(SESSION-DATA))--HMAC(secret_key, SESSION-DATA)

slide-16
SLIDE 16

16

Cookie Session Storage

Security implications

  • The user can view the session data in plain text
  • The HMAC can be brute-forced and arbitrary session data could be created
  • Replay attacks are easier as you cannot flush the client-side session

Countermeasures

  • Don’t store important data in the session!
  • Use a strong password,

Rails already forces at least 30 characters

  • Invalidate sessions after certain time on the server side

… or just switch to another session storage

slide-17
SLIDE 17

17

Cookie Session Storage

Rails default session secret Set HTTPS only cookies

slide-18
SLIDE 18

18

Cross-Site Scripting - XSS

“The injection of HTML or client-side Scripts (e.g. JavaScript) by malicious users into web pages viewed by other users.”

slide-19
SLIDE 19

19

Cross-Site Scripting - XSS

Cases of accepted user input

  • No formatting allowed

search query, user name, post title, …

  • Formatting allowed

post body, wiki page, …

slide-20
SLIDE 20

20

XSS - No Formatting Allowed

Use the Rails `h()` helper to HTML escape user input But using `h()` everywhere is easy to forget

  • Use safeERB or XSS Shield plugin
  • safeERB will raise an exception whenever a tainted string is not escaped
  • Explicitly untaint string in order to not escape it

http://agilewebdevelopment.com/plugins/safe_erb http://code.google.com/p/xss-shield/

slide-21
SLIDE 21

21

XSS - Formatting Allowed

Two approaches

Use custom tags that will translate to HTML (vBulletin tags, RedCloth, Textile, …) Use HTML and remove unwanted tags and attributes

  • Blacklist - Rails 1.2
  • Whitelist - Rails 2.0
slide-22
SLIDE 22

22

XSS - Custom Tags

Relying on the external syntax is not really secure

Filter HTML anyhow

slide-23
SLIDE 23

23

XSS - HTML Filtering

Use the Rails `sanitize()` helper

Only effective with Rails 2.0 (Whitelisting):

  • Filters HTML nodes and attributes
  • Removes protocols like “javascript:”
  • Handles unicode/ascii/hex hacks
slide-24
SLIDE 24

24

XSS - HTML Filtering

sanitize(html, options = {}) http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html

slide-25
SLIDE 25

25

XSS - HTML Filtering

Utilize Tidy if you want to be more cautious

slide-26
SLIDE 26

26

Session Fixation

Provide the user with a session that he shares with the attacker:

slide-27
SLIDE 27

27

Session Fixation

Rails uses only cookie-based sessions Still, you should reset the session after a login The popular authentication plugins like restful_authentication are not doing this!

slide-28
SLIDE 28

28

Cross-Site Request Forgery - CSRF

You visit a malicious site which has an image like this Only accepting POST does not really help

slide-29
SLIDE 29

29

CSRF Protection in Rails

By default Rails 2.0 will check all POST requests for a session token All forms generated by Rails will supply this token

slide-30
SLIDE 30

30

CSRF Protection in Rails

Very useful and on-by-default, but make sure that

  • GET requests are safe and idempotent
  • Session cookies are not persistent (expires-at)
slide-31
SLIDE 31

31

SQL Injection

The user’s input is not correctly escaped before using it in SQL statements

slide-32
SLIDE 32

32

SQL Injection Protection in Rails

Always use the escaped form If you have to manually use a user-submitted value, use `quote()`

slide-33
SLIDE 33

33

SQL Injection Protection in Rails

Take care with Rails < 2.1 Limit and offset are only escaped in Rails >= 2.1 ( MySQL special case )

slide-34
SLIDE 34

34

JavaScript Hijacking

http://my.evil.site/ JSON response The JSON response will be evaled by the Browser’s JavaScript engine. With a redefined `Array()` function this data can be sent back to http://my.evil.site

slide-35
SLIDE 35

35

JavaScript Hijacking Prevention

  • Don’t put important data in JSON responses
  • Use unguessable URLs
  • Use a Browser that does not support the redefinition of Array & co,

currently only FireFox 3.0

  • Don’t return a straight JSON response, prefix it with garbage:

The Rails JavaScript helpers don’t support prefixed JSON responses

slide-36
SLIDE 36

36

Mass Assignment

User model

slide-37
SLIDE 37

37

Mass Assignment

Handling in Controller A malicious user could just submit any value he wants

slide-38
SLIDE 38

38

Mass Assignment

Use `attr_protected` and `attr_accessible` Start with `attr_protected` and migrate to `attr_accessible` because of the different default policies for new attributes. Vs.

slide-39
SLIDE 39

39

Rails Plugins

Re-using code through plugins is very popular in Rails Plugins can have their problems too

  • Just because somebody wrote and published a plugin it doesn’t mean the plugin is

proven to be mature, stable or secure

  • Popular plugins can also have security problems, e.g. restful_authentication
  • Don’t use svn:externals to track external plugins,

if the plugin’s home page is unavailable you cannot deploy your site

slide-40
SLIDE 40

40

Rails Plugins

How to handle plugins

  • Always do a code review of new plugins and look for obvious problems
  • Track plugin announcements
  • Track external sources with Piston, a wrapper around svn:externals

http://piston.rubyforge.org/

slide-41
SLIDE 41

41

Rails Denial of Service Attacks

Rails is single-threaded and a typical setup concludes:

  • Limited number of Rails instances
  • ~8 per CPU
  • Even quite active sites (~500.000 PI/day ) use 10-20 CPUs
  • All traffic is handled by Rails
slide-42
SLIDE 42

42

Rails Denial of Service Attacks

A denial of service attack is very easy if Rails is handling down/uploads. Just start X (= Rails instances count) simultaneous down/uploads over a throttled line. This is valid for all slow requests, e.g.

  • Image processing
  • Report generation
  • Mass mailing
slide-43
SLIDE 43

43

Rails Slow Request DoS Prevention

Serve static files directly through the web server

  • Apache, Lighttpd, nginx (use x-sendfile for private files)
  • Amazon S3

Contaminate slow requests

  • Define several clusters for several tasks
  • Redirect depending on URL

Put slow requests into the background

  • Fast request to create a background

job

  • Query job status with Ajax
slide-44
SLIDE 44

44

Conclusion

slide-45
SLIDE 45

45

Conclusion

Rails has many security features enabled by default

  • SQL quoting
  • HTML sanitization
  • CSRF protection

The setup can be tricky to get right Rails is by no means a “web app security silver bullet” but adding security is easy and not a pain like in many other frameworks

slide-46
SLIDE 46

46

Questions?

slide-47
SLIDE 47

47 47

Peritor GmbH Teutonenstraße 16 14129 Berlin Telefon: +49 (0)30 69 20 09 84 0 Telefax: +49 (0)30 69 20 09 84 9 Internet: www.peritor.com E-Mail: kontakt@peritor.com

Peritor GmbH - Alle Rechte vorbehalten