kichik Dec 10 2010 at 00:22

Веб-сокеты временно отменяются

3 min

14K

Browsers

+51

Comments 48

aleks_raiden Dec 10 2010 at 00:38

ну это еще один повод советовать пользователям хром уже сейчас. И пусть остальные себе копошаться. Юзерам надо плюшки, уже сейчас возможные только сокетами, а не пространные рассуждения о возможных атаках

vgh Dec 10 2010 at 00:45

какой смысл использовать нестандартное уязвимое решение, которое гарантированно будет пересмотрено?

Drinker Dec 10 2010 at 10:29

Для внутренних решений, не передавая «сверхсекретные» данные по websocket-ам. Очень даже.

whynot Dec 10 2010 at 00:55

А какие есть уже работающие «плюшки» на вебсокетах?

homm Dec 10 2010 at 08:56

«Буратино был тупой.»

DIDJER Dec 10 2010 at 01:08

Блин, я уж игруху почти написал с этой технологией, во меня подставили.

marcus Dec 10 2010 at 01:18

Вот уж действительно, у нас тоже проект на вебсокетах в разработке. Надеюсь, проблему быстро устранят. Протокол-то хороший.

SailorMax Dec 10 2010 at 13:47

Пользуясь вот такими претендентами на стандарт вы сами себя подставляете. Это все равно что пользоваться рабочими сборками программ и жаловаться на их нестабильность…

aleks_raiden Dec 10 2010 at 14:41

а каким другим способом обеспечить постоянный реалтайм в браузере?

nekt Dec 10 2010 at 23:26

А как делали до появления веб-сокетов?

java, flash, ajax…

mace Dec 10 2010 at 01:22

Отличный пример того, почему не стоит сразу кидатся использовать неутвержденные стандарты.
Мы чуть менее года назад думали о том, чтобы использовать Web SQL Database в одном из проектов для поддержки офлайн режима. К счастью вовремя отказались от этой идеи и спустя некоторое время узнали, что проект стандарта спустили в унитаз.

Bonch Dec 10 2010 at 08:27

Насчет WS такое утверждение не совсем подходит, т.к. легко сделать downgrade до Comet, например.

Sannis Dec 10 2010 at 01:42

Не очень понял ваше описание уязвимости. Если я держу обычный HTTP прокси, мне тоже ничего не мешает подменить закешированный у меня www.google-analytics.com/ga.js. Почему же HTTP не признают опасным протоколом?

kichik Dec 10 2010 at 02:20

Подвох в том, что прокси чужой. Понятно, что если прокси мой, то я всегда могу подменить данные, проходящие через меня.

Подробности здесь www.adambarth.com/experimental/websocket.pdf.

Sannis Dec 10 2010 at 03:17

Подвох в том, что по тексту статьи не понятно, чем это плохо в случае WebSokets и почему другие протоколы этому не подвержены. Статью скачал, на свежую голову попробую понять :)

kichik Dec 10 2010 at 04:08

Суть проблемы в следующем, как я понимаю:

Между клиентом и сервером стоит промежуточная прозрачная прокси, часто выполняющая кеширующую функцию.

Злоумышленник коннектится через эту прокси к своему серверу, открывая сокет-соединение. В посылаемый запрос, который распознается прокси как обычный http-запрос, злоумышленник вставляет дополнительные данные, которые промежуточной прокси в силу ряда причин трактуются как второй запрос.

Этот второй запрос в качестве хоста содержит сервер-жертву (target.com), но посылается в рамках сокет-соединения туда же, куда и первый. И получает ответ от сервера злоумышленника с нужной информацией.

Дальше этот запрос вместе ответом кешируется в прокси.

Клиент-жертва обращается за этой же информацией на свой сервер, но так как его запросы выглядит также, как запрос злоумышленника, то он получает версию информации от злоумышленника, закешированную в прокси. И есть обратная схема, когда подменяется направление запроса (IP сервера).

В случае веб-сокетов это становится возможным в силу того, что промежуточная прокси не понимает, что ее используют для веб-сокетов и первичный запрос на открытие сокета и последующие запросы она видит как обычные http-запросы.

