Защита веб-API от несанкционированных приложений

Я работаю над веб-страницей, которая использует большое количество AJAX для связи с сервером. Сервер, в свою очередь, имеет обширный REST/JSON API, подвергая различные операции, вызываемые веб-клиентом.

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

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

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

Совместное использование секретного ключа между клиентом и сервером, с другой стороны, будет бесполезным. Это из-за способности любого аутсайдера читать его из исходного кода веб-страницы.

Я хотел бы сделать эти веб-сервисы такими же сложными, как и для любого стороннего приложения. Что бы вы сделали, используя токен CSRF? Это звучит немного глупо, но эй, может быть, это глупо, и я просто теряю время.

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

ОТВЕТЫ

Ответ 1

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

Подводя итог:

  • Секретный ключ фактически не отправляется между клиентом и сервером. Скорее, он использовал для подписи запросов
  • Убедитесь, что в запросах содержится некоторый уникальный/случайный элемент (вероятно, достаточно вашего ключа CSRF), так что два запроса на одни и те же данные API не идентичны.
  • Подпишите запрос с помощью секретного ключа и добавьте подпись к запросу. Вы связаны с вопросом PHP, но неясно, какой язык вы используете. В .Net я бы использовал класс HMAC, например HMACSHA256.
  • На стороне сервера API используйте тот же объект HMAC, чтобы убедиться, что запрос был подписан с тем же секретным ключом.

Ответ 2

Возможно, вы можете использовать счетчики для отслеживания разговоров. Только сервер и клиенты смогут предсказать следующую итерацию в разговоре. Таким образом, я думаю, вы можете запретить сторонним приложениям выдавать себя за кого-то (только идея).

В начале они начинают говорить на некоторой итерации (например, i=0).

  • Каждый раз, когда клиент что-то запрашивает, счетчик увеличивается на некоторое количество как на стороне сервера, так и на клиенте (i=i+some_number).

  • И, после нескольких минут отсутствия связи, они оба знают, что они должны reset счетчика (i=0).

Ответ 3

Это всего лишь идея, основанная на концепции RSA, а также размещение Fraud Detection в вашей системе. Риск от авторизированных пользователей минимален, однако они могут попытаться сделать анонимные звонки на ваш веб-сервис тоже.

Для пользователей, авторизованных ООН: для каждого вызова веб-службы генерируйте токен, используя RSA, который изменяется через некоторое время (можно настроить через 30 минут). Таким образом, предсказание кода минимизируется. До сих пор я не слышал о столкновении RSA. Отправьте этот токен обратно пользователю для сеанса браузера. Для дополнительной безопасности мы можем захотеть подключить идентификатор сеанса с токеном RSA. Поскольку идентификаторы сеанса уникальны, для новых анонимных вызовов потребуется новый идентификатор сеанса.

Вызовы можно отслеживать с использованием механизма аудита. Кроме того, для каждого веб-сервиса может быть установлена ​​другая настройка RSA. Как Алгоритм обнаружения мошенничества будет работать сам по себе.

Для авторизованных пользователей: Каждый пользователь должен отслеживать свой IP-адрес, используя блок заголовка. Принцип токена RSA может применяться.

Решение очень расплывчато, но стоит подумать.

Ответ 4

Я бы сделал несколько шагов.

  • Настроить https на сайте. Автоматически перенаправлять любые входящие HTTP-запросы на https (для этого удобно атрибут RequireHttps)
  • Каждая страница должна (безопасно, следовательно, https) отправлять клиенту единовременный токен использования, который будет использоваться для этой страницы. Операция script, запущенная на клиенте, может содержать это в памяти страницы. Любой возвращаемый запрос отправляет хешированный и соленый ответ, а также nonce соль. Сервер может повторить шаги с сохраненным маркером + соль и хэш для подтверждения запроса. (очень похоже на ответ выше) (Стоит отметить, что защищенный запрос от клиента не аутентифицируется из учетной записи пользователя, а всего лишь токена, отправленного с полной страницы.)
  • Определение для одноразового использования может быть либо загрузкой сеанса, либо страницей, в зависимости от предпочтения вашей безопасности и удобства. Токены должны быть длинными и истекли довольно быстро, чтобы помешать атакующим.

Для ваших нужд должно быть достаточно SSL + Hash (токен + nonce).

Ответ 5

Это интересно. Ниже приводится сумасшедшее предложение. Помните, что ваш вопрос также одинаково сумасшедший.

Ваш веб-сайт, открывшийся через браузер, должен генерировать длинное голосовое соединение (комета). Это создаст уникальный сеанс между браузером и сервером. Когда ur JS делает вызов ajax, каждый раз посылайте на сервер один токен (уникальный токен), через длинный поток опроса. Пусть AJAX также отправит один и тот же токен. На сервере получите токен AJAX и проверьте, есть ли у вас аналогичный токен в длинном сеансе опроса. Если да, выполните запрос. Любой кодер может сломать это. Но это будет нелегко. Скорее всего, фри-бордеры даже не видят эту вторую часть кода кометы. Вы можете реализовать кометный код таким образом, что его нелегко обнаружить или понять. Когда они звонят в службу ur, отправьте сообщение "Service Unavailable". Они будут смущены. Также сделайте код кометы https.

Вы также можете проверить, как долго длительный поток опроса открыт. Если сеанс был только что открыт, и вы сразу же получаете вызов ajax, вы можете предположить, что это сторонний вызов. Это зависит от потока веб-сайта ur. Если вызов ur Ajax происходит после 1 секунды загрузки страницы, вы можете проверить этот шаблон на стороне сервера.

Любое кодирование для вашего публичного api будет иметь от 1 до 2 секретных проверок, которые они даже не знали бы, и даже если они знают, их может отпугнуть все дополнительное кодирование, которое они должны выполнить.