Как безопасно перебросить домен, отправив форму со статического html сайта на серверную часть?

Question

Я хочу создать серию статических HTML-сайтов, которые будут размещаться на Amazon S3.

Статические сайты будут иметь формы.Мой план заключается в публикации / ajax отправки данных формы в серверное приложение, размещенное в другом домене.Приложение на стороне сервера сохранит данные в базе данных для последующего использования, а также отправит отправленные данные по электронной почте соответствующему лицу.

По номинальной стоимости это просто, HTML-форме просто нужно ПОСТАВИТЬ данные вскрипт на стороне сервера, похожий на google forms / wufoo / formspree и т. д.

Моя проблема связана с последствиями для безопасности.Пост будет междоменным со статического сайта, что затрудняет реализацию CSRF в популярных веб-фреймворках.Я прочитал много сообщений в блоге о CSRF / CORS / Authentication, но я не яснее.

Из изучения исходного кода formspree.io кажется, что они проверяют реферер и заголовки источника, чтобы убедиться, что отправка формы происходит с веб-сайта, которым она должна быть, и с веб-сайта, который зарегистрирован.Однако я понимаю, что они могут быть подделаны?

Поскольку любой код javascript на статическом сайте может быть прочитан и реверсирован, аутентификация в стиле API кажется трудной ...

Или я слишком обдумываю это, иесли я отправляю форму через SSL, проверяю сторону сервера данных формы, проверяю заголовки реферера / источника в соответствии с формой, она должна быть достаточно безопасной?

TLDR;Какие меры безопасности необходимо предпринять для размещения на сайте статического HTML-данных в серверной части сервера для хранения в БД и по электронной почте?

Заранее спасибо!

Answer 1

Оптимальное решение

Похоже, что оптимальное решение в вашем случае заключается в следующем:

1. Реализация рекапчи.
2. Сначала отправьте запрос в свой собственный скрипт, который проверяет капчу, а затем перенаправит запрос.
3. Добавление Access-Control-Allow-Origin только только ваших исходных текстов HTML. полезный вопрос

Защита CSRF

На самом деле, довольно сложно создать безопасное приложение, если у вас есть доступ только на стороне клиента.Если службы, которые вы публикуете, не имеют встроенной системы CSRF, было бы хорошим решением, если вы добавите рекапчу на свою HTML-страницу и создадите простой скрипт php, который получит поля формы, проверьте правильностьrecpatcha и отправьте поля формы в любое место назначения.

Защита CSRF с помощью токена также поможет, и на самом деле это решение для чистого кодирования, если вы в конечном итоге отправляете свой собственный сценарий, тем не менее, онобыло бы как-то сложно реализовать это в статических HTML-страницах.(Вам нужно будет сгенерировать его с помощью Javascript или php-сценария, сохранить его в своем сеансе, а затем проверить его в своем бэкэнд-сценарии), но я бы порекомендовал его, если вы сможете его кодировать.

• В обоих случаях вам необходимо сначала отправить свой собственный сценарий, а затем переслать запрос через CURL.

Проверка заголовков

В своем внутреннем сценарии вы можете проверитьреферер и источник, чтобы удостовериться, что запросы не поступают из другого источника, кроме ваших HTML-форм.

Сводка

1. Повторная проверка не позволит никому совершить CSRF-атаку противваши пользователи.
2. Если злоумышленник попытается найти обходной путь проверки источника и реферера, он может использовать что-то вроде CURL, recaptcha также помешает им сделать это.
3. ДоступРеализация -Control-Allow-Origin не позволит злоумышленникам отправлять данные на вашу страницу с помощью javascript.
4. Сначала отправьте свой собственный скриптКроме того, никто не узнает, куда именно вы отправляете эти данные, что затруднит выполнение атаки.

Хотя капча не очень удобное решение, еслиу вас есть возможность кодировать систему защиты CSRF, это необходимо сделать либо с помощью javascript, либо путем отправки ajax-запроса, который генерирует токен, уникальный для сеанса пользователя, после чего вы можете проверить этот токен на своей другой странице PHP, но вам нужно будетвнедрите капчу для предотвращения спама в любом случае.

Answer 2

На вашем сервере вам нужно некоторое промежуточное программное обеспечение, чтобы убедиться, что источником запроса является тот, которому доверяют.Поэтому, если ваш статический html-сайт www.mysite.com, убедитесь, что на сервере www.mysite.com разрешен доступ к вашему apis.Что касается аутентификации, то если вы не хотите, чтобы кто-либо обращался к вашему API, вам нужен какой-то тип аутентификации.Основной вид потока выглядит следующим образом:

Пользователь отправляет данные для входа в систему, сервер аутентифицируется, сервер генерирует токен и отправляет обратно клиенту в ответ, токен сохраняется на клиенте и устанавливается в заголовке при выполнении любых запросов.Затем на ваших маршрутах вам понадобится некоторое промежуточное программное обеспечение, чтобы проверить, присутствует ли токен в заголовке запроса, если да, разрешить доступ, если нет, запретить его.

Надеюсь, что это прояснит некоторые вещи.