JS Suicide: Using Javascript's security features to kill itself

JS Suicide: Using Javascript's security features to kill itself

BlackHat Asia 2014, Singapore.

JavaScript today has a presence in almost every single website across the Internet. Aggressive research is in progress in the security community to come up with better security features in JavaScript everyday. Unfortunately, many security features of JS are a double-edged sword. In this presentation, we will show how some of the security features in JavaScript can be used maliciously by an attacker to kill other security features in any website. More specifically, we will see how the sandboxing features of ECMAScript 5 can break and make security in modern day applications. We also take a few real world examples like OWASP CSRFGUARD and use some of the major security features of JS to bypass CSRF protection offered by this OWASP library in many different ways.

6932fd8236cec12354ba8230c0e80d81?s=128

Ahamed Nafeez

March 28, 2014
Tweet

Transcript

  1. 1.

    JS  Suicide:  Using  JavaScript  Security  Features  to   Kill  JS

     Security     Ahamed  Nafeez   @skeptic_fx
  2. 2.

    Agenda JavaScript  of  all  things   ! Objects  and  ECMAScript

     5   ! The  Principle  of  Unobtrusive  JavaScript   ! The  sad  story  of  OWASP  CSRFGuard   ! Hunting  down  insecure  DOM  Properties   !
  3. 3.

    What  to  expect  today? This  talk  is  about:   •

    Using  JavaScript’s  features  to  attack  its  implementations.   • Bypassing  OWASP  CSRFGuard’s  protection.   • DOM  Clobbering.   ! This  talk  is  NOT  about,  how  to  do   • Cross  site  scripting   • Cross  site  request  forgery   • Or  the  usual  stuff  you  hear  in  JS  Security  like  eval,  Global   Objects  etc.
  4. 4.

    #whoami ! Ahamed  Nafeez   ! Security  Engineer  by  day,

     with  above  average  interest  in   Web  and  Networks.   ! I  believe,  Defending  and  Building  secure  software  is  harder   than  attacking.   ! blog.skepticfx.com   ! This  talk  does  not  represent  the  view  of  my  employer.   ! 

  5. 6.

    Enough  JS  Primer  for  today Dynamic  language   ! Object-­‐based

      ! Functions  are  first  class  citizens  
  6. 21.

    21

  7. 24.

    OWASP  CSRFGuard Synchroniser  token  pattern.   ! Injects  ANTI-­‐CSRF  tokens

     in  to  pages  dynamically   ! Completely  compatible  with  the  principle  of  UnObtrusive   JavaScript
  8. 26.
  9. 28.

    An  attacker  could  load  this  JS  file  from  a  

    Cross-­‐Domain  website  and  steal  this   token.
  10. 32.

    Bypass  1  -­‐  Prototype  Overriding Always  return  True Freeze  the

     String.prototype  Object,  
 So  CSRFGuard  cannot  redefine  it. override.js
  11. 33.

    33 Bypass  1  -­‐  Continued  .  .  . Load  the

     CSRFGuard  JS  File  from  good.com Walk  the  DOM  and  read  the  CSRF  Token  injected  by  the  library.
  12. 38.

    38 ! ! Lets  try  another  way  to  bypass  this

      whole  situation.     ! Just  for  Fun.
  13. 43.

    Do  not  Hard  Code  the  Dynamic  +  Secret   artifacts.

    1.  Embed  them  inside  your  DOM  such  as  META  tags  and  read  from  JS 2.  Send  an  XHR  request  and  read  it.  So  the  token  is  protected  by  Same  Origin  Policy
  14. 46.

    Names  and  IDs  of  form  controls  are  treated   as

     properties  to  the  FORM  Element.
  15. 47.

    Think  about  JS  Frame  Busters Used  to  prevent  against  UI

     Redressing  attacks.   Some  people  still  use  this    alongside,   the    X-­‐Frame-­‐Options  header.
  16. 48.
  17. 50.

    The  DOM  is  a  Mess  !   ! @garethheyes  

     -­‐     http://www.thespanner.co.uk/2013/05/16/dom-­‐clobbering/
  18. 54.

    Things  to  keep  in  mind Today,  a  developer  can  only

     rely  on
 location.href,  as  the  only  trusted  source  of  location.   ! Every  other  location  properties  can  be  spoofed  and  played   around  with.   ! You  can  try  fuzzing  various  different  properties  and  use   them  in  your  pen  tests  /  research  accordingly.  
  19. 55.

    You  should  follow Mario,  @0x6D6172696F   ! Gareth  Heyes,  @garethheyes

        ! Yosuke  Hasegawa,  @hasegawayosuke     ! Lavakumar,  @lavakumark   ! And  a  few  more,  that  I  don’t  have  space  to  mention  here.   !