Безопасный JavaScript, работающий на сторонних сайтах

У нас есть «виджет», который работает на сторонних веб-сайтах, то есть на всех, кто регистрируется в нашем сервисе и внедряет JavaScript.

На данный момент мы используем JSONP для всего общения. Мы можем безопасно входить в систему и создавать учетные записи с помощью iFrame и некоторой магии с обнаружением событий загрузки на нем. (По сути, мы ждем, пока источник iFrames не укажет обратно на клиентский домен, прежде чем считывать значение успеха из его заголовка).

Поскольку мы работаем на JSONP, мы можем использовать файлы cookie HTTP браузера, чтобы определить, вошел ли пользователь в систему.

Однако мы находимся в процессе перевода нашей системы на работу в реальном времени и через веб-сокеты. У нас по-прежнему будет тот же метод аутентификации, но мы не обязательно будем совершать другие вызовы с использованием JSONP. Вместо этого эти вызовы будут выполняться через веб-сокеты (с использованием библиотеки Faye).

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

Лучше ли мне, чтобы мои безопасные действия выполнялись через обычный JSONP, а мои обновления — через WebSockets?


person Samuel    schedule 20.02.2012    source источник


Ответы (2)


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

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

В любом случае сторонняя организация, имеющая уязвимость XSS, также будет очень большая проблема, но, вероятно, вы уже это знаете.

person tjdett    schedule 21.02.2012

Отправляются ли вам файлы cookie во время открытия рукопожатия WebSocket браузером (и если да, то какие файлы cookie), не указано в спецификации WS. Это оставлено на усмотрение поставщиков браузеров.

Соединение WS можно открыть для любого сайта, а не только для сайта, изначально обслуживающего JS, осуществляющего соединение. Однако браузеры ДОЛЖНЫ установить HTTP-заголовок «Origin» в открывающем рукопожатии WS на тот, который изначально обслуживал JS. Затем сервер может принять или отклонить соединение.

Вы могли бы, например, сгенерировать случайную строку в JS, сохранить эту клиентскую сторону и позволить этому плюс IP-адрес клиента принять участие в вычислении токена аутентификации для WS..

person oberstet    schedule 21.02.2012