На прошедшей конференции Black Hat была обнародована (http://www.kb.cert.org/vuls/id/987798) информация о новом виде атаки BREACH, позволяющей восстановить содержимое отдельных секретных идентификаторов (например, сессионные cookie и CSRF-токены), передаваемых внутри зашифрованного HTTPS-соединения. Метод атаки BREACH практически идентичен представленной в прошлом году атаке CRIME (http://www.opennet.me/opennews/art.shtml?num=34869) (Compression Ratio Info-leak Made Easy), за тем исключением, что атака оперирует особенностью изменения характера потока при сжатии на уровне HTTP, а не при сжатии на уровне TLS/SSL, как в случае с CRIME.Для организации атаки требуется получение контроля за трафиком на промежуточном шлюзе и выполнение на стороне браузера клиента JavaScript-кода злоумышленника (в случае получения контроля над транзитным шлюзом, осуществить подстановку JavaScript-кода в незащищённый трафик не составляет труда). Атака строится на возможности выделения в отслеживаемом зашифрованном трафике блоков данных с метками, отправляемыми подставным JavaScript-кодом на сайт, для которого требуется перехватить идентификационные данные, в рамках общего шифрованного канала связи.
Так как содержимое отправляемых JavaScript-кодом помеченных пакетов известно, за исключением секретного идентификатора, и известен размер всех данных, то путем повторной отправки подставных запросов атакующий может символ за символом угадать содержимое искомых данных, сопоставляя свои попытки изменением размера сжатых данных (восстановление CSRF-токена было продемонстрировано за 30 секунд, потребовав отправки примерно 4000 пробных запросов). Точность восстановления оценивается в 95%.
Если для защиты от CRIME уже повсеместно отключено сжатие на уровне TLS/SSL, то в случае BREACH требуется отключение сжатия gzip/deflate на уровне HTTP. В качестве метода защиты на уровне web-приложений, предлагается случайным образом менять представление секретных идентификаторов при каждом запросе, например, через операцию XOR со случайной маской.URL: http://threatpost.com/breach-compression-attack-steals-https...
Новость: http://www.opennet.me/opennews/art.shtml?num=37614
как хорошо что в последнем firefox убрали опцию "noscript"
«Честному человеку скрывать нечего» ©
"Все врут" ©
> "Все врут" ©Врет ли врун, когда говорит, что он врет?
Рекурсия
> РекурсияНет, всего лишь антиномия.
Нет. Это не рекурсия. Что за манера сводить всё разнообразие проявлений окружающей среды к своему ограниченному лексикону? Это не рекурсия, а логический парадокс. Гурманы, разбирающиеся в сортах парадоксов, назвали бы его антиномией. Сия антиномия, известна как минимум, со времён Древней Греции. Ну и да, к сегодняшнему дню, математика вполне в состоянии справится с этим парадоксом, поэтому называть его парадоксом не совсем корректно. Но, для сельской местности, сойдёт.
автореференция это
Автореферентные высказывания, безусловно, относятся к рекуррентным (возвратным), которые не очень грамотные люди и называют обычно рекурсивными.
Спасибо тебе, что ты есть, мыслящий человек! :)
Уговорил. Доформулирую.
Все лгут, но не всегда.
> Уговорил. Доформулирую.
> Все лгут, но не всегда.Как говорил Капитан Очевидность, "я говорю правду всегда, кроме случаев, когда я лгу".
Цирюльник в деревне занимается тем, что бреет тех людей, которые не бреются сами. Бреет ли он при этом сам себя?
> Цирюльник в деревне занимается тем, что бреет тех людей,
> которые не бреются сами. Бреет ли он при этом сам себя?Оба ответа (противоположных) верны одновременно:
а) Да, он бреется сам.
б) Нет, его бреет цирюльник.
Нет, он вообще не бреется. Потому что автор поста выше забыл указать, что цирюльник бреет _всех_, кто не бреется сам. А без этой детали все становится очень просто (как говорят слесари на автобазе).
Не бреет. Он вообще не бреет бороду.
Не он, а она.
Цирюльник - индеец. У них бороды не растут.
Врет! Врун всегда врет!
всё же не врёт, получается
Расширения ставить религия не позволяет?
> Расширения ставить религия не позволяет?<sarcasm>
Мозилловцы уже обсуждают необходимость выпилить API-функции, требуемые для работы NoScript, ввиду того, что этим расширением пользуется менее 1% народа
</sarcasm>
Ссылочку приведете?
> Ссылочку приведете?Это инсайд.
> Это инсайд.Это жирный троллинг, имхо.
>> Это инсайд.
> Это жирный троллинг, имхо.Увы, нет.
> Мозилловцы уже обсуждают необходимость выпилить API-функции, требуемые для работы NoScript, ввиду того, что этим расширением пользуется менее 1% народатолько ради NoScript сижу на фоксе, неужели???
Интересно какой логикой надо обладать что бы запилить по умолчанию недофаербаг, недопанельку сетевой активности и выкинуть фичи по отрубанию джаваскриптов. С какой радости вот это расширениями нельзя оставить, что это за регилия такая?
«Целостность интерфейса»™ же.
> «Целостность интерфейса»™ же.Кроме того это достаточно глубокое влезание в механику браузера. Расширения... файрбаг прославился тем что вызывает ... уйму БАГОВ в процессе своей работы.
Опыт других браузеров показал что таки как часть браузера это работает лучше. А расширением теперь будет выборочно включаться JS, да. В этом есть некая логика: в core стоит оставить то что надо часто, а что надо редко (задр@чиваются с отключкой JS только продвинутые пользователи) - аддонами.
Обеспечение API для аддонов в core, как правило, гораздо сложнее реализации тех функций, которые вынесены в аддоны.
> В этом есть некая логика: в core стоит оставить то что надо часто, а что надо редко (задр@чиваются с отключкой JS только продвинутые пользователи) - аддонами.Могу ещё раз повторить вопрос и переформулировать его. Вот есть простой пользователь. Есть функции в ядре броузера. Допустим две. Первая предоставлять интерфейс к недофаербагу, вторая - возможность включить/отключить скрипты на сайтах.
Теперь вопрос. У нас простые пользователи каждые второй сайт крутят в фаербаге? Это нужнее чем иметь возможность включить-выключить скрипты на глючных сайтах? Какая тут логика? Особая?
Да не выкидывал фичу, там новость непонятно как писали. Убрали из окошка настроек, оставив в about:config
Большинству не нужно, всё, можно выкидывать.
Пропаганда меньшинства запрещена)
> Пропаганда меньшинства запрещена)Меньшинства-то как раз под защитой. А вот кто защитит большинство от этих самых меньшинств (которых расплодилось, как собак нерезанных)?
>> Пропаганда меньшинства запрещена)
> Меньшинства-то как раз под защитой. А вот кто защитит большинство от этих
> самых меньшинств (которых расплодилось, как собак нерезанных)?Ссыкливое большинство, умеющее только гадить на форумах и мелкопакостить в Манежах, иного недостойно.
> как хорошо что в последнем firefox убрали опцию "noscript"Но при этом добавили опцию, блокирующую выполнение незащищенных скриптов на защищенных страницах, бгг
См. http://www.opennet.me/opennews/art.shtml?num=37609> Включение системы блокирования смешанного контента, предназначенной для защиты пользователей от MITM-атак (man-in-the-middle) и от интеграции прослушивающих вставок на HTTPS-страницы. Начиная с Firefox 23 при наличии на доступной через HTTPS странице обращений к незащищённым HTTP-ресурсам, некоторые виды обращения по HTTP будут блокироваться по умолчанию. Блокироваться будет только активный контент, т.е. незащищённые запросы скриптов.
> как хорошо что в последнем firefox убрали опцию "noscript"Javascript тут не причём.
если предполижить что Javascript отключен -- то туже самую атаку можно сделать через <IFRAME> в сочитании с <META HTTP-EQUIV="REFRESH" ...>
так что прекратите пороть чушь.
если уж хотите глобального_и_радикального решения проблемы.
то нужно запретить HTTP-протокол , и разрешить только HTTPS (с обязательной проверкой сертификата по DANE (DNS-based Authentication of Named Entities)).
а также запретить IFRAME , и вообще все все ресурсы (даже картинки) подгружать только через CORS (Cross-origin resource sharing)...
...а Javascript тут виноват только в последнюю очередь...
> если уж хотите глобального_и_радикального решения проблемы.
> то нужно запретить HTTP-протокол , и разрешить только HTTPS (с обязательной проверкой
> сертификата по DANE (DNS-based Authentication of Named Entities))....после чего соотв. ауторити просто начнут выписку левых сертов и вся эта фигня пойдет лесом, как обычно.
Сам по себе https в его текущем виде защитой является не больше чем бронежилет из картона. Выглядит может и как настоящий, только пули не очень хорошо задерживает.
>> если уж хотите глобального_и_радикального решения проблемы.
>> то нужно запретить HTTP-протокол , и разрешить только HTTPS (с обязательной проверкой
>> сертификата по DANE (DNS-based Authentication of Named Entities)).
> ...после чего соотв. ауторити просто начнут выписку левых сертов и вся эта
> фигня пойдет лесом, как обычно.ды ауторити пусть хоть обвыписываются своими левыми сертифкатами, но всё равно это не будет иметь приоритета перед DANE.
в случае если есть хотя бы ОДНА ошибка в двух проверках (DANE или ауторити) -- сайт уже считается скомпрометированным и НЕ будет открыватсья в www-браузере.
(так написанно на wiki-страничке от Мозилки)
> не будет иметь приоритета перед DANE.Поэтому MITM просто поставит свой DNS сервер без этой байды посередине. Поскольку сайтов которые так не умеют будет много и еще долгие годы, типовой хомяк просто не замтит что ему DNS немного заменили. На иной, который так не умеет. Что как бы нормальная ситуация - ведь полинтернета тоже это не умеет.
>> передаваемых внутри зашифрованного HTTPS-соединения
> запретить HTTP-протокол , и разрешить только HTTPSперепутал?
> туже самую атаку можно сделать через <IFRAME>
ту же самую атаку можно будет сделать всегда, если клиент (браузер, плеер, хз-что) будет иметь возможность отправлять запрос через скомпрометированный гейт без участия юзера. Вне зависимости от протокола (НТТР/S, SPDY, FUCK и т.д.) и содержания страницы (HTML4/5, iframe, flash, jpg -- кстати жпеги тоже "ломали").
> если уж хотите глобального_и_радикального решения проблемы
> запретить IFRAME , и вообще все все ресурсыможет сразу запретить весь интернет.
> прекратите пороть чушь
> юзера. Вне зависимости от протоколаВот это не обязательно, кстати. Если на уровне протокола предусмотреть некий padding данных, с рандомизацией размера и прочая - MITM таки *будет* в этом случае чертыхаться.
IFRAME NoScript тоже умеет блочить. Это расширение вообще очень мощная штука для безопасности, рекомендую посмотреть.
убрали и павильно. Если бы можно было для определенныз сацтов разрешать это одно, а как там оно все равно бесполездно.
Кому надо отключит через эбоут:конфиг или расширением носкрипт.
Б-ть, не печатайте на опеннет с тетрисов.
> как хорошо что в последнем firefox убрали опцию "noscript"Поэтому есть аддон NoScript, который куда более разумно поступает - позволяет выборочно разрешить JS тем сайтам которые нужны и без него не работают.
Ох уж этот жабакод злоумышленника
Не понял - а что, так сложно не позволять исполнять незащищенный JS на защищенной странице?
> Не понял - а что, так сложно не позволять исполнять незащищенный JS на защищенной странице?например заходишь ты на
и сервер тебя переадресовывает на
но это происходит в НОРМАЛЬНОМ случае..
..а в случае атаки:
ты заходишь на
и тут включается CRIME-скрипт (или как его там?) ВМЕСТО переадесации на
# P.S.: стоит ли говорить про http-закоговок ---- HTTP Strict Transport Security (?) , который уже не позволит второй раз зайти на http если ты уже бывал хоть раз на https. так-что Firefox можно сказать УЖЕ на 99% защищён от этой фигни , если разработчик сайта вспомнил про "HTTP Strict Transport Security" . а если разработчик не вспомнил про этот заголовок -- то Firefox тоже защищён (но менее чем на 99%) :)
а ежели сразу на https:// заходить, тогда, выходит, атака невозможно?
не лучше ль тогда сварганить плагин, меняющий где только можно http на https?
Уже есть такой. См. eff.org/https-everywhere
> не вспомнил про этот заголовок -- то Firefox тоже защищён (но менее чем на 99%) :)Свежий лис не грузит не-HTTPS контент на HTTPS страницах по умолчанию.
Ага, дошло. Ну да, можно же через формы или ифреймы дергать раз за разом HTTPS-адрес с разными параметрами...
> ...можно же через формы или ифреймы дергать раз
> за разом HTTPS-адрес с разными параметрами...верно! :)
Нужно больше песочниц.
> Не понял - а что, так сложно не позволять исполнять незащищенный JS
> на защищенной странице?Свежий 23-й лис кстати так и сделает - матюкнется что не шифрованный контент на шифрованной странице и не будет его вгружать.
Если есть "выполнение на стороне браузера клиента JavaScript-кода злоумышленника", то зачем всё остальное?
>В качестве метода защиты на уровне web-приложений, предлагается случайным образом менять представление секретных идентификаторов при каждом запросе, например, через операцию XOR со случайной маской.костыли! причём кривые
Подскажите плиз, если у апача отключить mod_deflate и mod_gzip, то эксплуатация будет невозможна????
хотел сказать, "эксплуатация уязвимости будет невозможна?"
очень понравился лаконичный ответ Игоря Сысоева"gzip off" от SSL-enabled sites.
--
Igor Sysoev
> "gzip off" от SSL-enabled sites.Только у SSL еще встроенное сжатие zlib есть. Это как раз соседняя атака. Сколько там еще костылей надо поставить, ась?
в nginx сжатие на уровне openssl давно отключено
>> "gzip off" от SSL-enabled sites.Бред сивой кобыли
gzip относиться только к модулю (HTTP)
>>> "gzip off" от SSL-enabled sites.
> Бред сивой кобыли
> gzip относиться только к модулю (HTTP)директива работает на любом блоке server {} втч и в случае listen 443 ssl;
и да, нам как раз и нужно отключить сжатие на уровне http
if ( $scheme = "https" ) { gzip off }