Защита веб-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 секретных проверок, которые они даже не знали бы, и даже если они знают, их может отпугнуть все дополнительное кодирование, которое они должны выполнить.