Basics of Rails Security

Presented at CodeMash v2.0.1.5. Originally titled "What to say when they ask you about security", which turned out to be dumb.

Transcript

1. BASICS OF RAILS APP S E C U R I T Y
2. @joncanady
4. What does “secure” really mean?
5. No app can ever be 100% secure
6. The Internet Clock isn’t 100% secure
7. Your Rails app isn’t gonna be 100% secure
8. But you can prevent the most common attacks!
11. Things that will ruin your day
12. Things that will ruin your day DATA
13. Things that will ruin your day DATA USERS
14. Things that will ruin your day DATA USERS CODE
15. Things that will ruin your day DATA USERS CODE
21. INJECTION ATTACK
22. Comment.where( "comment = '#{params[:search]}'" )
23. Comment.where( "comment = '#{params[:search]}'" ) SELECT * FROM comments WHERE comment = 'AWESOME!'
24. Comment.where( "comment = '#{params[:search]}'" ) SELECT * FROM comments WHERE comment = ' '; DROP TABLE users; --'
25. Comment.where( comment: params[:search] )
26. Comment.where( comment: params[:search] ) SELECT * FROM comments WHERE comment = ' ''; DROP TABLE users; --'
27. Comment.where( "comment LIKE '%#{params[:search]}%'" )
28. Comment.where( "comment LIKE '%#{params[:search]}%'" ) SELECT * FROM comments WHERE comment = '% '; DROP TABLE users; --%'
29. Comment.where( ["comment LIKE ?", "%#{params[:search]}%"] )
30. Comment.where( ["comment LIKE ?", "%#{params[:search]}%"] ) SELECT * FROM comments WHERE comment = '% ''; DROP TABLE users; --%'
31. RECAP
32. RECAP SQL queries are dangerous!
33. RECAP SQL
34. RECAP SQL SHELL
35. RECAP SQL SHELL CUSTOM LOGS
36. RECAP SQL SHELL CUSTOM LOGS LDAP
37. RECAP User supplied data can not be trusted
41. XSS ATTACK
42. <h1> Search Results for <%= params[:search] %> </h1>
43. <h1> Search Results for <b>LULZ</b> </h1>
44. <h1> Search Results for <%= params[:search].html_safe %> </h1>
45. <h1> Search Results for <%= raw(params[:search]) %> </h1>
46. # Display a comment from the database def display_comment comment "<span>#{comment}</span>".html_safe end
47. RECAP
48. RECAP Any external data can not be trusted
50. /comments/120/edit
53. These are called DIRECT OBJECT REFERENCES
54. Rails looooooves DIRECT OBJECT REFERENCES
55. Rails looooooves DIRECT OBJECT REFERENCES (easily guessable)
56. class Comment < ActiveRecord::Base before_create :set_token def set_token self.token = SecureRandom.hex(8) end end
57. class Comment < ActiveRecord::Base def to_param token end end
58. /comments/120/edit
59. /comments/69922a61c5
60. RECAP
61. RECAP Never give your attackers free information
62. Things that will ruin your day DATA USERS CODE
64. /comments/120/edit
65. Why can our users modify things they don’t own, anyway?
66. class CommentsController < ApplicationContro def edit @comment = Comment.find( params[:id] ) end end
67. class CommentsController < ApplicationContro before_filter :authorize_and_load def authorize_and_load @comment = Comment.find params[:id] unless @comment.author == current_user raise "Nope" end end end
71. class TaskController < ApplicationController def update unless current_user.can_assign_to?( params[:task][:user]) params[:task].delete(:user) end end end
73. RECAP Is the user supposed to be able to do that?
74. <img src="http://website.com/ projects/images/15.jpg">
75. <img src="http://website.com/ projects/15/delete">
76. <img src="http://website.com/ projects/15/update? owner_id=125”>
77. CROSS SITE REQUEST FORGERY
78. Good news! You’re probably safe!
79. Rails.application.routes.draw do resources :products do resources :comments end end
80. GET GET GET GET /products/ /products/1/ /products/1/edit /products/new
81. GET requests should never change state
82. POST PUT DELETE /products/ /products/1/ /products/1/
83. State changes happen in non-GET requests only
84. class ApplicationController < ActionCon protect_from_forgery( with: :exception ) end
85. Stick to the Rails conventions
86. Safe from CSRF attacks
87. UNLESS
88. You turn off protect_from_forgery
89. You have other vulnerabilites that make CSRF possible
90. RECAP Rails’ routing conventions exist for a reason
91. RECAP Rails’ routing conventions exist for a reason
92. PASSWORD HASHING
93. class User < ActiveRecord::Base # have a password_digest column on # your table has_secure_password end
95. SESSION TIMEOUTS
96. Not everyone is on a machine they own
97. Rails.application.config.session_store( :cookie_store, key: '_codemash_session', expire_after: 30.minutes )
103. SESSION FIXATION
104. class SessionController < ApplicationCo def create # user logs in successfully reset_session end end
106. Things that will ruin your day DATA USERS CODE
107. SECURITY MISCONFIGURATION
108. We already covered plenty of these
111. Rails.application.config.session_store( :cookie_store, key: '_codemash_session', expire_after: 30.minutes )
112. How do you catch errors in config files?
114. brakemanscanner.org
115. KNOWN VULNERABILITIES
117. Each line in your Gemfile is another security hole waiting to happen
118. Are you on the latest
 Rails?
119. Are you on the latest
 Ruby?
120. Are you on the latest
 Devise?
121. WHY NOT?
122. How would you know if any of these projects had a security hole?
123. What does “secure” really mean?
124. You’re constantly questioning assumptions
125. What is this data, and how are we using it?
126. Who is this user, and what can they do?
127. Does our code really do what we thought?