Attacking Web Proxies in the modern Era.

6932fd8236cec12354ba8230c0e80d81?s=47 Nafeez
November 13, 2014

Attacking Web Proxies in the modern Era.

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

6932fd8236cec12354ba8230c0e80d81?s=128

Nafeez

November 13, 2014
Tweet

Transcript

  1. Attacking Web Proxies in the modern era

  2. Nafeez Software Security Engineer Defending & building secure stuff is

    more fun. Been talking about stuff that break the web @ BlackHat, HITB, Nullcon, C0c0n
  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.
  4. Web Proxy

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

  6. None
  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.
  8. Past attacks on web proxies De-anonymization, exfiltrating data, logs …

    Usually revolves around, the Proxy itself being malicious.
  9. Those are old threats Lets talk about owning an user

    when he is willing to click on links!
  10. A little bit of theory first

  11. Same origin policy (SOP) Single most important security feature in

    the browser. Without this, we would have a world-wide XSS havoc.
  12. Universal XSS (uXSS) Any flaw or un-intended feature in the

    browser, that bypasses its Same Origin Policy.
  13. User thinks he is on google.com Browser thinks he is

    on hidemyass.com
  14. Back to our web proxy story All the websites being

    proxied comes under a single trusted 'origin' from the browser's perspective.
  15. This also means any website can interact with the DOM

    / Cookies of other proxied websites.
  16. Fooling the Proxy’s SOP

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

    
 <iframe src=‘http://proxy.com/site?url=site.com’>
  18. attacker.com gets hold of the iframe Window Object and accesses

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

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

  21. How do we solve this problem?

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

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

    URL
  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.
  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.
  26. Glype Proxy Hot-Linking

  27. Bypassing Hot-Linking in Glype

  28. None
  29. This checks for all the whitelisted websites in the Referer

    If found, the hot-linking protection doesn’t apply to this!
  30. Allowed Referrers http://localhost http://proxy-website-itself And other whitelisted websites.

  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/
  32. Switching gears Lets talk about headers.

  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?
  34. True Story Web based proxies don’t respect target website’s HTTP

    Response Headers! Web based proxies have their own Cookie Jar implementation.
  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.
  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
  37. This is how web-proxies manage cookies for the websites you

    browser CookieName CookieValue
  38. None
  39. Bypassing JavaScript restriction Most proxies disable Javascript by default for

    a lot of reasons.
  40. They work by searching for Javascript patterns and removing them.

    They cannot completely disable Javascript because they are not the same as browser!
  41. For a web attacker, this situation is like an XSS

    filter bypass.
  42. Most proxies don’t restrict JS execution from SVG, Complex JS

    Event handlers. An attacker can also send chunked encoded responses.
  43. How not to write JS filters var inputHTML = "<img

    src='PLACEHOLDER'>"; 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: </br>' + input); document.write(finalHTML); }
  44. input = “$` onerror=alert(1);//”;

  45. String.replace is MAD! var inputHTML = "<img src='PLACEHOLDER'>"; 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: </br>' + input); document.write(finalHTML); }
  46. EcmaScript’s String.replace is funny! http://www.ecma-international.org/ecma-262/5.1/#sec-15.5.4.11

  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.
  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.
  49. Thanks! @skeptic_fx