Как достоверно идентифицировать сайт, с которого идёт обращение в iframe и предотвратить компрометирование данных?

@VikaShat · Регистрация: 30.12.2021

Студворк — интернет-сервис помощи студентам

Здравствуйте. Я бекенд-разработчица. Нам с фронтом поставили задачу сделать виджет, встраиваемый через iframe. Обязательным условием является безопасность наших клиентов, решивших купить виджет (чтобы их лицензией не сумели воспользоваться другие). Виджет - типичное веб-приложение. Фронт - React, бек - .net web api. Сама пришла к тому, что проверка по домену, с которого сделано обращение - недостаточно действенный способ, так как любой может создать локальный домен с тем же адресом, как и у клиента, и без проблем интегрировать себе виджет. Развернуть, настроить ингресс, и обеспечить всю свою компанию виджетом. Сценарий отчасти надуманный, но это возможно.

А теперь вопрос: как можно обеспечить на стороне фронтенда безопасную передачу данных, идентифицирующих сторону, с которой идёт вызов? Обязательным условием является то, что данные должны быть некомпрометируемыми. Сама надумала такой сценарий (вполне возможно, примитивный, не бейте. Но похожий подход реализует один эквайринг, который мне приходилось внедрять), но без совета развить его не смогу. Клиент передаёт в виджет выданный ему идентификатор и пароль, обеспечивающий доступ. Эти данные также хранятся на нашей стороне в БД, разумеется. По переданным данным я идентифицирую клиента, проверю наличие лицензии, отработаю основную логику, зашифрую респонс токеном (для каждой пары клиент-пароль свой токен) и отдам в виджет, там идёт дешифрование (у клиента также имеется токен). +обфускация js для создания дополнительных трудностей для "интересующихся".

@Eva Rosalene · 16.09.2022, 17:36

VikaShat, скоммуниздить смогут всегда, как ни пытайтесь. Denuvo тому пример.

google например "лицензию" на карты проверяют просто по адресу, куда интегрирован фрейм.

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

Можно проверять лицензию, требуя аутентификации не домена, а конечных юзеров - при этом условии
- можно отследить, в теории, от кого была утечка и жестоко засудить
- данные пользователя (e.g. cookies) сами по себе являются секретом, который со стороннего сайта не украсть, подсмотрев в код

Новые блоги и статьи Все статьи Все блоги /
Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .

@VikaShat 0 / 0 / 0 Регистрация: 30.12.2021 Сообщений: 8

	Как достоверно идентифицировать сайт, с которого идёт обращение в iframe и предотвратить компрометирование данных? 16.09.2022, 07:14. Показов 414. Ответов 1 Метки нет (Все метки) Здравствуйте. Я бекенд-разработчица. Нам с фронтом поставили задачу сделать виджет, встраиваемый через iframe. Обязательным условием является безопасность наших клиентов, решивших купить виджет (чтобы их лицензией не сумели воспользоваться другие). Виджет - типичное веб-приложение. Фронт - React, бек - .net web api. Сама пришла к тому, что проверка по домену, с которого сделано обращение - недостаточно действенный способ, так как любой может создать локальный домен с тем же адресом, как и у клиента, и без проблем интегрировать себе виджет. Развернуть, настроить ингресс, и обеспечить всю свою компанию виджетом. Сценарий отчасти надуманный, но это возможно. А теперь вопрос: как можно обеспечить на стороне фронтенда безопасную передачу данных, идентифицирующих сторону, с которой идёт вызов? Обязательным условием является то, что данные должны быть некомпрометируемыми. Сама надумала такой сценарий (вполне возможно, примитивный, не бейте. Но похожий подход реализует один эквайринг, который мне приходилось внедрять), но без совета развить его не смогу. Клиент передаёт в виджет выданный ему идентификатор и пароль, обеспечивающий доступ. Эти данные также хранятся на нашей стороне в БД, разумеется. По переданным данным я идентифицирую клиента, проверю наличие лицензии, отработаю основную логику, зашифрую респонс токеном (для каждой пары клиент-пароль свой токен) и отдам в виджет, там идёт дешифрование (у клиента также имеется токен). +обфускация js для создания дополнительных трудностей для "интересующихся". 0

@Eva Rosalene Модератор 5241 / 2115 / 416 Регистрация: 06.01.2013 Сообщений: 4,846
	16.09.2022, 17:36
	VikaShat, скоммуниздить смогут всегда, как ни пытайтесь. Denuvo тому пример. google например "лицензию" на карты проверяют просто по адресу, куда интегрирован фрейм. Например, раз уж они знают, на каких доменах этот виджет разрешён и теоретически имеют к ним доступ, то смогут выкрасть пароль прямо оттуда. Можно проверять лицензию, требуя аутентификации не домена, а конечных юзеров - при этом условии - можно отследить, в теории, от кого была утечка и жестоко засудить - данные пользователя (e.g. cookies) сами по себе являются секретом, который со стороннего сайта не украсть, подсмотрев в код 0