#api #rest #caching
#API #rest #кэширование
Вопрос:
Я добавляю кэширование на сервер API. Реализация системы кэширования используемой мной платформы просто хэширует весь URL-адрес запроса и использует его в качестве ключа кэша (а также некоторые другие данные, такие как язык и т. Д.).
Но с помощью этой простой системы я могу добавить поддельные параметры запроса к URL с произвольными значениями, и моя система также будет кэшировать эти запросы. Например:
GET https://example.com/apicall # Cached
GET https://example.com/apicall?fake=1 # Also cached
GET https://example.com/apicall?fake=2 # Also cached!
Это то, о чем я должен беспокоиться? Что люди могут очень легко заполнить мой кеш ненужными записями, которые не используются? Или я преувеличиваю потенциальное влияние этого?
Комментарии:
1. Это зависит от того, может ли базовая система обрабатывать нагрузку без кэша. Злоумышленник может отправить эти нежелательные URL-адреса и, при использовании LRU, отключить кэш для всех пользователей, отправив его в спам. Однако вы можете компенсировать это ограничением скорости IP-адресов и т. Д. чтобы избежать различных атак методом перебора. В целом, вероятно, это нормально для приложения с низким целевым назначением, но вы сделали хорошее замечание и могли бы добавить некоторые меры предосторожности.
2. Хорошо, итак, я пытался придумать способы защиты этого, и хорошо, ограничение скорости IP-адресов — это единственное, что кажется возможным. Проверка параметров запроса кажется невозможной, когда они становятся немного более сложными. Что-нибудь еще, что вы могли бы предложить? Было бы здорово, если бы вы могли опубликовать простой ответ со способами защиты от этого.
3. Я полагаю, вы создаете кэширующий обратный прокси-сервер? Вы можете спросить эти сообщества, как они решают эту проблему (nginx, haproxy и т. Д.). Их уровень техники может привести к хорошему решению. В противном случае я бы вложил средства в лучшую политику выселения, например, W-TinyLFU может эффективно отфильтровывать одноразовые чудеса. Другая проблема заключается в том, чтобы убедиться, что хэш-код ключа включает полный URL-адрес, например, недавно я обнаружил атаку hashDoS из-за неправильного использования кэша маршрутов.