SlideShare a Scribd company logo
Proxpective: Attacking
Web Proxies like never
before
Ahamed Nafeez
About me
Software Security Engineer
Defending & building secure stuff is more fun.
Been talking about stuff that break the web @
BlackHat, HITB, Nullcon, C0c0n
Web Proxy
Our scope
Not the pure HTTP Proxies but Web-Based proxies.
Attacking Web Proxies
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.
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.
Past attacks on web proxies
De-anonymization, exfiltrating data, logs …
Usually revolves around, the Proxy itself being malicious.
Those are old threats
Lets talk about owning an user when he is ready to
click on links!
A little bit of theory first
Same origin policy (SOP)
Single most important security feature in the
browser.
Without this, we would have a world-wide XSS
havoc.
Universal XSS (uXSS)
Any flaw or un-intended feature in the browser, that
bypasses its Same Origin Policy.
Back to our web proxy story
All the websites being proxied comes under a
single trusted 'origin' from the browser's
perspective.
This also means any website can interact with the
DOM / Cookies of other proxied websites.
Bypassing the Proxy’s SOP
attacker.com IFrame’s the proxified site.com URL.
The user navigates to,


<iframe src=‘http://proxy.com/site?url=site.com’>
attacker.com gets hold of the iframe Window Object and
accesses its DOM.
At this point, the SOP is bypassed
a.k.a.
Game Over!
How do we solve this
problem?
Do not allow other websites to directly control your
proxified URL
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.
Proxy Hot-linking
This feature is like the achilles-heel of any web
proxy security.
If any website can directly get themselves being
IFRAME + Proxied by a web proxy then attacks
like the SOP bypass and other attacks are easily
possible.
Glype Proxy Hot-Linking
Bypassing Hot-Linking in Glype
Attacking Web Proxies
This checks for all the whitelisted websites in the Referer
If found, the hot-linking protection doesn’t apply to this!
Allowed Referrers
http://localhost
http://proxy-website-itself
And other whitelisted websites.
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/
Practical aspects
What if the target website prevents IFraming using
X-Frame-options?
What if the target website has set httpOnly
cookies?
True Story
Web based proxies don’t respect target website’s
HTTP Response Headers!
Web based proxies have their own Cookie Jar
implementation.
The X-Frame-Options Header won’t be replicated
back to the User’s browser.
Unsafe response rewrites
Messing around with security response headers
like X- Frame-Options, X-XSS-Protection, Content-
Security-Policy.
The proxies store the site cookies like this,
Cookie Jars on Proxy
Proxies under-estimate the complexity of Cookie
management.
Things like various cookie flags, handling of
secure channels, limit of cookies etc
Bypassing JavaScript restriction
Most proxies disable Javascript by default for a lot
of reasons.
They work by searching for Javascript patterns
and possibly removing them.
They cannot completely disable Javascript
because they are not the same as browser!
For a web attacker, this situation is like a XSS filter
bypass.
Most proxies don’t restrict
JS execution from
SVG, Complex JS Event handlers.
An attacker can also send chunked encoded
responses.
A certain bypass
//inputHTML = ‘<img src=“PLACEHOLDER”>’;
input = filterChars(input); // Filters ‘, “
final = inputHTML.replace(PLACEHOLDER, input)
document.write(final);
input = “$` onerror=alert(1)”;
EcmaScript’s String.replace
is funny!
http://www.ecma-international.org/ecma-262/5.1/#sec-15.5.4.11
Little bit of EcmaScript 5
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.
Proxies should adopt CSP
Content security policy helps extensively in locking
down proxy based attacks, since its enforced by
the browser.
Thanks!
@skeptic_fx

More Related Content

Attacking Web Proxies