I'm going to take a stab at answering this even though you haven't really provided enough information to be clear about how your proxy works and what it's intended to do.
I am assuming the following:
- All access to the Internet is filtered through this proxy; it's either invisible on the network gateway or any program not configured to use the proxy won't be allowed through the gateway. This applies to all protocols and ports.
- You are filtering on hostnames, not IP addresses.
If those are both true, then yes, the attack as described would work fine. It would be an inconvenient way to browse the web but it would totally work. If you want to block it you need to either:
- Filter on IP address, not hostnames, and ensure that all IP addresses you allow are trusted sites not usable as any kind of proxy.
- Inspect request destination IPs and hostnames, and ensure that they match (that is, the IP is assigned to that domain) and also that the hostname is whitelisted and no whitelisted hostname runs any kind of proxy.
If the latter is untrue - that is, you filter on IP addresses, not hostnames - then this won't work as described. However, it would still work if somebody with a whitelisted IP sets up an open proxy on that IP that reads the hostname and forwards the request accordingly (and relays the response), and your users edit their HOSTS files to point all the domain names they care about to this one IP.
If the former is untrue - that is, if there's any way, on some protocol or port or through changing the program configuration, to access the Internet without going through your proxy - then bypassing the filter is always going to be possible. People have built filter-bypass proxies (which they run on their own machines) that tunnel traffic through all kinds of things, like ICMP (the protocol used by ping
and tracert
/traceroute
), DNS requests and responses, and so on. If you allow SSH traffic - even if you block the default SSH port - it's easy; most ssh
implementations let you set up port tunneling to a remote system and then all the user needs to do is tell their browser to use a HTTP proxy on localhost, forward the proxy's port through SSH to an outside box, and run an actual proxy on that box.