SilenceAndy Dec 10 2010 at 03:44

Подвох не в этом. Подвох в том, что прокси использует для кэширования хэддер Host, а не IP адрес сервера. Тут такой вектор атаки:

1. Мы создаем swf которая при открытии страницы создает сокет соединение с сервером attacker.com по 843 и получаем с него policy файл разрешающий подключение по всем портам.
2. Создаем socket соединение по 80 порту с сервером attacker.com.
3. Создаем запрос с фейковым хэддером:

GET /script.js HTTP/1.1

Host: target.com

по которому наш attacker.com вернет зловредный код script.js. Так как прокси для кэширования использует Host — в кэше окажется наш зловредный код, но принадлежащий к target.com, а не к attacker.com.
4. Пользователь запрашивает target.com/script.js и прокси отдает ему файл из кэша — файл полученный ранее с attacker.com.

kichik Dec 10 2010 at 04:09

Спасибо!

amosk Dec 10 2010 at 09:43

Прозрачный прокси должен выполнять серверные запросы к IP в который резолвится заголовок Host.
Если он вместо этого использует оригинальный IP назначения клиентского соединения, то это уязвимость конкретного прокси.

Причем здесь Web sockets? Вероятно уязвимость в чем то другом.

kichik Dec 10 2010 at 09:57

Это вопрос не веб-сокетов в браузере, а вопрос протокола, предлагающего решение, которое в таких случаях можно массово эксплуатировать. Да, это проблема прокси и правильной настройки прокси. Но эту проблему массово никато исправить не может, а вот пофиксить протокол — да.

amosk Dec 10 2010 at 10:34

А откуда про массовость проблемы известно?
Ни squid ни другие популярные прокси сервера такой уязвимости как transparent cache poisoning (из-за игнорирования DNS) не содержат, иначе она давно стала бы известна безо всяких веб сокетов.

kichik Dec 10 2010 at 11:01

Адам говорит о таких цифрах:

Not only are there theoretical vulnerabilities, our measurements show that approximately 3:6% of browsers are behind proxies with implementation errors that may enable attack via one of these vectors.

HnH Dec 10 2010 at 01:43

3 месяца назад начинал новый проект, и тогда серьёзно думал писать целиком под вебсокеты. Слава богу вовремя одумался в сторону APE. В нём, кстати говоря, реализованы различные методы передачи данных от клиента к серверу и наоборот (transport methods): Long Polling, JSONP. А в последних git версиях есть и поддержка 76 версии вебсокетов, так, что ребята работают в этом направлении, и, есть все основания верить, что с превращением Web Sockets в нормальную стабильную технологию можно будет с минимальными трудозатратами заставить работать приложение на APE через вебсокеты.

unxed Dec 10 2010 at 03:14

А в вебсокетах нет чего-нибудь вроде аналога ssl? Ну так с самого начала надо было думать :-/

witbier Dec 10 2010 at 07:06

wss:// же

unxed Dec 10 2010 at 07:29

Так а этот wss разве не решает проблему человека посередине?

witbier Dec 10 2010 at 08:19

решает.

unxed Dec 10 2010 at 17:06

Так откуда паника? Запретить временно ws, оставить wss, чтобы те, кому жизненно важна эта технология, могли бы продолжать её использовать.

Aux Dec 10 2010 at 18:10

То есть вы так взяли и побежали себе сертификаты покупать, да?

el777 Dec 10 2010 at 19:52

можно купить самый дешевый сертификат — лишь бы браузер принимал.
Проблема не в этом, а в резком росте нагрузки за счет шифрования.

unxed Dec 10 2010 at 20:39

А что дешевле — самый дешевый сертификат за 10$ в год, или переписать половину логики приложения?

seriyPS Dec 10 2010 at 03:33

Да на самом деле если кто то сейчас и разрабатывает на веб-сокетах, то, скорее всего, для подстраховки на случай когда они не поддерживаются браузером, имеет или Long Pooling или Flash альтернативу

Guria Dec 10 2010 at 16:29

