Комментарии 26
Да нет же. Прокси идёт по IP-адресу. А вот кэширует по Host. Соответствие при этом не проверяется.
ну так это в любом случае проблема прокси-сервера, а не протокола. Или как?
Да, насколько я понимаю, это поведение не специфично для web sockets.
Для обычного сайта можно спастись, используя HTTPS, не в курсе, доступен ли какой-нибудь аналог для web sockets.
Я, собственно, лишь хотел указать, что автор исходную статью понял неправильно.
Для обычного сайта можно спастись, используя HTTPS, не в курсе, доступен ли какой-нибудь аналог для web sockets.
Я, собственно, лишь хотел указать, что автор исходную статью понял неправильно.
Я начинаю смутно догадываться, что суть описанной проблемы в следующем:
1) есть ряд прокси серверов, уязвимых для cache poisoning
2) всунуть свой мусор в кеш не проблема — реализацию любой программист настрочит за пару минут
3) но сделать это можно только находясь позади прокси. снаружи этот фокус не пройдёт
4) т.е. для злоумышленнику нужно либо самому сидеть за этим прокси или же подсунуть свою программу-троян кому-нибудь (заставить запустить, использовать уязвимости системы и т.п.)
5) а вот вебсокеты позволяют это сделать без проблем: достаточно пользователю за уязвимым прокси открыть URL :)
Поправьте меня, если неправ.
1) есть ряд прокси серверов, уязвимых для cache poisoning
2) всунуть свой мусор в кеш не проблема — реализацию любой программист настрочит за пару минут
3) но сделать это можно только находясь позади прокси. снаружи этот фокус не пройдёт
4) т.е. для злоумышленнику нужно либо самому сидеть за этим прокси или же подсунуть свою программу-троян кому-нибудь (заставить запустить, использовать уязвимости системы и т.п.)
5) а вот вебсокеты позволяют это сделать без проблем: достаточно пользователю за уязвимым прокси открыть URL :)
Поправьте меня, если неправ.
ну так и флеш и java позволяют.
достаточно открыть URL
или я не прав?
достаточно открыть URL
или я не прав?
флеш и жава — это, все ж таки, плагины.
и разработчики браузеров не шибко много с ними сделать могут.
а тут получилось, они сами еще один вектор атаки создают.
вот и засуетились.
и разработчики браузеров не шибко много с ними сделать могут.
а тут получилось, они сами еще один вектор атаки создают.
вот и засуетились.
Ключевая фраза, на которую автору топика нужно обратить внимание.
Flash и Java — это сторонние плагины.
WebSocket же это часть браузера, за которую отвечают непосредственно разработчики браузера. От сюда и становится понятна их реакция.
Но, я согласен с автором в том что, если можно допилить WebSocket, то пусть допиливают.
Flash и Java — это сторонние плагины.
WebSocket же это часть браузера, за которую отвечают непосредственно разработчики браузера. От сюда и становится понятна их реакция.
Но, я согласен с автором в том что, если можно допилить WebSocket, то пусть допиливают.
Нет, все именно так, как я написал.
There are two common ways a transparent proxy will relay a user’s request to an end destination.
Approach A: Use the destination IP from the client
The first involves receiving a request from a client, inspecting the http payload, then forwarding this
HTTP payload to the ‘destination IP' specified by the client. In this configuration the transparent proxy
routes requests much like a standard router by basing its routing decisions off of the network layer
(layer 3).
Approach B: Inspect application layer data
The second involves identifying the end destination based on the HTTP payload instead of the client
destination IP by inspecting the HTTP 'Host' header or request URI. In this configuration the transparent
proxy is determining IP destinations based on the application protocol (layer 7) instead of IP (layer 3).
Due to the socket capabilities of browser plug-ins (flash/etc) this second architecture can be exploited
by an attacker to gain access to any destination accessible by the proxy.
«Плохой» прокси идет по IP адресу хоста из запроса.
There are two common ways a transparent proxy will relay a user’s request to an end destination.
Approach A: Use the destination IP from the client
The first involves receiving a request from a client, inspecting the http payload, then forwarding this
HTTP payload to the ‘destination IP' specified by the client. In this configuration the transparent proxy
routes requests much like a standard router by basing its routing decisions off of the network layer
(layer 3).
Approach B: Inspect application layer data
The second involves identifying the end destination based on the HTTP payload instead of the client
destination IP by inspecting the HTTP 'Host' header or request URI. In this configuration the transparent
proxy is determining IP destinations based on the application protocol (layer 7) instead of IP (layer 3).
Due to the socket capabilities of browser plug-ins (flash/etc) this second architecture can be exploited
by an attacker to gain access to any destination accessible by the proxy.
«Плохой» прокси идет по IP адресу хоста из запроса.
Да, я недопонял проблему.
Итак, есть java, flash и web sockets. Все они используют схему защиты same-origin, т.е. можно обращаться лишь к тому серверу, с которого получен апплет/флэш/скрипт. «Тот же сервер» определяется как «тот же IP», так как сравнение серверов по hostname подвержено DNS rebinding attack (подробности в исходной статье, если нужно — разверну здесь).
Такое ограничение слишком строго, поэтому есть механизмы повышения привилегий. В частности, если Flash-апплет пытается соединиться с левым сервером, то Flash сначала качает файл правил с этого сервера и позволяет соединение, если сайт, с которого загружен обращающийся скрипт, содержится в списке правил.
Подобные механизмы расслабления ограничений есть также для XMLHttpRequest и для web sockets. Но для web sockets есть особенность — запрос разрешения на общение идет в рамках того же соединения, по которому потом пойдут данные.
Пусть пользователь за прозрачным прокси зашел на attacker.com и получил страничку с флешкой. Если прокси определяет IP-адрес сервера исходя из значения заголовка Host, то происходит следующее:
* флешка запрашивает соединение до attacker.com
* флеш грузит правила с attacker.com
* на attacker.com лежат правила, позволяющие соединяться кому угодно и откуда угодно
* флеш успешно устанавливает соединение до attacker.com
* теперь через установленное соединение передаем данные, которые выглядят, как начало нового HTTP-запроса, причём с заголовком Host: google.com
* данные успешно передаются, так как флеш знает, что соединена флешка с attacker.com, а туда можно коннектиться
* но тупая прозрачная прокси видит начало запроса и подсоединяется к серверу, указанному в заголовке Host
Итог: смогли загрузить содержимое с совершенно левого сервера.
А используя метод CONNECT, можно даже заставить прокси открыть RAW connection на указанный хост, так как по команде CONNECT прокси перестает искать HTTP-запросы в потоке данных.
Это описана атака на прокси, использующие заголовок Host для маршрутизации.
Но некоторые прокси, использующие IP адрес, также уязвимы! Это как раз то, про что я писал в самом первом комментарии.
Открываем соединение до своего сервера attacker.com, это либо разрешено по умолчанию (Java), либо можно разрешить с помощью файла правил (SWF). Затем отправляем запрос, но указывает Host: google.com. Если проки кеширует запросы по заголовку Host, то содержимое, загруженное с attacker.com, будет помечено как загруженное с google.com и его получат следующие клиенты прокси.
Если наполнить таким образом вредоносными скриптами кэш для google-analytics, то потом из кэша его получат очень многие, так как google analytics используется на 57% страниц!
Причем здесь web sockets? Да собственно, они позволяют сделать то же самое — передать произвольные данные, которые прокси воспримет как начало нового соединения.
Итог: не все прокси, которые используют IP-адрес — хорошие.
Итак, есть java, flash и web sockets. Все они используют схему защиты same-origin, т.е. можно обращаться лишь к тому серверу, с которого получен апплет/флэш/скрипт. «Тот же сервер» определяется как «тот же IP», так как сравнение серверов по hostname подвержено DNS rebinding attack (подробности в исходной статье, если нужно — разверну здесь).
Такое ограничение слишком строго, поэтому есть механизмы повышения привилегий. В частности, если Flash-апплет пытается соединиться с левым сервером, то Flash сначала качает файл правил с этого сервера и позволяет соединение, если сайт, с которого загружен обращающийся скрипт, содержится в списке правил.
Подобные механизмы расслабления ограничений есть также для XMLHttpRequest и для web sockets. Но для web sockets есть особенность — запрос разрешения на общение идет в рамках того же соединения, по которому потом пойдут данные.
Пусть пользователь за прозрачным прокси зашел на attacker.com и получил страничку с флешкой. Если прокси определяет IP-адрес сервера исходя из значения заголовка Host, то происходит следующее:
* флешка запрашивает соединение до attacker.com
* флеш грузит правила с attacker.com
* на attacker.com лежат правила, позволяющие соединяться кому угодно и откуда угодно
* флеш успешно устанавливает соединение до attacker.com
* теперь через установленное соединение передаем данные, которые выглядят, как начало нового HTTP-запроса, причём с заголовком Host: google.com
* данные успешно передаются, так как флеш знает, что соединена флешка с attacker.com, а туда можно коннектиться
* но тупая прозрачная прокси видит начало запроса и подсоединяется к серверу, указанному в заголовке Host
Итог: смогли загрузить содержимое с совершенно левого сервера.
А используя метод CONNECT, можно даже заставить прокси открыть RAW connection на указанный хост, так как по команде CONNECT прокси перестает искать HTTP-запросы в потоке данных.
Это описана атака на прокси, использующие заголовок Host для маршрутизации.
Но некоторые прокси, использующие IP адрес, также уязвимы! Это как раз то, про что я писал в самом первом комментарии.
Открываем соединение до своего сервера attacker.com, это либо разрешено по умолчанию (Java), либо можно разрешить с помощью файла правил (SWF). Затем отправляем запрос, но указывает Host: google.com. Если проки кеширует запросы по заголовку Host, то содержимое, загруженное с attacker.com, будет помечено как загруженное с google.com и его получат следующие клиенты прокси.
Если наполнить таким образом вредоносными скриптами кэш для google-analytics, то потом из кэша его получат очень многие, так как google analytics используется на 57% страниц!
Причем здесь web sockets? Да собственно, они позволяют сделать то же самое — передать произвольные данные, которые прокси воспримет как начало нового соединения.
Итог: не все прокси, которые используют IP-адрес — хорошие.
Все правильно сказал [x]
НЛО прилетело и опубликовало эту надпись здесь
Я ничего не понял из вашего объяснения:
В чем опасность того, что клиент отправит host: evil.com, на ip-адрес сайта good.com? Прокси переведет запрос в соответствии с заголовком host на ip-адрес evil.com. Получится обчный запрос к evil.com, а при обращении к good.com будет выдаваться хороший ответ.
Другое дело, что если все будет наоборот:
Клиент пошлет на IP-адрес evil.com запрос с host: good.com и evil.com вернет ему ответ, который закешируется для хоста good.com (такой хост был указан при запросе).
И теперь, если прокси настолько глуп, что пойдет получать ответ к (зловредному) хосту в поле Host, то с этого сервера ему подсунут что угодно, причем прокси будет считать, что ответил ему исходный (хороший) хост.«исходный (хороший) хост» — это что? Я вижу тут один хост, который запрошен, а какой считается исходным?
В чем опасность того, что клиент отправит host: evil.com, на ip-адрес сайта good.com? Прокси переведет запрос в соответствии с заголовком host на ip-адрес evil.com. Получится обчный запрос к evil.com, а при обращении к good.com будет выдаваться хороший ответ.
Другое дело, что если все будет наоборот:
Клиент пошлет на IP-адрес evil.com запрос с host: good.com и evil.com вернет ему ответ, который закешируется для хоста good.com (такой хост был указан при запросе).
После прочтения статьи почему то вспомнились две фразы — «вот на эти 2% я и живу» и «ложечки нашлись но осадочек остался»
Ну наконец-то первый разумный комментарий на эту тему, а то уже сам писать собирался :)
Действуют прямо как белки-истерички: «а, смотрите, это проки, ааа, это уязвимость!»
Действуют прямо как белки-истерички: «а, смотрите, это проки, ааа, это уязвимость!»
Вообще, иногда мне кажется, что прокси — это такой узаконенный man-in-the-middle. Просто по определению. Человек, который перехватывает ваш трафик. Поэтому нужно быть морально готовым к тому, что у него может оказаться кривое ПО.
Если проблема прозрачных прокси их так беспокоит, то следует запретить и Flash, и Java
Если Flash и Java были бы сырыми черновиками будущего стандарта, а не технологиями, используемыми в течении многих лет огромным количеством сайтов и пользователей, то отключили бы и Flash с Java.
Спасибо, что растолковали. Сразу подозревал, что не в этом дело :)
К слову, веб-сокеты никто не хоронил ;)
Разработчики FF и Opera сказали, что все вернут, как только допилят протокол. А сами веб-сокеты в браузере не выпиливают, а отключают. Насколько я понимаю, их можно вручную включить для продолжения экспериментов.
Разработчики FF и Opera сказали, что все вернут, как только допилят протокол. А сами веб-сокеты в браузере не выпиливают, а отключают. Насколько я понимаю, их можно вручную включить для продолжения экспериментов.
насколько я понимаю, типичная связка squid + iptables подвержена этой проблеме, т.к. squid не лазит в ядро за исходным IP-адресом назначения. Или лазит?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимости прозрачного проксирования, отмена похорон WebSocket, выдыхаем…