На недавнем Black Hat была занятная презентация про возможность получения различной информации со сторонних сайтов с помощью простой атаки — Cross Site Scripting Inclusion (XSSI). Если ты читаешь Easy Hack систематически, то, наверное, уже хорошо знаком с Same Origin Policy (SOP), мы к нему часто возвращаемся. Из-за SOP возможность взаимодействия между двумя «сайтами» очень ограничена. Но так как задача получения и оправки информации на одном сайте с другого возникает часто, то были внедрены различные методы для «смягчения» политики и организации взаимодействия. Например, такие, как CORS или crossdomain.xml. Один из более старых методов — подгрузка JavaScript с другого домена через тег <script>. SOP нас здесь ничем не ограничивает: можно указать практически произвольное месторасположение. К примеру, есть хост атакующего evil.ru и сайт жертвы — victim.com. На evil.ru мы можем положить файл HTML и сослаться на любой скрипт у жертвы: <scriptsrc="http://victim.com/any_script_.js"></script> При входе пользователя на сайт атакующего браузер подгрузит и запустит JS с victim.com, но в контексте SOP evil.ru. Это значит, что из JS самого атакующего мы сможем получить доступ к данным (не всем) JS с сервера жертвы. Например, содержимое JS c cайта-жертвы (http://victim.com/any_script_.js): var a ="12345"; Тогда на сайте атакующего мы можем получить значение переменной: <scriptsrc="http://victim.com/any_script_.js"></script><script>console.log(a);</script> Идея работы проста, как алюминиевый чайник. По сути, возможность подгружать с других сайтов статический JS несет в себе не больше проблем для сайта-жертвы, чем погрузка картинки. Проблемы могут возникнуть, когда JS формируется динамически, то есть когда контент JS-скрипта меняется на основании данных из cookie в зависимости от того, какой пользователь к нему обращается. Например, в JS хранится какая-то «критичная» информация: персональные сведения (email, имя пользователя на сайте-жертве) или техническая инфа (анти CSRF-токены). Но, как мы знаем, при подгрузке скрипта через тег <script> браузер пользователя автоматически отправляет cookie пользователя. Сложив эти факты, мы получаем возможность получать информацию о любом пользователе, который зашел на сайт атакующего и при этом залогинен на сайте-жертве. Что же мы можем узнать? Глобальные переменные и результаты работы глобальных функций. К сожалению, доступа к внутренним переменным/функциям нам не получить (хотя, возможно, кто-то найдет способ сделать и это). function test(){return"private data frm function";} Такая атака выглядит возможной, но кажется, что она слишком проста и не должна быть распространенной. Этим и интересна презентация на Black Hat. Исследователи проанализировали 150 популярных сайтов и обнаружили, что в той или иной мере уязвима треть из них. Такая статистика заставляет взглянуть на проблему чуть более пристально. Была выявлена и еще одна закономерность. Content Security Policy становится все более распространенной. Как ты знаешь, с ней мы можем указать, с каких доменов может быть подгружен тот или иной ресурс. Например, можно сказать исполнять JS только с того же ресурса. Кроме того, лучшие практики настройки CSP подразумевают запрет на запуск inline JS (то есть кода, который находится прямо в HTML, а не подгружен из JS-файла). Однако перенос inline в файлы может быть сделан с костылями и на скорую руку — то есть посредством динамически генерируемых скриптов. Так как CSP никак не влияет на XSSI, мы опять-таки можем проводить наши атаки. Вот такая вот bad practice. Источник https://xakep.ru/2015/12/30/easy-hack-xssi/
Нашел такую статейку, на форуме не было на эту тему, поэтому решил запостить. Решил поизучать эту тему и возник вопрос . Если js не идет кк отдельный файл , а находится в теле странички между <script>.... </script> Можно ли его достать таким же спообом ?
В Дании расчленили журналистку на подводной лодке - отрубили голову, руки и ноги, а также пробили легкие, чтобы не всплыла. Бон вояж!!!1
Голову забрал капитан, жопу отдали боцману, низ живота отдали матросам. Жопу боцман тоже потом отдал матросам.
