Атака SDRF (Same Domain Request Forgery) не нова и появилась уже лет пять назад. Помнится, я присутствовал на выступлении d0znpp из ONsec’а на Сhaos Constractions 2010 года, тогда и услышал впервые сам термин и познал все радости самой атаки. Надо сказать, что веб-приложений и сайтов, уязвимых к ней, нашлась масса, и они систематически находятся до сих пор.
Несмотря на то что сама она уже описывалась в сети, позволю себе повториться и добавлю немного новых подробностей.
Если говорить без глубоких деталей, то SDRF во многом похожа на всем известную атаку CSRF (Cross Site Request Forgery). Важнейшее различие здесь в том, что при CSRF мы заставляем браузер жертвы отправлять запросы с первичного сайта (на который зашел пользователь) на другой (где и нужно что-то выполнить с правами юзера). Ты зашел на сайт А, а на нем находится код, который заставит твой браузер отправить на сайт Б какой-то запрос.
[ad name=»Responbl»]
Самый важный компонент CSRF — куки при запросе на сайт Б будут подставлены браузером автоматически, а потому запрос будет обработан на сайте Б.
Так вот, SDRF — это аналогичная атака, но проводится она только внутри контекста одного сайта Б. По сути, мы должны впихнуть на сайт Б что-то, что сможет отправлять запросы. Если сравнить с CSRF, роль сайта А здесь играет сайт Б, а роль сайта Б — какой-то исполняемый код. Теоретически если мы можем вставить свой JavaScript- или HTML-код, то это и будет SDRF (ну и по факту также XSS). Но чаще всего SDRF проводится за счет использования сторонних плагинов, поддерживаемых браузером, например Adobe’овских.
Например, если мы можем загрузить на атакуемый сайт PDF’ку (или флешку), то, когда жертва откроет ее в браузере, PDF’ка сможет без какихлибо предупреждений пользователю отправлять на сайт запросы (SOP’у не на что ругаться — все в рамках одного сайта), причем браузер жертвы опять-таки автоматически будет подставлять куки к запросам. Но еще круче то, что, в отличие от CSRF, мы получаем возможность еще и читать ответы на наши запросы. А это дает нам возможность обходить методы защиты от CSRF с помощью токенов, так как мы можем отправить запрос, прочитать
ответ, вынуть из него токен и отправить уже запрос вместе с ним. Ну а раз это все — один домен, то и проверка заголовка Referer не поможет.
Немного об ограничениях. Для проведения атаки нам чаще всего необходима возможность загружать PDF’ки, SWF’ки на атакуемый сайт. Притом важно, чтобы они попадали на тот же домен, который мы атакуем: секьюрная практика говорит нам, что пользовательский контент надо хранить на другом специальном домене (который не содержит ни функционала, ни критичных кук). Второе ограничение возникает, если атакуемый сайт отдает нам наш контент с заголовком Content-Disposition: attachment (или некорректным Content-Type), это указывает браузеру, что файл надо скачать, а не открыть с помощью соответствующего плагина.
[ad name=»Responbl»]
Немного технических аспектов. С флешками все ясно и просто. Функционал для генерации запросов и чтения ответов есть в ActionScript и хорошо документирован. А вот с PDF’ками… В PDF как бы разрешается вставлять яваскрипт, но он живет там в жесткой песочнице, которая систематически меняется, — совсем не гуд. А вот FormCalc — еще один поддерживаемый Adobe язык — позволяет делать необходимое: посылать произвольные GET-/POST-запросы, читать и парсить ответы. Насколько мне известно, эта особенность ничуть не поменялась с 2010 года. Так что пример от d0znpp
все еще должен отлично работать.
Немного новостей. В 2010 году SDRF-атаке (через PDF) были подвержены все браузеры, в которых был установлен плагин от Acrobat Reader, исключение составлял IE. Фишка с ним была в том, что по умолчанию он PDF’ку сначала
скачивал, а потом уже открывал через плагин. То есть открывалась она в другом сайте (локально), и тогда уже вмешивалось SOP, из-за которого перед отправкой запроса PDF’ка запрашивала у пользователя разрешение на него.
Но вот миновали годы, поменялись браузеры и соотношение их использования у пользователей. Кое-что поменялось и с PDF’ками. В браузерах Firefox и Chrome теперь по умолчанию (даже если установлен плагин Acrobat Reader)
для открытия PDF’ок используется специальная JS-либа — PDF.js, то есть сам браузер парсит и отображает PDF’ки. Понятное дело, что FormCalc’ом там и не пахнет, а JS жестко порезан (хотя качество этого дела требует проверки). Зато IE исправился и теперь имеет обычное поведение: при открытии PDF’ок сразу открывает плагин Acrobat Reader’а. Получается, возможность провести атаку уменьшилась в одном месте, но прибавилась в другом (особенно в корпоративном секторе, плотно сидящем на IE).
