Most of you know how CONNECT method is used by the client and the proxy to successfully tunnel an HTTPS connection without the proxy seeing the data. If you don't, then here is a quick description.
The client sends a CONNECT request to the proxy asking it to connect to the specified destination.
e.g. [1]
CONNECT mail.google.com:443 HTTP/1.0
User-agent: xyz
The proxy then connects to the destination server and if it succeeds in establishing this connection, it sends a 'Connection Successful' message to the client.
e.g. [2]
HTTP/1.0 200 Connection established
Proxy-agent: abc
After this the tunneling takes place. The tunnel is broken after either party disconnects.
It is obvious that neither the actual headers nor the URL/POST data is visible to the proxy.
However, as it can be seen from example [1], the host name is visible to the proxy.
Now you may wonder why this is important. Here is the reason why.
There exists a magical concept called the Same Origin Policy which all of you know. It states that the javascript on one domain can not access the data originating from the other domain under normal circumstances. The same fact is used by some applications to reduce the impact of an XSS on the users. Now these Apps are not directly harmed. However, if some implementations choose to include important user (session) information in the host name (E.g. XSS immune session using one time URL) then the proxies are able to see this information.
Therefore you can use multiple hosts to reduce the impact of XSS, but adding sensitive information as sub-domain name should be avoided.
Discussion on XSS immune session handling
Saturday, June 23, 2007
SSL tunneling using CONNECT method and its security implications
Subscribe to:
Post Comments (Atom)
5 comments:
That's interesting, I completely forgot about proxies. On a similar note, if you can view a user's DNS lookups, you can also find subdomain info.
But generally, if you can do either of those things, the user has bigger problems anyway.
Kuza you are right. But an app will try to keep the critical functions like credit card transactions etc. on HTTPS. While other pages may be important, the https pages may directly affect your bank accounts :)
Also, you can do attacks against SessionSafe even if you can't see the host name, because you can block the request from SessionSafe for the next token, and then make one yourself, but have your proxy allow yours through.
This is a bit of a guessing game since you need to guess which request is the request for the token, but it should be fairly easy, since it would be the second request in the PoC implementation of the URL randomiser, or the third request in the complete implementation (since the Delayer loading thing makes one), but it should work fairly well.
Interesting!
I assume you are talking about the first request for the token after the session starts.
E.g. you go to
http://home/
you login, and get
http://home/loggedin
and this page sends
http://home/getnexttoken
And you block the third (getnexttoken) one.
Is that correct?
Yeah, that's what I meant. Though it doesn't have to be the first token request after the session starts, it just has to be the one which is requested by the page which you have your XSS attack on.
Post a Comment