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

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

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

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

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

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

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

Ответы [ 10 ]

6 голосов
/ 28 октября 2011

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

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

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

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

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

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

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

4 голосов
/ 09 ноября 2011

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

1 голос
/ 17 ноября 2011

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

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

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

1 голос
/ 06 апреля 2010

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

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

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

1 голос
/ 02 апреля 2010

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

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

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

0 голосов
/ 06 апреля 2010

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

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

0 голосов
/ 05 апреля 2010

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

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

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

0 голосов
/ 04 апреля 2010

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

При использовании поддельного IP-адреса правильное TCP-рукопожатие не может быть выполнено, поэтому сообщение об атаке злоумышленников не завершено.

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

0 голосов
/ 02 апреля 2010

Как насчет:

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

0 голосов
/ 01 апреля 2010

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

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

...