|
| 1 | +Securing Your Rails Application |
| 2 | + |
| 3 | +Rails defaults are actually pretty good for security, but you still need to learn about this. |
| 4 | + |
| 5 | +Don't trust browser, don't trust database; trust the app server |
| 6 | + |
| 7 | +SQL injection prevention - use question mark in conditions |
| 8 | + |
| 9 | +White List is better than Black List |
| 10 | + * use attr_accessible (white list), not attr_protected (black list) |
| 11 | + |
| 12 | +Session Keys: |
| 13 | + * Read "A Lesson in Timing Hacks" article for explanation |
| 14 | + |
| 15 | +Detect social network authentication status: |
| 16 | + * using js in client can make a call to FB and find out if user is logged in |
| 17 | + |
| 18 | +XSS (Cross-Site Scripting) |
| 19 | + * HTML escape user submitted data when re-displaying data in view (use <=h %> in pre Rails3; don't use <%=raw %> in Rails3) |
| 20 | + * whitelist HTML tags if you need to allow HTML tags (or use Markdown, Redcloth, Textile, etc) |
| 21 | + * do not use a black list, do not try to correct malicious code |
| 22 | + * use sanitize Rails helper and don't try to write your own |
| 23 | + |
| 24 | +Authentication != Authorization |
| 25 | + * Authentication: who are you? |
| 26 | + * Authorization: who do you want? or What are you allowed to do? |
| 27 | + * don't blindly accept params[:id] or params[:xxx_id] values. Make sure user is allowed to access the record identified by id |
| 28 | + * do this (check for current_user 1st to avoid whiny nils): |
| 29 | + if @whatever=current_user.whatevers.find(params[:whatever_id]) |
| 30 | + # everything is safe and OK |
| 31 | + else |
| 32 | + # bad user. deny!!! |
| 33 | + end |
| 34 | + |
| 35 | +CanCan by Ryan Bates: |
| 36 | + * good authorization scheme |
| 37 | + |
| 38 | +CSRF (Cross Site Request Forgery): |
| 39 | + * the authenticity token thing for form submits is a good thing |
| 40 | + * XSS can still default CSRF (when user clicks on something they shouldn't) |
| 41 | + * SSL - can prevent a lot of stuff - Strict Site Security (I think is the name, slide moved by too fast) |
| 42 | + * offer users an option to always use SSL |
| 43 | + OR |
| 44 | + * just force SSL for everything during login, while logged in, and until logout (after logout, really) |
| 45 | + |
| 46 | +Security patches: |
| 47 | + * keep up to date. |
| 48 | + * even older versions of rails get security patches. Updating a minor release is easy. |
| 49 | + * monitor plugins and gems for updates, too |
| 50 | + * OS updates, of course, too |
| 51 | + * join the Rails security updates mailing list |
| 52 | + * try to upgrade to Rails3 |
| 53 | + |
| 54 | +Do a security audit: |
| 55 | + * you need a fresh set of eyes to find the vulnerabilities that you don't see |
| 56 | + |
| 57 | +Be aware (think like a hacker) |
0 commit comments