Комментарии 13
а нельзя ли просто фишить то что нужно, имея возможность оперировать «траффиком» пользователя?
-1
По материалам Positive Hack Days.То-то чувство дежавю меня не покидало во время чтения -)
Атака занятная, хотя и довольно трудоемкая. Самое трудное — выяснить, собственно, ip-адрес цели атаки.
+2
Надо же как интересно… а мне казалось что у всех людей, которые не хотят чтобы их локалку взломали хакеры, давно стоит JS block, не говоря уже о том что адрес этой самой локалки не имеет ничего общего с 192.168.0.0/24. Интересно кто наивнее — я или хакеры?
-7
прочитал, не понял, каким боком тут влияет default vhost?
кроме того, просто удалить _default_:80 в апаче не поможет — тогда по умолчанию станет отвечать первый определённый vhost, он будет работать как default и отвечать на все запросы, на которые не нашлось более подходящего vhostа
кроме того, просто удалить _default_:80 в апаче не поможет — тогда по умолчанию станет отвечать первый определённый vhost, он будет работать как default и отвечать на все запросы, на которые не нашлось более подходящего vhostа
+1
Я тоже прочитал и думаю, часть «Защита» написана для «галочки» и приданию статье литературной полноты
0
Формально Вы правы, но по сути это вопрос настройки веб-сервера и его фич: сервер должен обрабатывать заголовок Host определённым образом, тогда эта атака становится невозможной.
Например, в том же апаче mod_vhost_alias позволяет связать значение заголовка Host с путём к каталогу, где находится веб-сайт. В результате попытка обратиться с левым Host приведёт к поиску соответствующего веб-сайта в несуществующем каталоге и возврате ошибки 404, и никакого «default vhost» в такой конфигурации уже нет в принципе.
Например, в том же апаче mod_vhost_alias позволяет связать значение заголовка Host с путём к каталогу, где находится веб-сайт. В результате попытка обратиться с левым Host приведёт к поиску соответствующего веб-сайта в несуществующем каталоге и возврате ошибки 404, и никакого «default vhost» в такой конфигурации уже нет в принципе.
0
Интересно, но тяжеловато читать описание атаки. Возможно, из-за того, что слова типа «наши», «их» — создают путаницу. Имена собственные, вроде Алисы с Бобом были бы понагляднее.
Ну и основной смысл статьи в том можно было бы выразить в одной фразе: «если вы открыли страничку porno.example.com, то это ещё не значит, что javascript на этой странице не работает с веб-админкой вашего домашнего роутера с теми же самыми привилегиями, как если бы вы открыли саму эту админку».
Ну и основной смысл статьи в том можно было бы выразить в одной фразе: «если вы открыли страничку porno.example.com, то это ещё не значит, что javascript на этой странице не работает с веб-админкой вашего домашнего роутера с теми же самыми привилегиями, как если бы вы открыли саму эту админку».
+3
Прошло несколько лет, и эту уязвимость закрыли. Современные версии браузеров (даже IE8) теперь всегда для ссылок программно отдают цвет по умолчанию, даже если ранее ссылка была посещена. Впрочем, эту уязвимость все равно можно реализовать по-новому.
Спасибо и за эту наводку! :))
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вторая жизнь DNS Rebinding. Свежий подход к реализации атак Anti DNS pinning