flash альтернатива, как я понял уязвима аналогично

SdotR Dec 10 2010 at 04:03

Как я понял, IE и не собирался поддерживать WebSockets. А вот как насчет WebKit'овских браузеров (Chrome, Safari, др.)? Они будут выключать WebSockets?

kichik Dec 10 2010 at 04:14

Apple и Google, вроде, пока молчат относительно будущих версий и поддержки или неподдержки веб-сокетов.

Представители Microsoft периодически участвуют в дискуссиях по WebSockets и протоколу, но скорее выжидают стабилизации стандарта. Внутри есть понимание, что в целом, это нужная вещь. Но на грабли несовместимостей при реализации наступать как-то не хочется ;)

vsviridov Dec 10 2010 at 06:28

Бля. Ну, ничего, есть пока что Flash Websocket, можно и через него работать.

witbier Dec 10 2010 at 07:12

Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101209 Firefox-4.0/4.0b8pre

В версии 4.0~b8~hg20101209r58922+nobinonly-0ubuntu1~umd1~maverick из PPA уже выпилено. Печаль…

witbier Dec 10 2010 at 07:17

about:config -> network.websocket.override-security-block -> true

Выдыхаем и продолжаем свои переднекраевые экзерсисы.

professor_kuvalda Dec 10 2010 at 09:23

хорошо, что есть такая штука, как socket.io.
сменить веб-сокеты, на лонг-поллинг и прочее доисторическое говно можно крайне легко.

Throwable Dec 10 2010 at 10:52

У меня такое ощущение, что развитие IT-технологий — это вечное переизобретение велосипеда, только каждый раз более грузного и медленного. Изначально существовали обычные TCP-сокеты, которые решали и до сих пор решают поставленную задачу. Вебсокеты — это очередной велосипед, только средствами браузера.

bolk Dec 10 2010 at 13:00

Всё-таки зря назвали эту технологию «сокетами», люди путаются. TCP-сокеты и WebSocket — это совсем разные вещи. Примерно как JavaScript и Java.

Throwable Dec 10 2010 at 20:23

> WebSocket — протокол полнодуплексной двунаправленной связи поверх TCP соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.

Один реализуется поверх другого. Отличие примерно такое же как между JavaScript и JQuery. Но цель у них одна — дуплексный обмен данными в реальном времени. Использовать голый TCP в окружении браузера проблематично — это не юникс, и с тредами здесь проблемы. Поэтому добавили асинхронный JavaScript API для пакетного обмена.

Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.

bolk Dec 10 2010 at 22:59

Всё смешалось, люди, кони.

HTTP тоже работает поверх TCP, это ещё не повод называть его «сокетом». Я знаю, что такое WebSocket, это не «сокеты».

SVlad Dec 11 2010 at 01:49

А чем WebSocket, как интерфейс, отличается от, например, TCP Socket?
Так что можно было те же сокеты TCP дооформить до нужного уровня безопасности, и включить в стандартный набор браузера.

bolk Dec 11 2010 at 13:31

Ну это как в анекдоте: «чем отличаются трактор и помидор? Помидор красный, а у трактора дверки наружу открываются».

Чем IPX отличается интерфейсно от TCP? UDP от ICMP? Ваше сравнение примерно того же порядка.

SVlad Dec 11 2010 at 01:41

Есть такая старая мысль, что всё развивается по спирали.

Homakov Dec 10 2010 at 15:28

очень расстроен( буквально на них одних я делал ставку в проекте

Throwable Dec 11 2010 at 13:17

Сейчас рано делать ставку на эту технологию. Кроме того пройдет немало времени, прежде чем все клиенты будут поддерживать ее. Поэтому лучше использовать оболочку для дуплексных коннекшнов, которая снизу умеет работать как с Comet, так и с WS. Для серверной части это фреймворк Atmosphere. К нему существует куча клиентов, например JQuery plugin: jfarcand.wordpress.com/2010/06/15/using-atmospheres-jquery-plug-in-to-build-applicationsupporting-both-websocket-and-comet
В своем проекте я использовал GWT Comet. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.