----8<----
----8<----
Загрузка...
----8<----
Наташа, 25 лет
Анна, 17 лет
Нина, 29 лет
Светлана, 25 лет
Ангел, 20 лет
Алинка, 18 лет
Алёна, 26 лет
----8<----
----8<----
|
tshram.net tshram.com molekyla.kiev.ua molekyla.boom.ru shramenko.kiev.ua sexpartner.kiev.ua |
----8<----
Cross Domain Scripting
Введение. Идея написать данную статью мне пришла в голову позже того, как понадобилось дать одному новичку ссылку на подробное также понятное пояснение этого термина. Полазив по поисковикам, мы с удивлением обнаружил, что найти такую статью достаточно непросто. Термин или никак не объяснялся общий, или в пары словах также по-английски:). Между тем в Windows уязвимости такого типа обнаруживаются достаточно зачастую также они более чем серьёзны! Поэтому в этой статье мы попытался как разрешено подробнее также понятнее описать этот тип атак, особенности эксплуатации данного типа уязвимостей также охраны от них, привести конкретные примеры. Статья писалась в основном, несомненно, для новичков, но, уповаю, станет чем-то полезна также для более опытных читателей. Что такое Cross Domain Scripting? Изначально Cross-Domain Scripting (CDS) был связан с недостатками в модели безопасности всем известного «ослика» aka Internet Explorer (IE). Однако, т.к. архитектурные особенности современных браузеров никак не здорово отличаются приятель от приятеля, то атакам данного типа в настоящее пора подвержены почти что все известные веб-браузеры. Тем никак не менее, существующие отличия между программами этого класса приводят к тому, что чаще всего найденный CDS является «браузерозависимым», т.е., например, трудится на IE, но никак не трудится на Opera либо наоборот. В основе уязвимостей типа CDS лежит понятие «домена». В данном контексте смысл этого понятия несколько отличается от общепринятого. «Домен» - это уже никак не просто адрес сайта в Интернете, также даже никак не «область пространства иерархических имен сети Интернет», - данное понятие означает некоторую «границу безопасности» (security boundary), уходить за которую никак не разрешено ни одному пользовательскому скрипту. В основе модели безопасности всякого веб-браузера лежит тот принцип, что ресурсы различных доменов (странички, скрипты также т.д.) никак не могут никоим образом пересекаться приятель с ином, т.е. приобретать доступ к внутреннему содержимому также данным приятель друга. Ежели бы это было возможно, то, например, скрипт на домашней страничке юного хакера Васи мог бы получить доступ к данным почтового ящика на Mail.Ru ничто никак не подозревающего пользователя, которого Вася заманил на свою страничку. Вот было бы веселье:)! Более того, согласно архитектуре Windows также концепциям построения современных браузеров, всякий сетевой ресурс в локальной сети также собственная файловая система заказчика это также «домены», но значит к ним возможно обращение из скриптов точно так же, как к всякому ресурсу в Интернете! Собственно именно локальная файловая система заказчика также является чаще всего целью cross-domain атак. В также пора взаимодействие между собой ресурсов (страничек также скриптов) внутри домена (и всех его субдоменов!) концепцией безопасности Microsoft разрешено также в принципе никоим образом никак не ограничено. Трудно обсуждать правильно это либо нет, но то, что так проще:) также при этом расширяются возможности веб-серфинга, - это точно. Так что бла бла такое Cross-Domain Scripting? В контексте всего вышесказанного этот термин разрешено перевести как – «междоменный скриптинг», т.е. «пересечение скриптом границ домена» - нарушение той заветной черты безопасности, выход за которую отчуждает доступ к данным других доменов, в том числе к локальной файловой системе клиента. Такое нарушение чаще всего сопровождается возможностью записывать также выполнять произвольный HTML также Java код в контексте других доменов, произносить данные других доменов (например, формы с паролями либо файлы на системе клиента) также даже выполнять произвольные команды на удаленном компьютере. Часто понятие «cross-domain scripting» подменяют понятием «cross site scripting» (XSS). Действительно, зачастую бывает, что наружные проявления этих уязвимостей весьма похожи, - особенно, в какое время в результате CDS проистекает вставка Java-кода в контекст иного домена. Однако, несмотря на подобие, сущность этих уязвимостей различна: Во-первых, округ действия XSS по определению ограничена одним доменом. В то время, как CDS в общем случае подвержены все домены + локальная файловая система клиента. Во-вторых, повод XSS уязвимостей кроется в ошибках скриптов, расположенных на сервере, плюс, как положение, заключается в недостаточной фильтрации данных, полученных от пользователя. Родник CDS уязвимостей – клиентское программное обеспечение (браузер также операционная система), также он обычно никоим образом никак не связан с пользовательскими данными. Ну также никак не надобно забывать, что уровень риска от успешной эксплуатации злоумышленником XSS намного ниже, чем от CDS. Ведь в главном случае, как максимум, произойдет утечка конфиденциальных данных пользователя (пароли также т.д.), причем лишь только с одного сайта, но при CDS возможно похищение конфиденциальный данных с любых сайтов, но зачастую также исполнение произвольных команд на системе клиента, что позволяет взять над ней наполненный контроль. Подробнее об XSS разрешено чтить Antichat.Ru. Как это работает? Так почему бла бла делается посильным этот тип атак? Причина заключается в том, что та самая «линия безопасности» между доменами создается искусственно, что всю работу по предотвращению междоменного скриптинга выполняет веб-браузер также его компоненты – нет архитектурных ограничений. А значит, прктически всегда кушать вероятность погрешности в процедурах проверки, возможность их обойти, что в настоящее пора с успехом также делается. За более чем десятилетнюю летопись использования веб-браузеров было найдено множество способов преодолеть заветную границу домена. Но большая часть из них разрешено условно разделить на пара класса: 1.Эксплуатация ошибок безопасности в объектно-ориентированной модели браузеров; 2.Использование промежуточного звена для выполнения атаки. Рассмотрим подробнее данные классы атак. В основе главного лежит ярко выраженная объектно-ориентированная архитектура современных браузеров также виртуальной машины Java. Действительно, все, что мы наблюдаем на экране веб-браузера, это объекты определенных классов с их свойствами, событиями также методами. Используя данную объектно-ориентированную модель также скрипты Java, мы можем обращаться к всякому элементу загруженной в браузер странички, произносить также записывать в неё данные, вскрывать новые окна также т.д. Более того, с помощью скриптов возможно частичное управление элементами самого веб-браузера также даже действиями пользователя: перемещение «Вперед»/«Назад» по страничкам, прибавление в «Избранное» также т.п. Все же отдельные окна либо элементы странички в веб-браузере могут принадлежать различным доменам, но значит нужно пресекать обращение к ним. Невозможно допустить, дабы пользовательский скрипт, открыв иной домен в новоиспеченом окне браузера, имел возможность что-либо записать туда либо вычислять оттуда. Невозможно допустить, дабы скрипт на страничке с фреймом, куда подгружен ресурс с иного домена, смог обращаться к этому фрейму также приобретать доступ к его данным. Более того, утечка данных от одного домена к иному возможна никак не только чрез свойства, но также чрез методы также события объектов! Скажем скрипт на страничке юного хакера Васи, куда он заманил ничто никак не подозревающего пользователя, никак не вынужден «знать» какие клавиши тот нажимает, в какое время вводит пароль для входа в Mail.Ru, открытый в приятелем окне браузера. Ну также таких примеров разрешено привести весьма немало! К сожалению, но может также к счастью;), такие проверки безопасности зачастую выполняются некорректно, но иной раз также отсутствуют совсем! Поэтому делается посильным обращаться к элементам страничек с других доменов, считывать из них данные, записывать свой Java код в контекст других доменов также т.д. Из-за достаточно сложной архитектуры объектно-ориентированной модели такие «дырки» в ней находятся достаточно часто. Ниже приведен образец данного класса атак (Пример 1). Для выполнения атак другого класса используется некоторое промежуточное звено. Что действовать, в какое время прямое обращение к иному домену запрещено? Правильно! Двигаться в обход! А внезапно кушать кто-то иди что-то, кому это обращение никак не запрещено, также оно сможет вычислять оттуда данные также передать нам, либо навыворот – записать наши данные в контекст иного домена. Наиболее уязвимой с этой точки зрения оказывается технология ActiveX от Microsoft. Технология ActiveX предоставляет в распоряжение пользователя объекты, их свойства также методы, которые используются операционной системой для каких-либо вспомогательных целей. Например, для просмотра чрез веб-браузер файлов справки Windows (*.chm) используется HTML Help ActiveX компонент. Не правда ли удобно? Но зачастую объекты ActiveX выполняют роль своего рода «троянских коней»! Занятие в том, что существует средство управлять этими компонентами (загружать, обращаться к их свойствам также методам) чрез веб-страничку. Для этого используется тег . А ведь зачастую данные ActiveX объекты содержат методы манипуляций с файловой системой, запуска приложений, навигации по веб-страницам также т.д. Т.о. появляется возможность извне производить все данные действия также более того осуществлять полноценный обмен данными с жертвой! Например, произносить содержимое локальных файлов заказчика также отправлять назад скрипту данные данные, либо с помощью ActiveX объекта вскрывать иной домен также записывать в его контекст свой Java код. Именно с помощью данного класса атак иной раз удается добиться выполнения произвольного кода (запуска cmd.exe с нужными параметрами) на системе клиента. В настоящее пора этот тип CDS схоже широко распространен также безостановочно находят новые уязвимые ActiveX объекты. Ниже приведен образец такой уязвимости (Пример 2). Помимо рассмотренных классов CDS существуют также другие способы обхода междоменных ограничений. Правда, зачастую данные способы являются очень экзотическими также встречаются нечасто. Например, обнаруженная в июле 2004 года Cross-Cookie уязвимость (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Она позволяла при определенных условиях приобретать доступ (читать/записывать) к кукам других доменов. Причем это был один из немногих случаев, в какое время уязвимыми оказались многие браузеры: IE, Mozilla, Opera, Konqueror. Т.о. CDS является в настоящее пора весьма распространенным типом атак также безостановочно обнаруживаются новые способы эксплуатации этих уязвимостей («вектора атак»). Примеры CDS Чтобы все описанное выше было понятней – рассмотрим двух примеров реальных CDS уязвимостей. Все они были найдены в Internet Explorer также позволяют вставлять свой Java код в контекст других доменов. Обычно это используется для хищения кукисов либо выполнения произвольных действий в рамках текущей сессии пользователя. Пример 1. Similar Method Name Redirection Cross Domain Vulnerability – CAN-2004-0727 (MS04-038) Эта уязвимость была обнаружена в июле 2004 года также связана погрешностью безопасности в объектно-ориентированной модели IE (1-ый класс CDS уязвимостей из рассмотренных выше). Суть её в следующем. Как известно, дабы загрузить в текущее окно браузера другую страницу (возможно из иного домена), разрешено использовать свойство location.href либо метод location.assign(). Однако, позже загрузки требуемой страницы дальнейшее исполнение Java кода текущего скрипта нельзя – другим образом скрипт мог бы подгрузить Mail.Ru также выполнить в контексте этого домена произвольные действия. Но оказалось посильным обойти это ограничение маршрутом редиректа (перенаправления) метода location.assign() на точно такой же, но иного окна (ведь у нас объектно-ориентированная модель также мы можем присваивать методы различных объектов приятель другу). В результате появилась возможность выполнять Java код в контексте текущего окна, но уже позже загрузки требуемой странички – что также требовалось! Последующий скрипт выполняет требуемые действия: w=window.open("jаvascript:setInterval(function(){try{x=opener.location.href;}catch(e){location.assign('jаvascript:alert(document.cookie)');window.close();}},100)"); w.location.assign=location.assign; location.href="/click?http://localhost"; Вначале раскрывается новое окно, которое в цикле медлит загрузки странички (в нашем случае с localhost) в главное(текущее) окно. Тем временем скрипт переназначает методы location.assign() также затевает загрузку в суть окно требуемой страницы (localhost). Как только загрузка заканчивается, в цикле новоиспеченого окна срабатывает триггер, методом assign() вставляется Jаva код (из-за переназначения методов вставка проистекает в контекст первого окна) также новое окно тут бла бла закрывается. В результате выполнения скрипта в контексте localhost исполняется dоcument.cookie. Видимо разработчики Microsoft никак не предусмотрели возможность редиректа функций также никак не вставили проверку безопасности (или вставили некорректно) в данное событие. Для эксплуатации этой уязвимости необходимо, дабы в браузере был разрешен Active scripting. Почитать подробнее об этой уязвимости также найти рабочий образец эксплойта вы можете тут: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm. Пример 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN-2004-1319 (MS05-013) Данная уязвимость была обнаружена в конце прошлого года, но исправлена лишь только в феврале. Она относится ко 2-ому типу CDS атак из рассмотренных выше, т.е. использует промежуточное звено (DHTML ActiveX) для проведения атаки. Для успешной эксплуатации уязвимости необходимо выполнить следующую последовательность действий: 1.Загрузить DHTML ActiveX. Это делается при подмоги тега . 2.Загрузить в ActiveX объект нужную нам страницу (произвольный домен). Это делается маршрутом выполнения в контексте DHTML ActiveX нашего скрипта. exploit.DOM.Sсript.execSсript("window.name="new";open("http://localhost","new");"); 3.Ну но позже этого уже разрешено вставлять наш HTML также Java код. Он станет выполняться в контексте загруженного домена. Все просто вплоть до безобразия:)! exploit.DOM.Sсript.execSсript("alert(document.cookie)"); Каковы бла бла повода этой уязвимости? Я бы выделил их две: Во-первых, возможность извне выполнять произвольные скрипты внутри ActiveX объекта – на мой взор, это чрезвычайно внушительная вольность! Во-вторых, при загрузке страницы в DHTML ActiveX туда загружается ВСЁ – даже кукисы! Вопрос: зачем? Данный ActiveX объект может использоваться для редактирования страниц также зачем там нужны кукисы – непонятно… Естественно, для эксплуатации этой уязвимости необходимо, дабы в браузере было разрешено выполнение ActiveX. Почитать подробнее об этой уязвимости также найти рабочий образец эксплойта вы можете тут: http://greyhatsecurity.org/abusiveparent-discussion.htm. Как защититься? Защититься от междоменного скриптинга никак не так просто. Т.к. варианты эксплуатации («вектора атак») этих уязвимостей весьма разнообразны, то большая часть мер будут владеть очень ограниченный также мимолетный нрав. Перекрыть все «вектора атак» почти что невозможно. Поэтому мы дам несколько рекомендаций, которые способны лишь только снизить риск успешной атаки, но никак не защитить полностью. 1.Соблюдение бережности при веб-серфинге. Для успешного выполнения приблизительно всех разновидностей CDS необходимо вначале заманить ничто никак не подозревающего пользователя на страницу-эксплойт, позже чего он подвергнется этой атаке. Невозможно доверять ссылкам, как бы невзначай, подкинутым в диалоге, различным «домашним страницам» также т.п. Это наверное первая рекомендация из всех. К сожалению грамотно примененная XSS может перечеркнуть всю бережность. 2.Оперативная установка заплаток для операционной системы также браузера. Обычно для всех опубликованных в Интернете уязвимостей производитель (даже Microsoft:)) в короткие сроки выпускает корректирование (заплатку). Оно защитит от этой конкретной уязвимости, но никак не от других, еще никак не найденныхJ (или найденных, но никак не приданных огласке). Естественно, рассмотренные в примерах уязвимости уже давным-давно исправлены Microsoft, также кто захотел, тот уже позаботился о своей безопасности. 3.Отключение в браузере ActiveX также Active Scripting. Эта мерка сделает невозможным запуск в бразере ActiveX также выполнение Java либо VBS скриптов. Это истинно сделает неэффективными большая часть CDS атак, правда может существенно отразиться на функциональности посещаемых сайтов. Но никак не прктически всегда CDS для успешной атаки требует поддержки от браузера ActiveX либо Active Scripting – также это никак не панацея от всех бед! 4.Работа в Интернете только с ограниченными правами. Выполнение этой рекомендации позволит, даже в случае успешной атаки, снизить посильный ущерб от неё. Как известно браузер (а значит также все скрипты в нем) запускается с правами текущего пользователя. Не дайте хакеру Васе получить cmd.exe с правами Администратора:)! Следование всем этим рекомендациям поможет стать трудноуязвимым для Cross-Domain Scripting!  |
----8<----
|
|