После прочтения «Веб-сокеты временно устарели» , не удержался и решил ответить.
Итак, последние новости с IT-направления.
Они шокируют. Из-за серьезная неисправленная уязвимость В Adobe Flash все ведущие браузеры отказались от его поддержки.
Да, Flash в сети, увы, больше не будет. Об этом заявили все ведущие бабушки, сидящие на скамейке у меня во дворе.
Из-за серьезная неисправленная уязвимость в Internet Explorer всех версий до 9 все пользователи IE отказываются посещать Интернет. Новый кошмар для верстальщиков — больше не нужно поддерживать версии сайта для разных версий IE. Кошмар! Что делать с полученными навыками? Где есть свободное место для дворника? Из-за серьезная неисправленная уязвимость В Windows все производители браузеров отказываются поддерживать эту платформу.
«Да-да, мы переходим на ReactOS», — подтвердил в эксклюзивном интервью ведущий разработчик ведущего браузера ведущей фирмы на рынке.
Наконец, апофеозом стало заявление руководителя разработки зимних шин «Мышлена».
«Мы проанализировали 1 829 783 ДТП с участием транспортных средств, оборудованных нашими шинами.
И пришли к выводу, что у всех колеса круглые.
Поскольку безопасность вождения для нас превыше всего, мы решили отказаться от круглых колес и перейти на квадратные.
„ Ну давайте пошутим и хватит. Давайте попробуем разобраться.
Прежде всего, статья Адам Барт озаглавлен «Прозрачные прокси: угроза или угрозаЭ» То есть автор исследует не протокол WebSocket, а «прозрачное проксирование».
Что это? Все просто — если клиент явно указал прокси, то это явный прокси.
И если какой-либо запрос браузера (скажем, в каком-нибудь отеле) незаметно перехватывается специальным прокси для фильтрации, то это «прозрачный» прокси.
Проблема (по мнению автора) заключается в следующем.
Прозрачный прокси получил HTTP-запрос.
Поскольку прокси «прозрачен», он перехватывает запрос, направленный от клиента на определенный IP-адрес (сервер).
В этом случае сам HTTP-запрос также может указывать Хост. Похоже, что с логической точки зрения прокси должен отправить запрос туда, куда он направлялся — то есть на исходный IP. Однако, по мнению авторов, некоторые прокси-серверы пересылают HTTP-запрос на IP-адрес, который соответствует хосту в заголовке Host запроса.
Мы не будем пока обсуждать это решение с точки зрения «правильности».
Предположим, что некоторые прозрачные прокси-серверы фактически пересылают запрос хосту в заголовке Host. Что из этого следует? Далее автор ссылается на другое документ .
Предположим, что вредоносный сайт загрузил в браузер Flash-приложение, получившее разрешение на использование raw-сокетов, то есть, проще говоря, Flash-приложение может использовать TCP/IP-соединение с сервером, с которого оно было загружено.
Может ли прозрачный прокси отличить такое соединение от соединения браузера? Не могу.
Если приложение Flash генерирует и отправляет действительный HTTP-запрос на сервер через TCP, прозрачный прокси-сервер будет считать, что запрос отправляет браузер.
Вредоносное Flash-приложение вставит хост в свой вредоносный запрос, который будет указывать на вредоносный хост. А вот если прокси настолько тупой, что пойдет получать ответ на (злонамеренный) хост в поле Хост, то с этого сервера ему подсунут что угодно, и прокси будет считать, что исходный (добрый) хост( на чей это IP-адрес) ответил, что запрос был отправлен изначально).
Получаем две проблемы: 1. вредоносное флеш-приложение теперь может получить доступ к любому веб-серверу, а не только к тому, с которого оно было скачано; 2. если прокси кэширует ответ, то последующие запросы к хорошему серверу от любого клиента будут получать вредоносный кэшированный ответ. Так, проблема компрометации прозрачного прокси-кэша и нарушения его Flash-приложением СОП происходит, когда прозрачный прокси-сервер перенаправляет запрос на хост в заголовке Host (вместо использования IP-адреса, на который был отправлен запрос).
При чем тут Лужков WebSocket? Ничего общего с этим.
Вперед, продолжать.
Давайте заглянем в энциклопедию молодых сурков RFC. нам будет интересно РФК 1919 , который определяет прозрачное проксирование.
Мы читаем: 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.
То есть в стандарте четко указано, что нужно брать IP-адрес запроса, а не из поля Host .
Опять же, похоже, что WebSocket здесь не виноват. Ладно, вернемся к оригинальной статье автора.
Авторы провели эксперимент. Они раздавали рекламный баннер людям, которые пытались реализовать аналогичную схему: отправить HTTP-запрос с «другого» хоста.
Использовались как Flash, так и Java-приложения.
Эксперимент показал, что 2,2% (803 из 36305) запросов с использованием «вредоносного» Flash и 3,6% (1212 из 33820) запросов с использованием «вредоносного» Java-класса перенаправлялись на Host в HTTP-заголовке, а не на IP-адрес.
Далее авторы пытаются «обмануть» прокси с помощью протокола WebSocket. Если прозрачный прокси ничего не знает о WebSocket, то клиент может отправить TCP такое сообщение после рукопожатия WebSocket: GET /sensitive-document HTTP/1.1
Host: victim.com
Поскольку несчастный прокси ничего не знает о WebSocket, он решит, что это просто очередной HTTP-запрос.
Более того, он «зайдет» на сайтжертвы и перенесет ее туда.
Эксперимент авторов показал, что это сделали 2,8% прокси (1376 из 49218).
Далее эксперимент по существу повторялся.
Итак, утверждение о том, что WebSocket небезопасен — неправильный .
Нарушения безопасности происходят потому, что прозрачные прокси не знают WebSocket и нарушают RFC 1919 .
Авторы исследования предлагают свое решение: использовать команду HTTP CONNECT для WebSocket. Их эксперимент показал, что _все_ прозрачные прокси хорошо обрабатывают CONNECT. Они считают, что внутри будут HTTPS-данные и не пытаются их разобрать.
Запросы идут на исходный IP. Подведем итог.
Примерно 3% прозрачных прокси направляют HTTP-запросы на IP-адреса хоста, указанного в поле Host заголовка запроса.
Это нарушение стандарта RFC 1919. Вам необходимо рутировать исходный IP-адрес, на который был отправлен запрос.
Такое поведение позволяет вредоносному Flash-приложению, Java-апплету или сценарию JavaScript получать доступ к любым сайтам (нарушая принцип одинакового происхождения) и подвергать риску кеш этих прокси.
Вредоносный сценарий JavaScript может причинить вред только в том случае, если браузер поддерживает WebSockets. Приложению Flash и апплету Java не требуется поддержка браузером WebSockets, чтобы нанести вред. Переключение на команду CONNECT в рукопожатии WebSocket (с некоторыми изменениями) позволит нам «закрыть дыру» в случае с WebSocket. .
НО ИСПОЛЬЗОВАНИЕ ВРЕДОНОСНЫХ FLASH И JAVA-ПРИЛОЖЕНИЙ ДЛЯ НАРУШЕНИЯ SOP И КОМПЕТЕНТНОСТИ ПРОКСИ-КОМИТЕТА ОСТАЕТ ВОЗМОЖНЫМ, ПОКА ПРОЗРАЧНЫЕ ПРОКСИ НАРУШАЮТ RCF 1919. Картинка для отвлечения внимания.
ПС
Забыл добавить.
Разработчикам Opera и FireFox необходимо понимать, что безопасность должна быть систематической, то есть последовательной.
Если их так беспокоит проблема прозрачных прокси, то надо запретить и Flash, и Java. И это выглядит как дешевый пиар-ход: «Послушайте, мы заботимся о безопасности.
Мы оставили дырявый Flash в нашем браузере, но отключили WebSocket, и теперь вы в безопасности».
P.S.S. Я немного поправил.
Надеюсь, стало еще яснее.
Теги: #websocket #прозрачный #прокси #прокси #все #плохо #или #хорошо #браузеры
-
Либерализм
19 Oct, 24 -
Безопасность Авиаперелетов
19 Oct, 24 -
Современный Найм – Отстой
19 Oct, 24 -
Посвящение Десятилетию Openbravo Pos
19 Oct, 24
