Безопасность встроенного виджета iframe/javascript

Question

Я создаю сайт, функционально подобный Google Analytics. Я не занимаюсь аналитикой, но я пытаюсь предоставить либо одну строку javascript, либо одну строку iframe, которая добавит функциональность другим сайтам.

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

Всплывающее окно загрузит контент с моего сайта, но мой вопрос относится к встроенной строке javascript (или iframe). Каков наилучший способ сделать это? Google Analytics и оптимистично использовать javascript для изменения главной страницы. Очевидно, iFrame тоже будет работать.

У меня есть проблема с безопасностью: кто-то копирует код встраивания с одного сайта и помещает его в другое. Каждая комбинация страниц/сайтов, которая реализует мой скрипт/iframe, будет иметь уникальный идентификатор, который разработчики сайта будут генерировать из аутентифицированной учетной записи на моем сайте. Затем я предоставляю им соответствующий код для встраивания.

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

Я читал this post, что было очень полезно, но мой прецедент немного отличается, так как я на самом деле собираюсь создать контент для пользователей, с которыми можно взаимодействовать. Конкуренция заключается в том, что враг сайта, на котором размещается моя вставка, обманчиво соблазнит своих пользователей использовать виджет. Эти пользователи будут полагать, что они взаимодействуют с моим сайтом от имени вражеского сайта, но фактически взаимодействуют от имени дружественного сайта.

Answer 1

Если вы хотите сохранить его как простой виджет на стороне клиента, простой ответ заключается в том, что вы не можете делать это точно так, как вы описываете.

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

Referer Проверить

Вы можете проверить referer HTTP header, чтобы проверить, что домен соответствует ожидаемому для сайта конкретного ID, но имейте в виду, что не все браузеры будут посылать это (и большинство из них не будет, если ссылающаяся страница - HTTPS), и что некоторые плагины конфиденциальности для браузера могут быть настроены для их удержания, и в этом случае ваш виджет не будет работать, или вам понадобится дополнительный, неуклюжий шаг в работе пользователя.

1. Сайт www.foo.com встраивает виджет с использованием сказать, внедренный скрипт <script src="//example.com/widget.js?siteId=1234&pageId=456"></script>
2. Ваш виджет использует код на стороне сервера, чтобы генерировать .js файл динамически (например, запрос на .js файла может следовать правилу перезаписи на сервере для сопоставления с PHP/ASPX).
3. Код на стороне сервера проверяет HTTP-заголовок referer, чтобы узнать, соответствует ли оно ожидаемому значению в вашей базе данных.
4. В матче виджет работает как обычно.
5. на несоответствие, или если реферер пустой/отсутствует, виджет будет по-прежнему работать, но будет дополнительный шаг, который просит пользователя подтвердить, что они обращались виджет из www.foo.com
6. Для того, для подтверждения чтобы быть в безопасности от clickjacking, вы должны open the confirmation step in a popup window.

Сервер Проверить

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

1. Веб-сайт www.foo.com хочет внедрить ваш виджет для запроса текущей страницы, который он получает от пользователя.
2. Сервер www.foo.com делает запрос API (проходящий секретный ключ) к API размещенному, запрашивая ключ один раз для ID страницы 456.
3. Вашего API проверяет секретный ключ, генерирует безопасный один ключ времени и проходы вернуть значение во время записи запроса в базу данных.
4. www.foo.com встраивается скрипт следующим <script src="//example.com/widget.js?siteId=1234&oneTimeKey=231231232132197"></script>
5. Ваш виджет использует на стороне сервера код для создания файла JS динамически (например, в .js может следовать правилу перезаписи на сервере для отображения на PHP/ASPX).
6. Код на стороне сервера проверяет комбинацию oneTimeKey и siteId, чтобы проверить ее правильность, и если это так генерирует код виджета и удаляет запись базы данных.
7. Если пользователь перезагрузит страницу, вышеуказанные шаги будут повторяться, и будет создан новый один ключ времени. Это защитит от evil.com со страницы, соскабливающей код и параметры вставки.

Answer 2

Ответ здесь очень подробный и содержит много отличной информации и идей. Я решил эту проблему, утвердив заголовки X-Frame-Options на стороне сервера, хотя поддержка для них неполна в браузерах и, возможно, подделана.