Attacking Web Proxies in the modern Era.

Slides from my talk on Attack web proxies @ Ground Zero 2014, New Delhi

Transcript

1. Attacking Web Proxies
   in the modern era
   

   View Slide

2. Nafeez
   Software Security Engineer
   Defending & building secure stuff is more fun.
   Been talking about stuff that break the web @
   BlackHat, HITB, Nullcon, C0c0n
   

   View Slide

3. Why use web proxies?
   Widely used for anonymous surfing and identity
   cloaking on the Internet.
   

   Also used in traffic filtering, traffic management,
   log auditing, access policies and surfing
   restricted sites.
   

   View Slide

4. Web Proxy
   

   View Slide

5. Our scope
   Not the pure HTTP Proxies but Web-Based proxies.
   

   View Slide

6. View Slide

7. How does a web based
   proxy work?
   1. User requests site.com inside the Web Proxy
   page.
   2. The Proxy downloads the web content and
   pushes its own HTML alongside the
   downloaded content.
   3. User finally gets to see site.com under the Web
   Proxy page.
   

   View Slide

8. Past attacks on web proxies
   De-anonymization, exfiltrating data, logs …
   Usually revolves around, the Proxy itself being malicious.
   

   View Slide

9. Those are old threats
   Lets talk about owning an user when he is willing
   to click on links!
   

   View Slide

10. A little bit of theory first
    

    View Slide

11. Same origin policy (SOP)
    Single most important security feature in the
    browser.
    Without this, we would have a world-wide XSS
    havoc.
    

    View Slide

12. Universal XSS (uXSS)
    Any flaw or un-intended feature in the browser, that
    bypasses its Same Origin Policy.
    

    View Slide

13. User thinks he is on google.com
    Browser thinks he is on hidemyass.com
    

    View Slide

14. Back to our web proxy story
    All the websites being proxied comes under a
    single trusted 'origin' from the browser's
    perspective.
    

    View Slide

15. This also means any website can interact with the
    DOM / Cookies of other proxied websites.
    

    View Slide

16. Fooling the Proxy’s SOP
    

    View Slide

17. attacker.com IFrame’s the proxified site.com URL.
    The user navigates to,
    

    
    

    View Slide

18. attacker.com gets hold of the iframe Window Object and
    accesses its DOM.
    

    View Slide

19. At this point, the SOP is bypassed
    a.k.a.
    Game Over!
    

    View Slide

20. The browser has a single origin here, ‘hidemyass.com’
    

    View Slide

21. How do we solve this
    problem?
    

    View Slide

22. For a start, Web-Proxies already
    tries to solve this problem.
    

    View Slide

23. Do not allow other websites to directly control your
    proxified URL
    

    View Slide

24. Proxy Hot-linking
    This feature prevents users from hot-linking
    directly to a proxied page and forces all users to
    visit the index page first.
    

    View Slide

25. Proxy Hot-linking
    This feature is like the achilles-heel of any web
    proxy security.
    If any website can directly get themselves being
    IFRAMED + Proxied by a web proxy then attacks
    like the SOP bypass and other attacks are easily
    possible.
    

    View Slide

26. Glype Proxy Hot-Linking
    

    View Slide

27. Bypassing Hot-Linking in Glype
    

    View Slide

28. View Slide

29. This checks for all the whitelisted websites in the Referer
    If found, the hot-linking protection doesn’t apply to this!
    

    View Slide

30. Allowed Referrers
    http://localhost
    http://proxy-website-itself
    And other whitelisted websites.
    

    View Slide

31. The bypass
    Just add the whitelisted name to the path of your
    referrer.
    Just do a location.reload() from, 

    http://attacker.com/localhost/
    http://attacker.com/whitelisted-domain/
    

    View Slide

32. Switching gears
    Lets talk about headers.
    

    View Slide

33. Practical aspects
    What if the target website prevents IFraming using
    X-Frame-options and other such security
    headers?
    What if the target website has set httpOnly
    cookies?
    

    View Slide

34. True Story
    Web based proxies don’t respect target website’s
    HTTP Response Headers!
    Web based proxies have their own Cookie Jar
    implementation.
    

    View Slide

35. Unsafe response rewrites
    Messing around with secure response headers like
    X- Frame-Options, X-XSS-Protection, Content-
    Security-Policy, HSTS
    Those headers won’t be re-written back to the
    user’s browser in the response.
    

    View Slide

36. Cookie Jars on Proxy
    Proxies under-estimate the complexity of Cookie
    management.
    Things like various cookie flags, handling of
    secure channels, limit of cookies with the same
    name, cookie folding, cookie SOP etc
    

    View Slide

37. This is how web-proxies manage cookies
    for the websites you browser
    CookieName CookieValue
    

    View Slide

38. View Slide

39. Bypassing JavaScript restriction
    Most proxies disable Javascript by default for a lot
    of reasons.
    

    View Slide

40. They work by searching for Javascript patterns
    and removing them.
    They cannot completely disable Javascript
    because they are not the same as browser!
    

    View Slide

41. For a web attacker, this situation is like an XSS filter
    bypass.
    

    View Slide

42. Most proxies don’t restrict
    JS execution from
    SVG, Complex JS Event handlers.
    An attacker can also send chunked encoded
    responses.
    

    View Slide

43. How not to write JS filters
    var inputHTML = "";
    function doTemplating(){
    var input = document.getElementById('id_input').value;
    input = filterInput(input);
    var finalHTML = inputHTML.replace("PLACEHOLDER", input);
    console.log(finalHTML);
    document.write('Your input: ' + input);
    document.write(finalHTML);
    }
    

    View Slide

44. input = “$` onerror=alert(1);//”;
    

    View Slide

45. String.replace is MAD!
    var inputHTML = "";
    function doTemplating(){
    var input = document.getElementById('id_input').value;
    input = filterInput(input);
    var finalHTML = inputHTML.replace("PLACEHOLDER", input);
    console.log(finalHTML);
    document.write('Your input: ' + input);
    document.write(finalHTML);
    }
    

    View Slide

46. EcmaScript’s String.replace
    is funny!
    http://www.ecma-international.org/ecma-262/5.1/#sec-15.5.4.11
    

    View Slide

47. Little bit of the new ECMAScript
    features helps as well!
    Overriding and Freezing DOM properties using
    ES5 Object locking mechanisms to completely
    subvert any defences placed by the proxied
    website against Proxy based attacks.
    

    View Slide

48. Proxies should adopt CSP to
    enforce real anonymity.
    Content security policy helps extensively in locking
    down proxy based attacks, since its enforced by
    the browser.
    

    View Slide

49. Thanks!
    @skeptic_fx
    

    View Slide