Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Rails Security in the Wild - Chicago Ruby

Matt Konda
December 04, 2012

Rails Security in the Wild - Chicago Ruby

Discussion of important security issues developers in Rails are advised to be aware of.

Matt Konda

December 04, 2012
Tweet

More Decks by Matt Konda

Other Decks in Programming

Transcript

  1. “….developers will never learn, never improve because they are repeating

    the same mistakes over and over again” Breaker Tuesday, December 4, 12
  2. “…only good at ranting. Zero contribs, and almost zero constructive

    feedbacks but bashing” Builde Response Tuesday, December 4, 12
  3. “If you are a developer and don’t know who OWASP

    is at this point, it’s because you’ve chosen not to.” reaker Tuesday, December 4, 12
  4. “Problem. Infosec pros, pentesters, etc. are more interested in #appsec

    than programmers. How to change that? < will not change” uilde Tuesday, December 4, 12
  5. SLOW POLL Who typically has: 1. Pen test 2. Static

    analysis 3. App Scan 4. Secure Code Review 5. Secure Development Training Tuesday, December 4, 12
  6. #25 SQL Injection Apr 30, 2007 Episode #204 – Mar

    08, 2010 – 31 comments XSS Protection in Rails 3 #178 7 Security Tips Sep 07, 2009 Episode #26 – Mar 08, 2012 – 23 comments Hackers Love Mass Assignment (revised) Episode #27 – May 04, 2007 – 15 comments Cross Site Scripting Episode #26 – May 02, 2007 – 32 comments Hackers Love Mass Assignment Episode #20 – Apr 18, 2007 – 22 comments Restricting Access Episode #352 – May 23, 2012 – 15 comments Securing an API Episode #356 – Jun 08, 2012 – 23 comments Dangers of Session Hijacking History Lesson Tuesday, December 4, 12
  7. In ApplicationController: def restrict_access_by_token_to_worker() token = request.env["HTTP_AUTHORIZATION"] if token ==

    nil authenticate_user! else key = ApiKey.find_by_token(token) if key != nil and key.worker == true return true else puts "Invalid token" return false end end end In command controller: before_filter :authenticate_user!, :except => [:show] In show method: worker = restrict_access_by_token_to_worker Tuesday, December 4, 12
  8. Command Injection • Vulnerability Focused on Server • Attacker piggybacks

    on variable input that is passed down to a command line call. • Most easily demonstrated like so… http://example.com/page.php?id=123;ifconfig Tuesday, December 4, 12
  9. • Lis$ng  a  file  or  showing  the  IP  configura$on  can

     be  used   to  demonstrate  app  vulnerability. Command Injection Tuesday, December 4, 12
  10. • Demo • “Pop  a  shell”  via  command  injec$on  vulnerability

     in  Rails  App Command Injection Tuesday, December 4, 12
  11. SQL Injection 1 @project = Project.find(params[:id]) 2 @projects = Project.find(:all,

    :conditions=>"id LIKE #{params[:id]}") 3 @project = Project.find(:all, :conditions=> ["id LIKE ?", "%#{params[:query]}%&"] ) http://localhost:3002/projects/-1%20or%20name%20= %20name Tuesday, December 4, 12
  12. Rails SQL Injection Workarounds ----------- This issue can be mitigated

    by casting the parameter to an expected value. For example, change this: Post.where(:id => params[:id]).all to this: Post.where(:id => params[:id].to_s).all CVE-2012-2661 Tuesday, December 4, 12
  13. Rails Unsafe Query Generation unless params[:token].nil? user = User.find_by_token(params[:token]) <---

    HERE user.reset_password! end Workarounds ----------- This problem can be mitigated by testing for `[nil]`. For example: unless params[:token].nil? || params[:token] == [nil] user = User.find_by_token(params[:token]) user.reset_password! end Another possible workaround is to cast to a known type and test against that type. unless params[:token].to_s.empty? user = User.find_by_token(params[:token]) user.reset_password! end CVE-2012-2660 Tuesday, December 4, 12
  14. Before and After def destroy @service_request = ServiceRequest.find(params[:id]) @service_request.destroy respond_to

    do |format| format.html { redirect_to service_requests_url } format.json { head :no_content } end end def show @service_request = ServiceRequest.find(params[:id]) respond_to do |format| format.html # show.html.erb format.json { render json: @service_request } end end Tuesday, December 4, 12
  15. Magic def user_can_access_service_request(service_request) sr_key = service_request.api_key keys = get_api_keys keys.each

    do |key| if (key == sr_key) return true end end return false end Tuesday, December 4, 12
  16. After def destroy @service_request = ServiceRequest.find(params[:id]) if (user_can_access_service_request(@service_request)) @service_request.destroy end

    respond_to do |format| format.html { redirect_to service_requests_url } format.json { head :no_content } end end def show @service_request = ServiceRequest.find(params[:id]) respond_to do |format| if (user_can_access_service_request(@service_request)) format.html # show.html.erb format.json { render json: @service_request } else @service_request = ServiceRequest.new @service_request.errors.add(:base, "You do not have access to this object.") flash[:error] = "Unable to access specified instance." format.html { render action: "new" } format.json { render json: @service_request.errors, status: :unprocessable_entit end end end Tuesday, December 4, 12
  17. Cross-site Scripting (XSS) • Alert  boxes  are  an  easy  proof

     of  concept  to   demonstrate  applica$on  vulnerability. • Real attackers use JavaScript for evil Tuesday, December 4, 12
  18. Cross-site Scripting (XSS) • Demo • Steal Facebook Credentials via

    Persistent XSS Vulnerability in Rails App Tuesday, December 4, 12
  19. Cross-site Scripting (XSS) • Vulnerability  Focused  on  Client  Browsers •

    AHacker  convinces  user  to  click  a  link,  Javascript   is  executed  in  target  browser. • Most  easily  demonstrated  like  so… • hHp://example.com/page?id=<script>alert(‘xss’)</ script> Tuesday, December 4, 12
  20. Top 10 • A1: Injection • A2: Cross-Site Scripting (XSS)

    • A3: Broken Authentication and Session Management • A4: Insecure Direct Object References • A5: Cross-Site Request Forgery (CSRF) • A6: Security Misconfiguration • A7: Insecure Cryptographic Storage • A8: Failure to Restrict URL Access • A9: Insufficient Transport Layer Protection • A10: Unvalidated Redirects and Forwards Tuesday, December 4, 12
  21. Top 10 A1: Injection • A2: Cross-Site Scripting (XSS) •

    A3: Broken Authentication and Session Management • A4: Insecure Direct Object References • A5: Cross-Site Request Forgery (CSRF) • A6: Security Misconfiguration • A7: Insecure Cryptographic Storage • A8: Failure to Restrict URL Access • A9: Insufficient Transport Layer Protection • A10: Unvalidated Redirects and Forwards Tuesday, December 4, 12
  22. Security in the SDLC Requirements Design Coding Testing Agile Model

    Quantum: Story Static Analysis Code Review Pen Test Architecture Security Requirements Security in the Story Threat Model Security Training Scanners Change Mgmt More ... Tuesday, December 4, 12
  23. Resources OWASP • Code Review Guide • Legal Language •

    Cheat Sheets • Top 10 • Tools (ZAP) Tools Attack Proxy (Burp, ZAP) Static Analysis (Brakeman) Web App Scan (Arachni) Code Review (Barkeep) Bad Code (Intentional) https://github.com/claudijd/xss https://github.com/claudijd/command_injection https://github.com/Jemurai/triage Tuesday, December 4, 12
  24. Now let’s talk: . We’ll buy for the first 5

    people that find problems and verify with us. VERY LIMITED TIME OFFER. Tuesday, December 4, 12