How to become an author
Search
Write a publication
Pull to refresh

Comments 48

ну это еще один повод советовать пользователям хром уже сейчас. И пусть остальные себе копошаться. Юзерам надо плюшки, уже сейчас возможные только сокетами, а не пространные рассуждения о возможных атаках
Total votes 42: ↑6 and ↓36-30
какой смысл использовать нестандартное уязвимое решение, которое гарантированно будет пересмотрено?
Total votes 14: ↑12 and ↓2+10
Для внутренних решений, не передавая «сверхсекретные» данные по websocket-ам. Очень даже.
Total votes 2: ↑1 and ↓10
А какие есть уже работающие «плюшки» на вебсокетах?
Total votes 6: ↑4 and ↓2+2
«Буратино был тупой.»
Total votes 14: ↑10 and ↓4+6
Блин, я уж игруху почти написал с этой технологией, во меня подставили.
Total votes 5: ↑4 and ↓1+3
Вот уж действительно, у нас тоже проект на вебсокетах в разработке. Надеюсь, проблему быстро устранят. Протокол-то хороший.
Total votes 1: ↑1 and ↓0+1
Пользуясь вот такими претендентами на стандарт вы сами себя подставляете. Это все равно что пользоваться рабочими сборками программ и жаловаться на их нестабильность…
Total votes 4: ↑3 and ↓1+2
а каким другим способом обеспечить постоянный реалтайм в браузере?
Total votes 1: ↑1 and ↓0+1
А как делали до появления веб-сокетов?

java, flash, ajax…
Total votes 1: ↑1 and ↓0+1
Отличный пример того, почему не стоит сразу кидатся использовать неутвержденные стандарты.
Мы чуть менее года назад думали о том, чтобы использовать Web SQL Database в одном из проектов для поддержки офлайн режима. К счастью вовремя отказались от этой идеи и спустя некоторое время узнали, что проект стандарта спустили в унитаз.
Total votes 12: ↑11 and ↓1+10
Насчет WS такое утверждение не совсем подходит, т.к. легко сделать downgrade до Comet, например.
Total votes 2: ↑1 and ↓10
Не очень понял ваше описание уязвимости. Если я держу обычный HTTP прокси, мне тоже ничего не мешает подменить закешированный у меня www.google-analytics.com/ga.js. Почему же HTTP не признают опасным протоколом?
Total votes 10: ↑9 and ↓1+8
Подвох в том, что прокси чужой. Понятно, что если прокси мой, то я всегда могу подменить данные, проходящие через меня.

Подробности здесь www.adambarth.com/experimental/websocket.pdf.
Total votes 2: ↑1 and ↓10
Подвох в том, что по тексту статьи не понятно, чем это плохо в случае WebSokets и почему другие протоколы этому не подвержены. Статью скачал, на свежую голову попробую понять :)
Total votes 1: ↑1 and ↓0+1
Суть проблемы в следующем, как я понимаю:

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

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

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

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

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

В случае веб-сокетов это становится возможным в силу того, что промежуточная прокси не понимает, что ее используют для веб-сокетов и первичный запрос на открытие сокета и последующие запросы она видит как обычные http-запросы.
Total votes 4: ↑3 and ↓1+2
Подвох не в этом. Подвох в том, что прокси использует для кэширования хэддер 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.
Total votes 12: ↑12 and ↓0+12
Прозрачный прокси должен выполнять серверные запросы к IP в который резолвится заголовок Host.
Если он вместо этого использует оригинальный IP назначения клиентского соединения, то это уязвимость конкретного прокси.

