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

Security for JS Developers

Gavin Miller
February 16, 2016

Security for JS Developers

A brief look into SQL Injection attacks, Side Channel attacks, and an entropy based attack (password cracking) using a real life leaked database scenario. Each section includes details of how the attack works, and how to prevent/mitigate said attacks.

Gavin Miller

February 16, 2016
Tweet

More Decks by Gavin Miller

Other Decks in Programming

Transcript

  1. Sources:  h+ps://haveibeenpwned.com/PwnedWebsites                

                     h+p://betanews.com/2014/12/17/the-­‐top-­‐10-­‐worst-­‐security-­‐breaches-­‐of-­‐2014/  
  2. Adobe   Poor  Encryp7on   Sony   SQL  Injec7on  +

     OnSite  Breach  /  Stolen   Creden7als   Dominos   Weak  MD5  password  Hashing   Snapchat   Brute  force  enumera7on  of  phone  numbers   Yahoo   SQL  Injec7on   Target     Stolen  HVAC  creden7als  &  pivoted  into   POS  system   eBay   Stolen  employee  creden7als   Ashley   Madison   Internal  data  dump  &  encrypted  passwords   cracked   Source:  h+p://krebsonsecurity.com/2014/02/target-­‐hackers-­‐broke-­‐in-­‐via-­‐hvac-­‐company/                                h+p://www.businessinsider.com/how-­‐the-­‐hackers-­‐broke-­‐into-­‐sony-­‐2014-­‐12  
  3. Most  of  the  industry’s  worst  security  problems   happened  because

     smart  developers   approached  security  code  the  same  way  they   did  the  rest  of  their  code.     The  difference  between  security  code  and   applica;on  code  is,  when  applica;on  code  fails,   you  find  out  right  away.       When  security  code  fails,  you  find  out  4  years   from  now,  when  a  DVD  with  all  your  customer’s   credit  card  and  CVV2  informa;on  starts   circula;ng    -­‐  Thomas  Ptacek   Source:  h+p://web.archive.org/web/20130407190430/h+p://chargen.matasano.com/chargen/                                      2007/9/7/enough-­‐with-­‐the-­‐rainbow-­‐tables-­‐what-­‐you-­‐need-­‐to-­‐know-­‐about-­‐s.html  
  4. Goals   Could  my  business/project  be     hacked  like

     that?     Glimpse  into  how  hackers  operate     Pee  your  pants  a  liKle   Scare  you  a  ;ny  bit  
  5. AYacks!!   •  3  Different  AYacks:     •  SQL

     Injec7on   •  Side-­‐Channel   •  Entropy   Theory   Demo   Preven7on  
  6. Preven7on   •  Query  Parameteriza7on   – Learn  how  your  ORM

     works   – Know  how  to  parameterize  if  using  raw  SQL   •  Code  Review   – Team  ought  to  be  capable  of  catching  this  
  7. Side  Channel   An  aYack  to  exploit  the  informa7on  gained/

    leaked  from  the  implementa7on  of  a  system  
  8. Total  Time:  8T   ✓   ✓   ✓  ✓

      ✓   ✓  ✓   ✓  
  9. Exploitable?   Ruby  comparison  takes  0.840ns/byte   (effec;vely  per  character)

        Can  measure  a  30μs  difference  over  the   internet   Which  means  you  can't  exploit  a  ;ming   aKack  over  the  internet  …  (in  Ruby)     Source:  h+ps://www.youtube.com/watch?v=idjDiBtu93Y  
  10. Exploitable!   So  get  closer…   EC2  to  EC2  can

     measure  a  15-­‐400ns   difference.   Bingo!     ~1000  request  per  character   Source:  h+ps://www.youtube.com/watch?v=idjDiBtu93Y  
  11. Preven7on   •  Constant  Time  Comparison   – For  aKackable  areas

      – Passwords,  authen;ca;on,  tokens,  etc.   •  Don't  roll  your  own  Crypto/Auth   – You're  not  smart  enough  (and  neither  am  I)   •  Logs     – Monitoring   – IP  ThroKling   – IPS  (Intrusion  Protec;on  Systems)  
  12. Password  Hashing  101     hash(x)    #=>  5f4dcc3b5aa765d61d8327…  

      •  If  DB  is  ever  stolen/leaked/compromised   user's  passwords  are  safe…   Source:  h+ps://github.com/codahale/bcrypt-­‐ruby    
  13. Password  Hashing  101     MD5(x)    #=>  5f4dcc3b5aa765d61d8327…  

      •  Very  aKackable   •  Use  the  same  algorithm  with  a  very  fast   computer   •  Store  the  result  ==  rainbow  tables   Source:  h+ps://github.com/codahale/bcrypt-­‐ruby    
  14. Password  Hashing  101   •  Add  a  salt   MD5(salt

     +  x)  #=>  cca80912a0c2…   •  Store  hashed  password  &  salt  in  DB   Source:  h+ps://github.com/codahale/bcrypt-­‐ruby    
  15. Password  Hashing  101   MD5(salt  +  x)  #=>  cca80912a0c2…  

    •  Slightly  less  than  very  aKackable   •  Brute  force   – Common  Password  Dic;onary  +  Time     – Compute  Power  (AWS,  GPUs,  ASICs?)   •  GPU  ==  3  Billion  MD5/sec!   Source:  h+ps://github.com/codahale/bcrypt-­‐ruby                                  h+p://www.troyhunt.com/2016/02/data-­‐breaches-­‐vbulleUn-­‐and-­‐weak.html  
  16. Password  Hashing  101   •  "Tradi;onal"  hash  algorithms  are  fast:

      – MD5   – SHA1   •  Want  a  slow  hash  algorithm   – BCrypt   – Argon2  (latest  hotness)  
  17. Preven7on   Should  NEVER  be  Stored  in  your  DB!!!  

    nor  any  other  password  related  informaAon  
  18. Sources:  h+p://cynosureprime.blogspot.com.au/2015/09/how-­‐we-­‐cracked-­‐millions-­‐of-­‐ashley.html   •  Login  Token  (type-­‐2)   •  md5(

         lc($username)  +  "::"  +      lc($pass)  +  "::"  +      lc($email)  +  "::"  +      ":73@^bhhs&#@&^@8@*$")  
  19. Thanks  :)   Make  good  decisions        

      @gavingmiller   gavinmiller.io