Как я могу проверять/защищать/аутентифицировать основанный на JavaScript запрос POST?

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

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

Как насчет:

Сайт A создает одноразовый номер (в основном случайную строку), отправляет его на ваш сайт B, который помещает его в сеанс. Затем, когда сайт A отправляет запрос POST с сайта, он отправляет одноразовый номер вместе с запросом, и запрос принимается только в том случае, если одноразовый номер совпадает с тем, который указан в сеансе сайта B.

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

С поддельным IP-адресом невозможно правильное TCP-рукопожатие, поэтому подделанный пост злоумышленники не завершают.

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

Предоставляйте людям ключи для каждого домена.

Заставьте людей включать в запросы хеш значение [строка ключа + параметры запроса]. (Хеш-значение должно быть вычислено на сервере)

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

Основным недостатком системы, как вы описали, является то, что вам «дано» содержимое страницы, почему бы не пойти и не получить содержимое страницы для себя?

1. Веб-издатель создает новую страницу на своем сайте, которая включает скрипт с вашего сервера.
2. Когда посетитель достигает этой новой страницы, этот сценарий отправляет запрос на получение на ваш сервер.
3. Ваш сервер получает содержимое страницы (возможно, используя заголовок реферера для определения источника запроса).
4. Ваш сервер обрабатывает текстовое содержимое и возвращает ответ (через JSONP), который включает в себя фрагмент HTML, содержащий ссылки на связанный контент в Интернете. Этот ответ кэшируется и передается последующим посетителям из кэша / прокси-сервера на стороне сервера
5. . По истечении срока жизни кэшированной версии прокси-сервер пересылает запрос в ваше приложение, и весь цикл начинается снова с шага 3.

] Это предотвращает "передачу" вредоносного контента на ваш сервер и позволяет вам предоставить некоторую форму ключа API, который связывает запросы и домены или страницы вместе (например, ключ api 123 работает только для рефереров на mydomain.com - все остальное явно подделано ). Благодаря кешированию / прокси-серверу ваше приложение в некоторой степени защищено от любой формы атак типа DOS, так как содержимое страницы обрабатывается только один раз каждый раз, когда истекает TTL кеша (и теперь вы можете обрабатывать возрастающие нагрузки, увеличивая TTL до тех пор, пока вы может принести дополнительную возможность обработки).Теперь ваш клиентский скрипт безумно мал и прост - больше не нужно очищать контент и публиковать его - просто отправьте запрос ajax и, возможно, заполните пару параметров (ключ api / страница).

Вы может очистить сайт, и если вы получите ответ с кодом 200, включая ваш скрипт, просто используйте его. Если нет, вы можете решить информацию из своего «прокси-сервера», тогда проблема будет связана с сайтами, которые вы не можете очистить.

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

Может ли веб-издатель также разместить прокси-страницу на своем сервере?

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

Что такое система входа в систему? Как насчет использования единого входа и разделения скриптов?