Причем здесь Web sockets? Вероятно уязвимость в чем то другом.
Total votes 2: ↑2 and ↓0+2
Это вопрос не веб-сокетов в браузере, а вопрос протокола, предлагающего решение, которое в таких случаях можно массово эксплуатировать. Да, это проблема прокси и правильной настройки прокси. Но эту проблему массово никато исправить не может, а вот пофиксить протокол — да.
Total votes 3: ↑2 and ↓1+1
А откуда про массовость проблемы известно?
Ни squid ни другие популярные прокси сервера такой уязвимости как transparent cache poisoning (из-за игнорирования DNS) не содержат, иначе она давно стала бы известна безо всяких веб сокетов.
Total votes 1: ↑1 and ↓0+1
Адам говорит о таких цифрах:
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.
Total votes 1: ↑0 and ↓1-1
3 месяца назад начинал новый проект, и тогда серьёзно думал писать целиком под вебсокеты. Слава богу вовремя одумался в сторону APE. В нём, кстати говоря, реализованы различные методы передачи данных от клиента к серверу и наоборот (transport methods): Long Polling, JSONP. А в последних git версиях есть и поддержка 76 версии вебсокетов, так, что ребята работают в этом направлении, и, есть все основания верить, что с превращением Web Sockets в нормальную стабильную технологию можно будет с минимальными трудозатратами заставить работать приложение на APE через вебсокеты.
Total votes 3: ↑2 and ↓1+1
А в вебсокетах нет чего-нибудь вроде аналога ssl? Ну так с самого начала надо было думать :-/
This comment wasn’t rated yet0
Так а этот wss разве не решает проблему человека посередине?
This comment wasn’t rated yet0
Так откуда паника? Запретить временно ws, оставить wss, чтобы те, кому жизненно важна эта технология, могли бы продолжать её использовать.
Total votes 1: ↑1 and ↓0+1
То есть вы так взяли и побежали себе сертификаты покупать, да?
Total votes 2: ↑1 and ↓10
можно купить самый дешевый сертификат — лишь бы браузер принимал.
Проблема не в этом, а в резком росте нагрузки за счет шифрования.
Total votes 1: ↑1 and ↓0+1
А что дешевле — самый дешевый сертификат за 10$ в год, или переписать половину логики приложения?
Total votes 2: ↑2 and ↓0+2
Да на самом деле если кто то сейчас и разрабатывает на веб-сокетах, то, скорее всего, для подстраховки на случай когда они не поддерживаются браузером, имеет или Long Pooling или Flash альтернативу
Total votes 4: ↑3 and ↓1+2
flash альтернатива, как я понял уязвима аналогично
Total votes 2: ↑2 and ↓0+2
Как я понял, IE и не собирался поддерживать WebSockets. А вот как насчет WebKit'овских браузеров (Chrome, Safari, др.)? Они будут выключать WebSockets?
This comment wasn’t rated yet0
Apple и Google, вроде, пока молчат относительно будущих версий и поддержки или неподдержки веб-сокетов.

Представители Microsoft периодически участвуют в дискуссиях по WebSockets и протоколу, но скорее выжидают стабилизации стандарта. Внутри есть понимание, что в целом, это нужная вещь. Но на грабли несовместимостей при реализации наступать как-то не хочется ;)
Total votes 3: ↑3 and ↓0+3
Бля. Ну, ничего, есть пока что Flash Websocket, можно и через него работать.
This comment wasn’t rated yet0
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 уже выпилено. Печаль…
This comment wasn’t rated yet0
about:config -> network.websocket.override-security-block -> true

Выдыхаем и продолжаем свои переднекраевые экзерсисы.
Total votes 1: ↑1 and ↓0+1
хорошо, что есть такая штука, как socket.io.
сменить веб-сокеты, на лонг-поллинг и прочее доисторическое говно можно крайне легко.
Total votes 3: ↑2 and ↓1+1
У меня такое ощущение, что развитие IT-технологий — это вечное переизобретение велосипеда, только каждый раз более грузного и медленного. Изначально существовали обычные TCP-сокеты, которые решали и до сих пор решают поставленную задачу. Вебсокеты — это очередной велосипед, только средствами браузера.
Total votes 2: ↑2 and ↓0+2
Всё-таки зря назвали эту технологию «сокетами», люди путаются. TCP-сокеты и WebSocket — это совсем разные вещи. Примерно как JavaScript и Java.
Total votes 2: ↑2 and ↓0+2
> WebSocket — протокол полнодуплексной двунаправленной связи поверх TCP соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.

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

Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.
Total votes 2: ↑1 and ↓10
Всё смешалось, люди, кони.

HTTP тоже работает поверх TCP, это ещё не повод называть его «сокетом». Я знаю, что такое WebSocket, это не «сокеты».
Total votes 2: ↑2 and ↓0+2
А чем WebSocket, как интерфейс, отличается от, например, TCP Socket?
Так что можно было те же сокеты TCP дооформить до нужного уровня безопасности, и включить в стандартный набор браузера.
Total votes 2: ↑1 and ↓10
Ну это как в анекдоте: «чем отличаются трактор и помидор? Помидор красный, а у трактора дверки наружу открываются».

Чем IPX отличается интерфейсно от TCP? UDP от ICMP? Ваше сравнение примерно того же порядка.
This comment wasn’t rated yet0
Есть такая старая мысль, что всё развивается по спирали.
Total votes 1: ↑1 and ↓0+1
очень расстроен( буквально на них одних я делал ставку в проекте
Total votes 2: ↑1 and ↓10
Сейчас рано делать ставку на эту технологию. Кроме того пройдет немало времени, прежде чем все клиенты будут поддерживать ее. Поэтому лучше использовать оболочку для дуплексных коннекшнов, которая снизу умеет работать как с 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. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time
Change theme settings

Your account

Sections

Information

Services

Support
© 2006–2024, Habr