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

Продукт, который я помогаю развивать, будет в основном работать следующим образом:

  • Веб-издатель создает новую страницу на своем сайте, которая включает <script> с нашего сервера.
  • Когда посетитель достигает этой новой страницы, <script> собирает текстовое содержимое страницы и отправляет ее на наш сервер через запрос POST (междоменный, используя <form> внутри <iframe>).
  • Наш сервер обрабатывает текстовое содержимое и возвращает ответ (через JSONP), который включает в себя фрагмент HTML, содержащий ссылки на связанный контент вокруг Web. Этот ответ кэшируется и подается последующим посетителям, пока мы не получим еще один запрос POST с текстовым контентом с того же URL-адреса, после чего мы восстановим "свежий" ответ. Эти POST-сообщения происходят только тогда, когда истекает время кэширования TTL, и в этот момент сервер это означает и запрашивает <script> на странице для сбора и POST текстового содержимого снова.

Проблема в том, что эта система по своей природе небезопасна. Теоретически любой может обмануть HTTP-запрос POST (включая заголовок реферера, чтобы мы не могли просто проверить это), который отправляет содержимое страницы на наш сервер. Это может включать любой текстовый контент, который мы затем будем использовать для создания связанных ссылок на контент для этой страницы.

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

В идеале нам нужен метод, который каким-то образом проверяет подлинность запроса POST, соответствующего определенной веб-странице. Мы не можем просто очистить веб-страницу и сравнить контент с тем, что было POSTED, поскольку цель отправки JavaScript-контента заключается в том, что он может быть за системой входа.

Любые идеи? Надеюсь, я достаточно хорошо объяснил проблему. Заранее благодарим за любые предложения.

ОТВЕТЫ

Ответ 1

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

Google и другие делают это эффективно с объявлениями. Создайте токен api и попросите их отправить это. Проведите процесс проверки на сайтах, использующих ваш script, который требует от регистратора этого script разрешить их сайт для профилирования до использования script. Затем вы можете собрать каждый бит информации о рассматриваемом сервере и если профиль сервера не соответствует тому, который находится на записи, может ли запрос.

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

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

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

Наконец, когда приходит плохой запрос, который вы профилировали как плохой запрос, отправьте JSONP из того, что было бы хорошим запросом для этой страницы на основе данных, которые, как вы знаете, хороши (24-часовая версия страницы и т.д.). Не говорите хакеру, что вы знаете, что они там. Действуйте так, как будто все в порядке. Это займет некоторое время, чтобы понять, что один из них!

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

Ответ 2

Как насчет этого? - тег <script/>, который содержит сторонние сайты, имеет динамический атрибут src. Таким образом, вместо загрузки некоторого статического ресурса Javascript он приходит на ваш сервер, генерирует уникальный ключ в качестве идентификатора для веб-сайта и отправляет его обратно в ответ JS. Вы сохраняете тот же ключ в сеансе пользователя или в своей базе данных. Форма, созданная и представленная этим JS-кодом, также представит этот ключевой параметр. Ваш бэкэнд отклонит любой запрос POST, у которого нет соответствующего ключа с тем, который находится в вашем db/session.

Ответ 3

Дайте людям ключи для каждого домена.

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

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

Ответ 4

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

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

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

Ответ 5

Прежде всего, я бы подтвердил домен (и, возможно, "профиль сервера" ), как это было предложено другими, и, очевидно, очень строго проверяет содержимое POST (как я надеюсь, вы уже все равно).

Если вы указали URL-адрес вашего файла script на то, что динамически генерируется вашим сервером, вы также можете включить чувствительный к времени сеансовый ключ, который будет отправлен вместе с POST. Это не будет полностью лишать кого-либо, но если вы сможете сделать сессию достаточно быстро, ее будет гораздо труднее использовать (и если я правильно понимаю ваше приложение, сессии должны быть достаточно долго для пользователя для ввода чего-либо после загрузки страницы).

После ввода этого текста я понимаю, что в основном avlesh уже предложил с добавлением истечения срока действия.

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

Как насчет:

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