Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Effective approaches to web application security


Published on

Published in: Technology, News & Politics
  • Slide 14 ... a revalation!
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi Zane, nice presentation. I was looking for JMX monitoring solutions and I wanted to know where you apply exponential smoothing function? Is that done on collection or during display using graphite?
    Are you sure you want to  Yes  No
    Your message goes here
  • I really liked the JavaScript hooks idea for automated XSS exploitation notifications, just awesome.
    Are you sure you want to  Yes  No
    Your message goes here
  • like Arthur replied I am shocked that a student able to earn $9035 in four weeks on the internet. have you seen this web link NUTTYRICH DOT com
    Are you sure you want to  Yes  No
    Your message goes here

Effective approaches to web application security

  1. 1. Effec%ve  Approaches  to  Web   Applica%on  Security     @zanelackey  
  2. 2. Who  am  I?     •  Co-­‐Founder  /  CSO  at  Signal  Sciences   •  Built  and  led  the  Etsy  Security  Team   •  Prior  to  that,  offensive  research  and   penetra%on  tes%ng  @  iSEC  Partners        
  3. 3. About  this  talk         Real  world  approaches  to  web  applica%on   security  challenges      
  4. 4. About  this  talk         Specifically,  techniques  that  are  simple  and   effec*ve      
  5. 5.     Con%nuous  deployment?  
  6. 6. <-­‐  What  it   (hopefully)   isn’t    
  7. 7.     Three  words:  iterate,  iterate,  iterate  
  8. 8.     Etsy  pushes  to  produc%on  30  *mes  a  day  on   average    
  9. 9.                                                                        (dogs  push  too)    
  10. 10.     But  doesn’t  the  rapid   rate  of  change  mean   things  are  less   secure?!  
  11. 11. Actually,  the  opposite  is   true  
  12. 12.     Being  able  to  deploy  quick  is  our  #1  security   feature      
  13. 13. Compared  to       We’ll  rush  that  security  fix.    It  will  go  out  …  in   about  6  weeks.     -­‐  Former  vendor  at  Etsy  
  14. 14. What  it  boils  down  to   (spoiler  alert)     •  Make  things  safe  by  default   •  Detect  risky  func%onality  /  Focus  your  efforts     •  Automate  as  much  as  you  can   •  Know  when  the  house  is  burning  down        
  15. 15.     Safe  by  default  
  16. 16.     How  have  the  tradi%onal  defenses  for  XSS   worked  out?        
  17. 17. Safe  by  default   •  Problems?     –  OZen  done  on  a  per-­‐input  basis   •  Easy  to  miss  an  input  or  output     –  May  use  defenses  in  wrong  context   •  Input  valida%on  paern  may  block  full  HTML  injec%on,  but   not  injec%ng  inside  JS   –  May  put  defenses  on  the  client  side  in  JS   –  Etc  …   These  problems  miss  the  point  
  18. 18. Safe  by  default   •  The  real  problem  is  that  it’s  hard  to  find  where   protec%ons  have  been  missed         •  How  can  we  change  our  approach  to  make  it   simpler?    
  19. 19. Safe  by  default       Input  valida%on   Output  encoding  
  20. 20. Safe  by  default       Input  valida%on   Output  encoding  
  21. 21. Safe  by  default     Encode  dangerous  HTML  characters  to  HTML   en%%es  at  the  very  start  of  your  framework       To  repeat…  Before  input  reaches  main   applica%on  code    
  22. 22. Safe  by  default         On  the  surface  this  doesn’t  seem  like  much  of  a   change  
  23. 23. Safe  by  default         Except,  we’ve  just  made  lots  of  XSS  problems   grep-­‐able  
  24. 24.      
  25. 25. Safe  by  default   Now  we  look  for  a  small  number  of  paerns:   •  HTML  en%ty  decoding  func%ons  or  explicit  string   replacements   •  Data  in  formats  that  won’t  be  sani%zed     –  Ex:  Base64  encoded,  double  URL  encoded,  etc   •  Code  that  opts  out  of  plaeorm  protec%ons  
  26. 26. Safe  by  default   Fundamentally  shiZs  us:    From:  “Where  is  my  app  missing  protec%ons?”   (hard)                    To:  “Where  is  it  made  deliberately  unsafe?”   (easy)    
  27. 27. Safe  by  default   Obviously  not  a  panacea     – DOM  based  XSS     – Javascript:  URLs   – Can  be  a  pain  during  interna%onaliza%on  efforts  
  28. 28.     Focus  your  efforts  
  29. 29. Focus  your  efforts     •  Con%nuous  deployment  means  code  ships  fast   •  Things  will  go  out  the  door  before  security   team  knows  about  them   •  How  can  we  detect  high  risk  func%onality?  
  30. 30. Detect  risky  func%onality   •  Know  when  sensi%ve  por%ons  of  the  codebase   have  been  modified     •  Build  automa%c  change  aler%ng  on  the   codebase   – Iden%fy  sensi%ve  por%ons  of  the  codebase     – Create  automa%c  aler%ng  on  modifica%ons    
  31. 31. Detect  risky  func%onality   •  Doesn’t  have  to  be  complex  to  be  effec%ve   •  Approach:     – sha1sum  sensi%ve  plaeorm  level  files   – Unit  tests  alert  if  hash  of  the  file  changes   – No%fies  security  team  on  changes,  drives  code   review  
  32. 32. Detect  risky  func%onality   •  At  the  plaeorm  level,  watching  for  changes  to   site-­‐wide  sensi%ve  func%onality     – CSRF  defenses   – Session  management     – Encryp%on  wrappers   – Login/Authen%ca%on   – Etc  
  33. 33. Detect  risky  func%onality   •  At  the  feature  level,  watching  for  changes  to   specific  sensi%ve  methods   •  Iden%fying  these  methods  is  part  of  ini%al   code  review/pen  test  of  new  features  
  34. 34. Detect  risky  func%onality   •  Watch  for  dangerous  func%ons     •  Usual  candidates:   – File  system  opera%ons   – Process  execu%on/control   – Encryp%on  /  Hashing   – Etc  
  35. 35. Detect  risky  func%onality   •  Unit  tests  watch  codebase  for  dangerous   func%ons     – Split  into  separate  high  risk/low  risk  lists   •  Alerts  are  emailed  to  the  appsec  team,  drive   code  reviews      
  36. 36. Detect  risky  func%onality   •  Find  out  about  unused  but  reachable  pages   •  Any  files  s%ll  reachable  but  barely  requested   are  probably  old  or  “temporary”  code   – aka  a  goldmine  of  vulnerabili%es    
  37. 37. Detect  risky  func%onality   1.  Walk  DocumentRoot,  build  list  of  files     2.  Compare  each  file  against  access  log   3.  Alert  on  any  files  accessed  <  X  %mes  in  last  30   days   Iden%fied  files  are  worth  a  manual  review,  can   likely  be  removed  en%rely  
  38. 38. Detect  risky  func%onality   •  Monitor  applica%on  traffic   •  Purpose  is  twofold:   – Detec%ng  risky  func%onality  that  was  missed  by   earlier  processes     – Groundwork  for  aack  detec%on  and  verifica%on    
  39. 39. Detect  risky  func%onality   •  Regex  incoming  requests  at  the  framework   – Sounds  like  performance  nightmare,  shockingly   isn’t     •  Look  for  HTML/JS  in  request     – This  creates  a  huge  number  of  false  posi%ves   •  That’s  by  design,  we  refine  the  search  later  
  40. 40. Detect  risky  func%onality   •  We  deliberately  want  to  cast  a  wide  net  to  see   HTML  entering  the  applica%on     •  From  there,  build  a  baseline  of  HTML     – Entering  the  applica%on  in  aggregate     – Received  by  specific  endpoints  
  41. 41. Detect  risky  func%onality   What  to  watch  for:   – Did  a  new  endpoint  suddenly  show  up?     •  A  new  risky  feature  might’ve  just  shipped   – Did  the  amount  of  traffic  containing  HTML  just   significantly  go  up?     •  Worth  inves%ga%ng    
  42. 42. Detect  risky  func%onality     Aggregate  increased,  %me  to  inves%gate  
  43. 43.     Automate  as  much  as  you  can  
  44. 44. Automate  as  much  as  you  can   •  Automate  finding  simple  issues  to  free  up   resources  for  more  complex  tasks   •  Use  aacker  traffic  to  automa%cally  drive   tes%ng     •  We  call  it  A<ack  Driven  Tes@ng  
  45. 45. Automate  as  much  as  you  can   •  Some  cases  where  this  is  useful:   – Applica%on  faults     – Reflected  XSS   – SQLi    
  46. 46. Automate  as  much  as  you  can   •  Applica%on  faults  (HTTP  5xx  errors)   •  As  an  aacker,  these  are  one  of  the  first  signs   of  weakness  in  an  app   – As  a  defender,  pay  aen%on  to  them!  
  47. 47. Automate  as  much  as  you  can   •  Just  watching  for  5xx  errors  results  in  a  lot  of   ephemeral  issues  that  don’t  reproduce   •  Instead:   – Grab  last  X  hours  worth  of  5xx  errors  from  access   logs   – Replay  the  original  request   – Alert  on  any  requests  which  s%ll  return  a  5xx  
  48. 48. Automate  as  much  as  you  can   •  Cron  this  script  to  run  every  few  hours   •  If  a  request  s%ll  triggers  an  applica%on  fault   hours  later,  it’s  worth  inves%ga%ng    
  49. 49. Automate  as  much  as  you  can   •  Similar  methodology  for  verifying  reflected   XSS   •  For  reflected  XSS  we:   – Iden%fy  requests  containing  basic  XSS  payloads   – Replay  the  request     – Alert  if  the  XSS  payload  executed    
  50. 50. Automate  as  much  as  you  can   •  Basic  payloads  commonly  used  in  tes%ng  for   XSS:   – alert()   – document.write()   – unescape()   – String.fromCharCode()     – etc  
  51. 51. Automate  as  much  as  you  can         We  created  a  tool  to  use  NodeJS  as  a  headless   browser  for  verifica%on  
  52. 52. Automate  as  much  as  you  can   Test  webserver   1.  Fetch  URL  containing  poten%al  XSS  
  53. 53. Automate  as  much  as  you  can   Test  webserver   2.  Page  contents  returned   to  a  temp  buffer,  not   interpreted  yet      
  54. 54. Automate  as  much  as  you  can   Test  webserver   3.  Inject  our  instrumented  JS  into  page  contents   +   Our  JS   Page  contents  
  55. 55. Automate  as  much  as  you  can   Test  webserver   4.  Combina%on  of  instrumented  JS  +  page   contents  interpreted     +   Our  JS   Page  contents  
  56. 56. Automate  as  much  as  you  can   Test  webserver   5.  If  instrumented  JS  is  executed,  alert   appsec  team  for  review  
  57. 57. Automate  as  much  as  you  can   •  Sample  instrumented  JS:   (function() { var proxiedAlert = window.alert; window.alert = function() { location="XSSDETECTED"; }; })();
  58. 58. Automate  as  much  as  you  can   •  Open  sourced  NodeJS  tool     – hps://     •  Combine  this  approach  with  driving  a  browser   via  Wa%r/Selenium   – Make  sure  to  use  all  major  browsers    
  59. 59.     Know  when  the  house  is   burning  down  
  60. 60. Know  when  the  house  is  burning  down             Graph  early,  graph  oCen      
  61. 61. Know  when  the  house  is  burning  down             Which  of  these  is  a  quicker  way  to  spot  a   problem?      
  62. 62. Know  when  the  house  is  burning  down      
  63. 63. Know  when  the  house  is  burning  down      
  64. 64. Know  when  the  house  is  burning  down       •  Methodology:   – Instrument  applica%on  to  collect  data  points   – Fire  them  off  to  an  aggrega%on  backend     – Build  individual  graphs   – Combine  groups  of  graphs  into  dashboards   •  We’ve  open  sourced  our  instrumenta%on   library   – hps://    
  65. 65. Know  when  the  house  is  burning  down      
  66. 66. Know  when  the  house  is  burning  down      
  67. 67. Know  when  the  house  is  burning  down      
  68. 68. Know  when  the  house  is  burning  down      
  69. 69. Know  when  the  house  is  burning  down             Now  we  can  visually  spot  aacks    
  70. 70. Know  when  the  house  is  burning  down             But  who’s  watching  at  4AM?    
  71. 71. Know  when  the  house  is  burning  down       •  In  addi%on  to  data  visualiza%ons,  we  need   automa%c  aler%ng     •  Look  at  the  raw  data  to  see  if  it  exceeds   certain  thresholds   •  Works  well  for  graphs  like  this…  
  72. 72. Know  when  the  house  is  burning  down      
  73. 73. Know  when  the  house  is  burning  down             But  not  like  this…    
  74. 74. Know  when  the  house  is  burning  down      
  75. 75. Know  when  the  house  is  burning  down       •  We  need  to  smooth  out  graphs  that  follow   usage  paerns   •  Use  exponen%al  smoothing  formulas  like  Holt-­‐ Winters     •  Math  is  hard,  let’s  look  at  screenshots!    
  76. 76. Know  when  the  house  is  burning  down    
  77. 77. Know  when  the  house  is  burning  down       •  Now  that  we’ve  smoothed  out  the  graphs…   •  Use  the  same  approach  as  before:   – Grab  the  raw  data   – Look  for  values  above/below  a  set  threshold     – Alert    
  78. 78. Know  when  the  house  is  burning  down             Have  the  ability  to  quickly/easily  correlate   events  
  79. 79. Know  when  the  house  is  burning  down       •  Global  Request  IDs   <?php   global  $request_uuid;   apache_note(’request_uuid',  $request_uuid);  
  80. 80. Know  when  the  house  is  burning  down         [01/Aug/2012:16:37:41  +0000]  "GET  /members/twokb/payments   HTTP/1.1"  200  "hps://XXX/members/twokb"  "Mozilla/5.0  (Windows   NT  6.1;  WOW64)  AppleWebKit/536.11  (KHTML,  like  Gecko)  Chrome/ 20.0.1132.57  Safari/536.11"  MF9JqDVpY93VOMreyvI2UC24wRjT   [Wed  Aug  01  16:37:41  2012]  [MF9JqDVpY93VOMreyvI2UC24wRjT]   [info]  [XXX]  [kbarry]  about  to  call  shop_get_data  for  shop:  [5971709]   [Wed  Aug  01  16:37:41  2012]  [MF9JqDVpY93VOMreyvI2UC24wRjT]   [info]  [XXX_audit]  [kbarry]    ac%on="view_payments"  staff="kbarry"   user_id="5597626"  sec%on="payment_info"  
  81. 81. Know  when  the  house  is  burning  down             Alert  on  events  that  (should)  never  happen    
  82. 82. Know  when  the  house  is  burning  down             Successful  aacks  don’t  happen  in  a  vacuum!   They  generate  signals    
  83. 83. Know  when  the  house  is  burning  down       1.  Iden%fy  the  signals  associated  with  a   vulnerability  class   2.  Alert  when  a  signal  occurs   3.  Fix  the  iden%fied  weaknesses    
  84. 84. Know  when  the  house  is  burning  down             Two  examples:  SQLi  and  code  execu%on      
  85. 85. Know  when  the  house  is  burning  down       •  The  road  to  exploited  SQLi  is  liered  with   broken  queries       1.  Watch  the  logs  for  SQL  syntax  errors   2.  Alert  when  they  appear   3.  Fix  the  lack  of  valida%on  allowing  the  error    
  86. 86. Know  when  the  house  is  burning  down       •  Further  along  the  aack  process,  a  SQLi  aack   looks  like…  your  database   •  Sensi%ve  DB  table  names  shouldn’t  be   showing  up  in  requests   – Alert  if  they  do!     •  aka  the  “Two  hours  un%l  the  db  is  up  on  pastebin”  alert    
  87. 87. Know  when  the  house  is  burning  down             A  funny  story  about  a  code  execu%on  vuln…    
  88. 88. Know  when  the  house  is  burning  down       •  preg_replace()  in  PHP  has  an  interes%ng   modifier     “e  (PREG_REPLACE_EVAL)  If  this  modifier  is  set,   preg_replace()  does  normal  subs%tu%on  of   backreferences  in  the  replacement  string,     evaluates  it  as  PHP  code,  and  uses  the  result  for   replacing  the  search  string.  “  
  89. 89. Know  when  the  house  is  burning  down       •  preg_replace()  in  PHP  has  an  interes%ng   modifier     “e  (PREG_REPLACE_EVAL)  If  this  modifier  is  set,   preg_replace()  does  normal  subs%tu%on  of   backreferences  in  the  replacement  string,   evaluates  it  as  PHP  code,  and  uses  the  result  for   replacing  the  search  string.”  
  90. 90. Know  when  the  house  is  burning  down             What  do  the  signals  for  this  look  like?        
  91. 91. Know  when  the  house  is  burning  down      
  92. 92. Know  when  the  house  is  burning  down             You  can’t  fix  what  you’re  not  aler%ng  on      
  93. 93.     Conclusions  
  94. 94.       Have  the  ability  to  deploy/respond  quickly      
  95. 95. •  Make  things  safe  by  default   •  Focus  your  efforts  /  Detect  risky  func%onality   •  Automate  as  much  as  you  can   •  Know  when  the  house  is  burning  down    
  96. 96. Thanks!                    @zanelackey    
  97. 97. References  /  Thanks   •  DevOpsSec:   hp:// devopssec-­‐apply-­‐devops-­‐principles-­‐to-­‐security     •  Special  Thanks:     – Nick  Galbreath,  Dan  Kaminsky,  Marcus  Barczak