Cookie Tossing - Evaluation and Mitigation

An evaluation and mitigation of the Cookie Tossing technique in performing Cross-Site Request Forgery

Transcript

1. Evalua&on   •  Need  the  control  of  pr.bank.com,  don’t  we?  
2. Pervasiveness  of  XSS   Nils  Juenemann,  hAp://www.nilsjuenemann.de/2011/11/applecom-­‐xss-­‐gallery.html  
3. Evalua&on   •  Client  has  to  be  tricked  into  accessing  the  link   to  a  compromised  page   •  Seriously,  who  clicks  on  links?    
4. Evalua&on   •  Expecta&on  of  malware  is  low  for  a  trusted   domain   •  CSRF  provides  no  visual  feedback  on  the   malicious  ac&vity  –  damage  would  likely  have   been  done  upon  discovery  
5. Evalua&on   •  Client  has  to  be  logged  into  the  target  service   while  viewing  compromised  page   •  Chances  would  be  raised  if  the  mode  of  link   delivery  coincides  with  the  account  to  be   compromised   – Link  can  be  sent  to  vic&m  via  email  if  the  aAacker   is  interested  to  take  over  the  mail  account  
6. Mi&ga&ons   •  Address  cookie  tossing  on  the  basis  of  it  only   being  able  to  overwrite  cookies,  but  not  read   them  
7. Mi&ga&on   •  Strategy  1:  Store  Session  CSRF  Token  in   database   •  Perform  check  between  hidden  form  variable   and  stored  token  
8. Persistent  CSRF  Token   Web  Server   Client   CSRF  Nonce   AAacker  
9. Cookies   Web  Server   Client   Session  ID   Form   CSRF  Nonce   Email  Add.   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce  
10. Cookies   Web  Server   Client   Session  ID   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce  
11. Cookies   Web  Server   Client   Session  ID   Malicious  Form   Bad  Nonce   evil@aAacker.com   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce  
12. Cookies   Web  Server   Client   Session  ID   Malicious  Form   Bad  Nonce   evil@aAacker.com   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce  
13. Web  Server   Client   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce   Cookies   Session  ID   Malicious  Form   Bad  Nonce   evil@aAacker.com  
14. Web  Server   Client   AAacker   Persistent  CSRF  Token   Database   CSRF  Nonce   Cookies   Session  ID   Malicious  Form   Bad  Nonce   evil@aAacker.com   Equal?  No:  Reject!  
15. Mi&ga&on   •  Good:  Straight-­‐forward  approach,  no  technical   complexi&es   •  Bad:  Need  to  maintain  addi&onal  state  in   database,  nightmare  for  web  applica&ons   requiring  mul&ple  log-­‐ons  for  a  single  account  
16. Mi&ga&on   •  Strategy  2:  Make  hidden  form  variable  a   func&on  of  CSRF  Cookie  Token  and  Session  ID   – f(CSRF  Cookie  Token,  Session  ID)  =  Form  Variable   •  Transform  CSRF  Cookie  Token  to  hidden  form   variable  through  Session  ID  before  comparing  
17. CSRF  Protec&on:  C  =  FV?   Form  Variable   Cookie   C  =  FV  ?   Ideal   abcd   abcd   ✔   Failed  A3ack   efgh   abcd   ✘   Successful  A3ack   efgh   efgh   ✔   Set  by  legi&mate  web  server   Set  by  aAacker   Controlled  by  aAacker  due   to  cookie  tossing  
18. CSRF  Protec&on:  f(C,  SID)  =  FV?   Form  Variable   Cookie  (CSRF)   Session  ID   f(C,  SID)  =  FV  ?   Mi@ga@on   bd`   abcd   1234   ✔   Failed  A3ack   abcd   abcd   1234     ✘   No  incen&ve  to  overwrite   Not  able  to  read  or  guess   Set  by  legi&mate  web  server   Set  by  aAacker  
19. Mi&ga&on   •  Good:  No  persistent  storage  in  database   needed,  clean  migra&on  for  sites  already  using   Double  Submit  Cookies   •  Bad:  More  challenging  for  administrators  to   fully  comprehend   •  And  that’s  when  vulnerabili&es  come  in,  no?