0,0
рейтинг
10 декабря 2010 в 00:22

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

Ровно год назад, 9 декабря 2009, разработчики Google Chrome взбудоражили общественность, объявив внедрение поддержки веб-сокетов в будущих версиях Chrome. О том, что такое Web Sockets и что это дает, см. почти годовалый пост на хабре.

Веб-сокеты — это, действительно, вкусно.

С точки зрения веб-стандартов, Web Sockets — это отдельная спецификация, вынесенная из спецификации HTML5 еще весной 2009 для дальнейшей проработки внутри рабочей группы по веб-приложениям (WebApps WG). В настоящий момент документ находится в состоянии Working Draft.

Интересной особенность веб-сокетов является то, что это не просто API в браузере: механизм работы веб-сокетов завязывается на соответствующий протокол — WebSocket Protocol, разрабатываемый в рамках IETF, и требует соответствующей поддержки со стороны сервера. Текущая редакция драфта – 03 (17 октября), до этого было еще 76 ревизий. С последней в начале лета была неприятная история, когда новая ревизия оказалась несовместимой со старой.

Поддержка веб-сокетов была заявлена в Chrome и Safari, а также, насколько я понимаю, должна была быть доступна в предварительных версиях Opera 10.70-11 и Firefox 4b. (Ок, очевидно, что IE9 в этом списке нет, однако, справедливости ради: разработчики не раз заявляли, что в первую очередь внедряют стабильные и устояшиеся вещи, которые не приведут к обратным несовместимостям через несколько месяцев.)

Протокол, равно как и стандарт, все еще дорабатывается. И на самом деле хорошо, что его вынесли из HTML5, так как это позволяет отдельно прорабатывать и стабилизировать независимые куски, а не смешивать в одну кучу разметку и API для веб-приложений на JavaScript.

Что же произошло?


В конце ноября Adam Barth опубликовал результаты исследования надежности используемого протокола. Выяснилось, что сам используемый протокол подвержен серьезным уязвимостям:

The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies.

We found that for a $100, we were able to poison the cache of 8 users by using the Upgrade-based handshake. When the attacker is able to poison the proxy's cache in this way, the attacker can exploit /every/ user of the cache, with potentially dangerous consequences. For example, the attacker can poison the proxy's cache entry for http://www.google-analytics.com/ga.js and inject JavaScript into approximately 57% of the top 10,000 web sites.




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

Подробнее см. тут http://www.adambarth.com/experimental/websocket.pdf

Очевидно, что протокол будет дорабатываться и сейчас в списке рассылки можно наблюдать довольно бурное обсуждение.

Вскрытая проблема оказалась довольно серьезной для того, чтобы разработчики Firefox и Opera объявили, что до устранения проблем в будущих версиях их браузеров поддержка веб-сокетов будет закрыта. В Firefox поддержка будет закрыта, начиная с версии FF4b8. Комментарий от Opera см. тут.

Что это означает для разработчиков?


На текущий момент и до устранения проблем с протоколом — это обратная несовместимость новых версий. То есть с выходом обновлений браузеров, текущие решения на WebSocket просто перестанут работать. Подвох еще заключается в том, что хотя разрабатываемый стандарт и соответствующий протокол находятся только в черновой редакции, с точки зрения внедрения и поддержки в браузерах, он не обозначен как экспериментальный и с большой вероятностью подлежащий изменениям и в то же время активно продвигается.

Впрочем, хочется надеяться, что если вы использовали веб-сокеты, вы делали проверку поддержки функциональности (feature detection) и у вас была ветка на случай отсутствия свойства window.WebSocket.

Важно подчеркнуть, что это не проблема браузеров, а именно используемого протокола. И, кстати, уязвимости в нем также затрагивают Java и Flash, поэтому ждем, будет ли реакция от Oracle и Adobe.

p.s. На злобу дня — небольшой ролик по цитатам из блогов Google и Firefox.
Константин Кичинский @kichik
карма
114,9
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (48)

  • –30
    ну это еще один повод советовать пользователям хром уже сейчас. И пусть остальные себе копошаться. Юзерам надо плюшки, уже сейчас возможные только сокетами, а не пространные рассуждения о возможных атаках
    • +10
      какой смысл использовать нестандартное уязвимое решение, которое гарантированно будет пересмотрено?
      • 0
        Для внутренних решений, не передавая «сверхсекретные» данные по websocket-ам. Очень даже.
    • +2
      А какие есть уже работающие «плюшки» на вебсокетах?
    • +6
      «Буратино был тупой.»
  • +3
    Блин, я уж игруху почти написал с этой технологией, во меня подставили.
    • +1
      Вот уж действительно, у нас тоже проект на вебсокетах в разработке. Надеюсь, проблему быстро устранят. Протокол-то хороший.
    • +2
      Пользуясь вот такими претендентами на стандарт вы сами себя подставляете. Это все равно что пользоваться рабочими сборками программ и жаловаться на их нестабильность…
      • +1
        а каким другим способом обеспечить постоянный реалтайм в браузере?
        • +1
          А как делали до появления веб-сокетов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          Чем IPX отличается интерфейсно от TCP? UDP от ICMP? Ваше сравнение примерно того же порядка.
    • +1
      Есть такая старая мысль, что всё развивается по спирали.
  • 0
    очень расстроен( буквально на них одних я делал ставку в проекте
  • 0
    Сейчас рано делать ставку на эту технологию. Кроме того пройдет немало времени, прежде чем все клиенты будут поддерживать ее. Поэтому лучше использовать оболочку для дуплексных коннекшнов, которая снизу умеет работать как с 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. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.

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