Есть приложение: в котором юзер убивает адрес своего сайта в ответ получает js код.
Размещая этот код у себя на сайте он получает форму с которой можно слать почту на любой ящик .
Форма появляется у пользователя на сайте через iframe src сайт приложения.
И вот в чем вопрос как убедится что отправка идёт именно от клиента пользовательского сайта а не с какого либо скрипта на стороне Серве.
Проверка по рефереру мне кажется бональной.
Открытие сессии в фрейме невозможно слишком большая нагрузка.
Размышляя о решение вывел следующее.
1) надо убедиться что сабмит делает человек
2) убеждается что идёт отправка с фрейма который размещен на актуальном сайте.
Пока что склоняюсь к обфускации js кода в котором будет алгоритм создания токена для дружбы с бекендом
1. У валидации домена (hash) - срока жизни нет: без ограничений. Он перманентный прописывается в meta-теге в head-секции HTML страницы, которая расположена на домене, к которому Вы предоставили доступ, где будет загружаться Ваш виджет отправки писем.
2. Технологии - это проверка возможностей браузера, чтобы максимально исключить различные скрипты на бэке. Например, достаточно проверить, что браузер поддерживает геолокацию, Workers и WebRTC, к примеру, чтобы отсечь максимум "левых" вызовов через бэкенды.
3. Про размещать в родительском окне - так там и надо. Иначе-то - вообще никак не отследить и не проверить)
4. Про токен (который формируется сразу после отправки формы) - можете проверить, что он не просрочен более, чем на 10 секунд, так: время получения минус timestamp с клиента, защищённый hash-подписью на основе данных meta-тэга, UserAgent и IP-адреса пользователя.
А как это все спасет от запроса с сервера? Это все только hardening, на это нельзя полагаться. Дайте мне скрипт этого решения и я обойду его за секунду:
1) hash я получаю со страницы с публичной страницы с iframe.
2) На какой стороне формируется токен на основе ip, рефера и hash-ключа? И как он может формироваться в момент отправки формы если браузер ничего не знает про ip?
Если же токен формируется запрос на сторонний сервер, то я просто могу выставить кастомный referer, сделать запрос через tor или любой прокси и передать hash-ключ с первого шага.
xmoonlight, я просто еще не совсем понял какую задачу решаем. Что запрос отправляет реальный живой человек? Или что запрос приходит от того, от кого мы думаем, что он приходит?
Если первое, то капча - отличное предложение.
Если второе, то как бы ни хотелось, надежно убедиться, что запрос идет из JS с какого-то конкретного домена невозможно в принципе. Соответственно, единственный вариант: регистрировать приложения, где будет размещен виджет, выдавать ему секрет и делать отправку писем через этот самый сервер, т.е. не только на стороне клиента, но это усложнит установку виджета. Но тогда у автора вопроса будет уверенность, что запрос действительно пришел от того, от кого пришел. Но это, тем не менее, не будет гарантировать, что запрос на отправку письма пришел от реального человека, а не от машины.
Ivan Tomilov: два критерия:
1. запрос отправляет живой человек (капча - не панацея и тоже обходится также)
2. запрос приходит именно с нужного домена (тут - я пока кроме как делает гугл с гугл-мэпс при установке JS-карт с ключом - вариантов не знаю)
я понял, нужно глубже анализировать... ушёл думать дальше....
Oauth для юзера слишком будет сложно. Oauth юзаю для интеграции на наших сервисах, что бы максимально упростить работу юзеру. То есть есть сервис 1 и сервис 2 для них создано по приложению и с ними идёт безопастный обмен данных.
А вот та дырен через которую можно стать почту мне покоя не даёт.
Предложение генерить хеш и отдавать его на клиент тоже мне показалось решением но его также могут спарсить (phantomjs) но будет чуть сложнее бить эту дырку.
Ivan Tomilov @tiabc
Да это идёт с браузера реальным человеком в идеале как хотелось бы, надо исключить другим варианты.
Проджек менеджер врятли согласится на капчу.
Как без неё обойтись уже неделю думаю, как обезопасить.
Соглашусь с Андреем, по-другому задача не решается.
Любой запрос, который можно отправить с браузера, можно отправить и с сервера. Поэтому нужно четко понимать задачу: если требуется убедиться, что отправку производит человек, то капча - ваше решение.
Если требуется убедиться, что отправка идет именно с того приложения, которому вы сгенерировали токен, то нужно отдавать iframe по этому токену, но тогда любой другой сможет этот токен себе скопировать и использовать.
Сессия, которую вы упоминаете, тоже не поможет даже если ее хранить не на сервере, а на стороне клиента в виде jwt-токена или любым другим образом, который криптографически защищает содержимое токена. Потому что любой другой на стороне сервера просто запроси этот же айфрейм, получит токен и отправит его.
Задача, которую вы сейчас поставили, не решается, email по-любому нужно будет отправлять с сервера, где можно хранить ключи, а дальше авторизуйте приложение как хотите, хоть oauth2 используйте.
xmoonlight: Oauth2 сервер имеется для работы между сервера наших сервисов.
Но согласитесь юзеру придётся писать код для получения токена и код для отправки что бы токен не светить . Вся идея была изначально в том что бы упростить интеграцию , взял js код в личном кабинете и вставил его к себе на сайт
