Безопасный JavaScript работает на сторонних сайтах - PullRequest
2 голосов
/ 21 февраля 2012

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

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 21 февраля 2012

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

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

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

0 голосов
/ 21 февраля 2012

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

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

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

...