Как получить данные через Cross site scripting inclusion.

На недавнем Black Hat была занятная презентация про возможность получения различной информации со сторонних сайтов с помощью простой атаки — Cross Site Scripting Inclusion (XSSI).

Если ты читаешь наш сайт систематически, то, наверное, уже хорошо зна- ком с Same Origin Policy (SOP), мы к нему часто возвращаемся. Из-за SOP возможность взаимодействия между двумя «сайтами» очень ограничена. Но так как задача получения и оправки информации на одном сайте с другого возникает часто, то были внедрены различные методы для «смягчения» политики и организации взаимодействия. Например, такие, как CORS или crossdomain. xml. Один из более старых методов — подгрузка JavaScript с другого домена через тег < script >. SOP нас здесь ничем не ограничивает: можно указать практически произвольное месторасположение.

К примеру, есть хост атакующего evil.ru и сайт жертвы — victim.com. На evil. ru мы можем положить файл HTML и сослаться на любой скрипт у жертвы:

При входе пользователя на сайт атакующего браузер подгрузит и запустит JS с victim.com, но в контексте SOP evil.ru. Это значит, что из JS самого атакующего мы сможем получить доступ к данным (не всем) JS с сервера жертвы.

Например, содержимое JS c cайта жертвы (http://victim.com/any_script_.js):

 

Тогда на сайте атакующего мы можем получить значение переменной:

Идея работы проста, как алюминиевый чайник.
По сути, возможность подгружать с других сайтов статический JS несет в себе не больше проблем для сайта-жертвы, чем погрузка картинки. Проблемы могут возникнуть, когда JS формируется динамически, то есть когда контент JS-скрипта меняется на основании данных из cookie в зависимости от того, какой пользователь к нему обращается. Например, в JS хранится какая-то «критичная» информация: персональные сведения (email, имя пользователя на сайте-жертве) или техническая инфа (анти CSRF-токены).

Но, как мы знаем, при подгрузке скрипта через тег <script> браузер пользователя автоматически отправляет cookie пользователя. Сложив эти факты, мы получаем возможность получать информацию о любом пользователе, который зашел на сайт атакующего и при этом залогинен на сайте-жертве.

Что же мы можем узнать? Глобальные переменные и результаты работы глобальных функций. К сожалению, доступа к внутренним переменным/функциям нам не получить (хотя, возможно, кто-то найдет способ сделать и это).

Такая атака выглядит возможной, но кажется, что она слишком проста и не должна быть распространенной. Этим и интересна презентация на Black Hat. Исследователи проанализировали 150 популярных сайтов и обнаружили, что в той или иной мере уязвима треть из них. Такая статистика заставляет взглянуть на проблему чуть более пристально.

Была выявлена и еще одна закономерность. Content Security Policy становится все более распространенной. Как ты знаешь, с ней мы можем указать, с каких доменов может быть подгружен тот или иной ресурс. Например, можно сказать исполнять JS только с того же ресурса. Кроме того, лучшие практики настройки CSP подразумевают запрет на запуск inline JS (то есть кода, который находится прямо в HTML, а не подгружен из JS-файла).

Однако перенос inline в файлы может быть сделан с костылями и на скорую руку — то есть посредством динамически генерируемых скриптов. Так как CSP никак не влияет на XSSI, мы опять таки можем проводить наши атаки. Вот такая вот bad practice.