Rails and security
0 likes1,427 views
Rails aims to be secure by default but developers still need to be careful. The document outlines several common security issues like mass assignment vulnerabilities, XSS risks, and CSRF concerns. It provides examples of each issue and recommends solutions like using strong parameters, output encoding, and adding CSRF tokens. While Rails improves security with each release, the document emphasizes the importance of following security best practices to protect applications.
![Agenda
● GET Accessible Actions(method “match”, CSRF)
● Mass Assignment(attr_accessible, “SQL Inject”)
● JS(ON) and DOM Injects, Responders and XSS
● Regular Expressions and Validators
● Common Tips
● Headers
● [bonus?] OAuth](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-2-320.jpg)
![case 4
params[:user][:url]="http://#{params[:user][:
url]}" unless params[:user][:url] =~ /^https?/
#update attributes](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-19-320.jpg)
![case 8
#hand-made jsonp
json = Order.all.to_json
render text: "#{params[:callback]}(#{json})"
https://api.github.com/user/repos?
callback=leak](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-30-320.jpg)
![case 8 tips
don't give out private data via JSONP
avoid - render text: contains_user_input
XSS - ?callback=<script>..</script>
use - render json: data, callback: params[:
cb]](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-31-320.jpg)
![case 9 - CVE-2012-2660
Mass assignment[extended edition]. You
can send nested arrays/hashes in any
param.
params[:token] can be a huge array(brute):
?token[]=1&token[]=2&token[]=3...
it also may contain nils!
?token[] <- nil](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-32-320.jpg)
![case 9 - CVE-2012-2660
Change
User.find_by_token(params[:token]) and
User.where(token: params[:token])
use explicit casting
params[:token].to_s](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-33-320.jpg)
![common tips
● use system('ls', '.') instead of `ls .`
● before_filter{headers['X-Frame-Options']
='SAMEORIGIN'}#application_controller.
rb
● hide config/initializers/secret_token.rb
● obvious: check permissions
● WHITELIST
● RTFM](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-34-320.jpg)
![bonus OAuth
Mitigation: CSRF token in 'state' param.
Checking
$_SESSION['state']==$_REQUEST
['session'] IS NOT WORKING
Check existence and equality both.
OR use client side JS based authentication.](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-39-320.jpg)
![references
[old] http://www.rorsecurity.info/
http://guides.rubyonrails.org/security.html
http://developers.facebook.
com/docs/authentication/server-side/
get new stuff 1st!: homakov.blogspot.com](https://image.slidesharecdn.com/railsandsecurity-120612121200-phpapp01/85/Rails-and-security-40-320.jpg)
Rails and security
- 1. Rails & Security People should know it Insecure-by-default means insecure http://homakov.blogspot.com
- 2. Agenda ● GET Accessible Actions(method “match”, CSRF) ● Mass Assignment(attr_accessible, “SQL Inject”) ● JS(ON) and DOM Injects, Responders and XSS ● Regular Expressions and Validators ● Common Tips ● Headers ● [bonus?] OAuth
- 3. Rails ARE Secure ● CSRF Protection by default (authenticity_token) ● XSS Protection(HtmlSafe, sanitize by default) ● SQL Injects are impossible(active record) ● Hundreds of commits with security improvements, etc
- 4. PHP(and others) is not ● if I see PHP site with (proper)CSRF protection than .. it's facebook.com ● SQL Injects, XSS, includes, zomg etc ● "secure by default" just impossible thus rails is more secure than most php sites are...
- 5. BUT
- 7. case 1 #routes.rb #match usage is a common mistake match “/follow”, to: “followings#create” match “/followers, to: “followings#index”
- 8. case 1 Hey, “match” means GET too. GET means no csrf protection!
- 9. case 1 >This commit disallows calling +match+ without an HTTP verb constraint by default. To explicitly match all verbs, this commit also adds a :via => :all option to +match+. (@wycats) #update code: post “/follow”, to: “followings#create” get “/followers, to: “followings#index” match “/getpost_endpoint”, via: :all, to: “etc#etc”
- 10. case 1 tips Make sure to set “post” for state-changing requests. Avoid using of “match” Use “get” for all data retrieval requests. Scope your routes, be RESTful, please.
- 11. case 2 #comments/index.haml :javascript var comments = #{@comments.to_json} OR :javascript var value = "#{current_user.name}"
- 12. case 2 @comments = {k:"</script><script>alert(1) </script>"} JSON Encoder and ':javascript' (:css too!) both don't escape anything - output is RAW.
- 13. case 2 XSS?!
- 14. case 2 tips Update rails to 4(now html entities are escaped by default) or set manually ActiveSupport.escape_html_entities_in_html = true in initializers or don't use .to_json in templates.
- 15. case 3 #comments/index.haml :javascript var data = #{@data.to_json} #or getJSON $('.datacontainer').html(data.body);
- 16. case 3 Pitfall. That is a pure DOM XSS - you didn't sanitize it! Escaping u only helps JSON parser but you should sanitize it before you insert into DOM Don't trust/use any input param until you sanitized it.
- 17. case 3
- 18. case 3 tips Use $.text()/innerText instead of $.html() /innerHTML when possible, always sanitize any user input even in JS(Rails just escapes). I strongly recommend this patch: ActiveSupport::JSON::Encoding:: ESCAPED_CHARS.merge! '<' => '<'
- 19. case 4 params[:user][:url]="http://#{params[:user][: url]}" unless params[:user][:url] =~ /^https?/ #update attributes
- 20. case 4
- 21. case 4 tips Keep in mind - in ruby $^ always match new lines. Your manuals and books lie. Use Az This passes: javascript:alert(1)/* http://hi.com */ added warning/exception in RoR
- 22. case 5 #in application_controller.rb skip_before_filter :verify_authenticity_token
- 23. case 5 tips protect_from_forgery is a MUST. It is a hassle to deal with tokens but don't be stupid. No, presence of authenticity_token input doesn't scare a hacker.
- 24. case 6 found an XSS for auto_link, remember, always *whitelist* everything - protocols too javascript://%0Aalert(1) Update your bundle, if you use auto_link or rails_autolink gem
- 26. case 7 class PublicKey < ActiveRecord::Base #attr_accessible, where are you... end
- 27. case 7
- 28. case 7 Github and Assembla shared the same vulnerability. It was easy to steal or push code into anybody’s repo 'dropping' your public key. Also you could(still can) set “created/updated_at” to 3012 in *really* a lot of applications to have fun and get the 1st place in 'order by *_at'
- 29. case 7 tips If use update_attributes/new/create+hash - you should set attr_accessible(If you don’t use mass assignment - don’t care.) gem 'strong_parameters' whitelist_attributes = true by default. it takes slightly more time to write an app but it’s worth it. IT IS NOT attr_accessor :±
- 30. case 8 #hand-made jsonp json = Order.all.to_json render text: "#{params[:callback]}(#{json})" https://api.github.com/user/repos? callback=leak
- 31. case 8 tips don't give out private data via JSONP avoid - render text: contains_user_input XSS - ?callback=<script>..</script> use - render json: data, callback: params[: cb]
- 32. case 9 - CVE-2012-2660 Mass assignment[extended edition]. You can send nested arrays/hashes in any param. params[:token] can be a huge array(brute): ?token[]=1&token[]=2&token[]=3... it also may contain nils! ?token[] <- nil
- 33. case 9 - CVE-2012-2660 Change User.find_by_token(params[:token]) and User.where(token: params[:token]) use explicit casting params[:token].to_s
- 34. common tips ● use system('ls', '.') instead of `ls .` ● before_filter{headers['X-Frame-Options'] ='SAMEORIGIN'}#application_controller. rb ● hide config/initializers/secret_token.rb ● obvious: check permissions ● WHITELIST ● RTFM
- 35. #DISCUSS Security is not developers' business. Web is poorly designed: Clickjacking, CSRF
- 36. bonus
- 37. bonus OAuth CSRF + GET. code/token getting into master-account with no fingerprints. omniauth fb strategy vulnerability depends on server side logic
- 39. bonus OAuth Mitigation: CSRF token in 'state' param. Checking $_SESSION['state']==$_REQUEST ['session'] IS NOT WORKING Check existence and equality both. OR use client side JS based authentication.
- 40. references [old] http://www.rorsecurity.info/ http://guides.rubyonrails.org/security.html http://developers.facebook. com/docs/authentication/server-side/ get new stuff 1st!: homakov.blogspot.com
- 41. Teh Edn. Y U NO PAY ME FOR SECURITY AUDIT?