Transparent proxying vulnerabilities, WebSocket funeral cancellation, exhale ...
After reading "Web Sockets Temporarily Canceled" , I could not resist and decided to respond.
So, the latest news from the fronts of IT. They are shocking.
')
Because of the serious unclosed vulnerability in Adobe Flash, all major browsers refused to support it. Yes, yes, there will be no more Flash in the network, alas. This was stated by all the leading grandmothers sitting on a bench in my yard.
Because of a serious unclosed vulnerability in Internet Explorer of all versions up to 9, all IE users refuse to visit the Network. New nightmare for web designers - you no longer need to maintain versions of the site for different versions of IE. Nightmare! Where to put these skills? Where is the janitor's free space?
Because of the serious unclosed vulnerability in Windows, all browser manufacturers refuse to support this platform. “Yes, yes, we are switching to ReactOS,” in an exclusive interview, confirmed the lead developer of the leading browser of the leading company in the slave market.
Finally, the apotheosis was the statements of the head of the development of winter tires in the company Myshan. “We analyzed 1829783 accidents that occurred with the cars on which our tires were installed. And they came to the conclusion that all of them had round wheels. Since driving safety is our everything, we decided to abandon the round wheels and go to the square ones. „
Well, joking and that's enough. Let's try to figure it out.
First of all, the Adam Barth article is titled “Transparent Proxies: Threat or Menace?”. That is, the author investigates not the WebSocket protocol, but “transparent proxying”.
What it is? It's simple - if the client has specified a proxy explicitly, then this is an explicit proxy. And if any browser request (for example, in some hotel) is imperceptibly intercepted by a special proxy for filtering, then this is a “transparent” proxy.
The problem (according to the author) is as follows. Transparent proxy received an HTTP request. Since the proxy is transparent, it intercepts the request sent from the client to a specific IP address (server). In this case, the HTTP request itself may also specify a Host. It seems from the point of view of logic, the proxy should send the request to where it was going - that is, to the original IP. However, according to the authors, some proxies will send an HTTP request to the IP address that corresponds to the host in the Host request header.
We will not discuss this decision from the point of view of "correctness" yet. Suppose that some transparent proxies do redirect the request to the host in the Host header. What follows from this?
The author further refers to another document .
Suppose that a malicious site has loaded a Flash application into a browser that has received permission to use raw sockets, that is, simply speaking, a flash application can use a TCP / IP connection to the server from which it was loaded. Can a transparent proxy distinguish such a connection from the browser? Can not. If the flash application generates and sends the correct HTTP request to the server via TCP, then the transparent proxy will decide that the request is sent by the browser. A malicious flash application will insert a Host into its malicious request, which will point to the malicious host.
And now, if the proxy is so stupid that it will go to receive a response to the (malicious) host in the Host field, then from this server it will slip anything, and the proxy will assume that it answered the original (good) host (to the IP address which request is initially sent).
We get two problems:
1. malicious flash application can now access any web server, and not just the one from which it was downloaded;
2. if the proxy caches the response, then subsequent requests to a good server from any client will receive a malicious cached response.
So, the problem of compromising the transparent proxy cache and violation of the SOP flash application occurs if the transparent proxy forwards the request to the host in the Host header (instead of using the IP address to which the request was sent).
And hereLuzhkov WebSocket? Nothing to do with it. Go ahead. Take a look at the RFC marmot encyclopedia . We will be interested in RFC 1919 , which defines transparent proxying. We read:
That is, the standard clearly states that it is necessary to take the IP address of the request, and not from the Host field .
Again, it seems, WebSocket is not to blame. Ok, back to the original article by the author.
The authors conducted an experiment. They handed out to people an advertising banner that tried to crank up a similar pattern: send an HTTP request to the “other” Host. Both flash and java applications were used. The experiment showed that 2.2% (803 of 36305) requests using malicious Flash and 3.6% (1212 of 33820) requests using malicious Java class were redirected to Host in the HTTP header, and not to the IP address.
Further, the authors are trying to "deceive" the proxy using the WebSocket protocol. If a transparent proxy does not know anything about WebSocket, then the client can send a message like this to TCP after WebSocket handshake:
Since the hapless proxy knows nothing about WebSocket, he will decide that this is another HTTP request. And he will “go” to victim.com and transfer it there. The authors' experiment showed that this was done by 2.8% of the proxy (1376 of 49218). Further, the experiment essentially repeated.
So, the statement that WebSocket is insecure is incorrect .
Security breaches occur because transparent proxies do not know WebSocket and violate RFC 1919 .
The study authors propose their solution: use the HTTP CONNECT command for WebSocket. Their experiment has shown that _all_ transparent proxies work well for CONNECT. They believe that inside will be HTTPS data and do not try to parse them. Requests go to the original IP.
Summarize.
Approximately 3% of transparent proxies ruled HTTP requests to host IP addresses specified in the Host field of the request header. This is a violation of the RFC 1919 standard. You must rut to the source IP address to which the request was sent.
This behavior allows a malicious Flash application, Java applet or JavaScript script to access any sites (violation of the Same Origin Policy principle) and compromise the cache of these proxies.
Malicious javascript can only harm if the browser supports WebSockets. Flash application and Java applet do not need browser support for WebSockets to harm.
Switching to the CONNECT command in the handshake WebSocket (with some modifications) will allow to “close the hole” in the case of WebSocket ...
... BUT USING HARMFUL FLASH AND JAVA APPLICATIONS TO DISABLE SOP AND PROXY CARD COMPROMINATION REMAINS POSSIBLE UNTIL THEREFORE, TRANSPARENT PROXY DISABLE RCF 1919.
Picture for distraction.
PS
Forgot to add. The developers of Opera and FireFox needto understand what to do with the security system, that is, consistent.
If the problem of transparent proxies bothers them so much, then both Flash and Java should be disabled.
And so it looks like a cheap PR trick:
“Look, we care about security. We left a full of holes in our browser, but we turned off the WebSocket and now you are safe. ”
Pss
A little corrected. I hope it became even clearer ...
So, the latest news from the fronts of IT. They are shocking.
')
Because of the serious unclosed vulnerability in Adobe Flash, all major browsers refused to support it. Yes, yes, there will be no more Flash in the network, alas. This was stated by all the leading grandmothers sitting on a bench in my yard.
Because of a serious unclosed vulnerability in Internet Explorer of all versions up to 9, all IE users refuse to visit the Network. New nightmare for web designers - you no longer need to maintain versions of the site for different versions of IE. Nightmare! Where to put these skills? Where is the janitor's free space?
Because of the serious unclosed vulnerability in Windows, all browser manufacturers refuse to support this platform. “Yes, yes, we are switching to ReactOS,” in an exclusive interview, confirmed the lead developer of the leading browser of the leading company in the slave market.
Finally, the apotheosis was the statements of the head of the development of winter tires in the company Myshan. “We analyzed 1829783 accidents that occurred with the cars on which our tires were installed. And they came to the conclusion that all of them had round wheels. Since driving safety is our everything, we decided to abandon the round wheels and go to the square ones. „
Well, joking and that's enough. Let's try to figure it out.
First of all, the Adam Barth article is titled “Transparent Proxies: Threat or Menace?”. That is, the author investigates not the WebSocket protocol, but “transparent proxying”.
What it is? It's simple - if the client has specified a proxy explicitly, then this is an explicit proxy. And if any browser request (for example, in some hotel) is imperceptibly intercepted by a special proxy for filtering, then this is a “transparent” proxy.
The problem (according to the author) is as follows. Transparent proxy received an HTTP request. Since the proxy is transparent, it intercepts the request sent from the client to a specific IP address (server). In this case, the HTTP request itself may also specify a Host. It seems from the point of view of logic, the proxy should send the request to where it was going - that is, to the original IP. However, according to the authors, some proxies will send an HTTP request to the IP address that corresponds to the host in the Host request header.
We will not discuss this decision from the point of view of "correctness" yet. Suppose that some transparent proxies do redirect the request to the host in the Host header. What follows from this?
The author further refers to another document .
Suppose that a malicious site has loaded a Flash application into a browser that has received permission to use raw sockets, that is, simply speaking, a flash application can use a TCP / IP connection to the server from which it was loaded. Can a transparent proxy distinguish such a connection from the browser? Can not. If the flash application generates and sends the correct HTTP request to the server via TCP, then the transparent proxy will decide that the request is sent by the browser. A malicious flash application will insert a Host into its malicious request, which will point to the malicious host.
And now, if the proxy is so stupid that it will go to receive a response to the (malicious) host in the Host field, then from this server it will slip anything, and the proxy will assume that it answered the original (good) host (to the IP address which request is initially sent).
We get two problems:
1. malicious flash application can now access any web server, and not just the one from which it was downloaded;
2. if the proxy caches the response, then subsequent requests to a good server from any client will receive a malicious cached response.
So, the problem of compromising the transparent proxy cache and violation of the SOP flash application occurs if the transparent proxy forwards the request to the host in the Host header (instead of using the IP address to which the request was sent).
And here
4.2.3 DNS requirements
In transparent proxy configurations, client systems MUST be
able to resolve server names belonging to remote networks. This
is critical since the proxy will determine the target server
from the destination IP address of the packets arriving from
the client.
That is, the standard clearly states that it is necessary to take the IP address of the request, and not from the Host field .
Again, it seems, WebSocket is not to blame. Ok, back to the original article by the author.
The authors conducted an experiment. They handed out to people an advertising banner that tried to crank up a similar pattern: send an HTTP request to the “other” Host. Both flash and java applications were used. The experiment showed that 2.2% (803 of 36305) requests using malicious Flash and 3.6% (1212 of 33820) requests using malicious Java class were redirected to Host in the HTTP header, and not to the IP address.
Further, the authors are trying to "deceive" the proxy using the WebSocket protocol. If a transparent proxy does not know anything about WebSocket, then the client can send a message like this to TCP after WebSocket handshake:
GET /sensitive-document HTTP/1.1
Host: victim.com
Since the hapless proxy knows nothing about WebSocket, he will decide that this is another HTTP request. And he will “go” to victim.com and transfer it there. The authors' experiment showed that this was done by 2.8% of the proxy (1376 of 49218). Further, the experiment essentially repeated.
So, the statement that WebSocket is insecure is incorrect .
Security breaches occur because transparent proxies do not know WebSocket and violate RFC 1919 .
The study authors propose their solution: use the HTTP CONNECT command for WebSocket. Their experiment has shown that _all_ transparent proxies work well for CONNECT. They believe that inside will be HTTPS data and do not try to parse them. Requests go to the original IP.
Summarize.
Approximately 3% of transparent proxies ruled HTTP requests to host IP addresses specified in the Host field of the request header. This is a violation of the RFC 1919 standard. You must rut to the source IP address to which the request was sent.
This behavior allows a malicious Flash application, Java applet or JavaScript script to access any sites (violation of the Same Origin Policy principle) and compromise the cache of these proxies.
Malicious javascript can only harm if the browser supports WebSockets. Flash application and Java applet do not need browser support for WebSockets to harm.
Switching to the CONNECT command in the handshake WebSocket (with some modifications) will allow to “close the hole” in the case of WebSocket ...
... BUT USING HARMFUL FLASH AND JAVA APPLICATIONS TO DISABLE SOP AND PROXY CARD COMPROMINATION REMAINS POSSIBLE UNTIL THEREFORE, TRANSPARENT PROXY DISABLE RCF 1919.
Picture for distraction.
PS
Forgot to add. The developers of Opera and FireFox need
If the problem of transparent proxies bothers them so much, then both Flash and Java should be disabled.
And so it looks like a cheap PR trick:
“Look, we care about security. We left a full of holes in our browser, but we turned off the WebSocket and now you are safe. ”
Pss
A little corrected. I hope it became even clearer ...
Source: https://habr.com/ru/post/109785/
All Articles