Firebase cloud function: как бороться с непрерывным запросом

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

Итак, мне интересно, как мы можем справиться с тем, что кто-то, кто каким-то образом узнает нашу конечную точку, а затем непрерывный запрос намеренно (сценарием или инструментом)?

Я сделал поиск в Интернете, но не вижу ничего, что могло бы помочь. За исключением этого, но не очень полезного.

Ответы

Ответ 1

Поскольку вы не указали, какой тип запроса, я собираюсь предположить, что вы имеете в виду http (s) -triggers для облачных функций firebase.

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

1) Ограничить тип запросов

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

if (req.method === 'PUT') { res.status(403).send('Forbidden!'); }

2) Аутентификация, если вы можете

Следуйте примеру Google и разрешите только авторизованным пользователям использовать конечные точки https. Вы можете просто добиться этого, проверив токены, подобные этому SOF-ответу на этот вопрос.

3) Проверить происхождение

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

Экспериментальная идея 1

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

Экспериментальная идея 2

Вы можете попытаться использовать решения для предотвращения атак на уровне DNS для своей проблемы, добавив что-то вроде cloudflare между ними. Используйте CNAME и правила страницы Cloudflare для сопоставления URL-адресов вашим облачным функциям. Это может гипотетически поглотить воздействие. Как это:

*function1.mydomain.com/* → https://us-central1-etc-etc-etc.cloudfunctions.net/function1/$2

Теперь, если вы идете в

http://function1.mydomain.com/?something=awesome

вы даже можете передать параметры URL своим функциям. Тактика, о которой я читал в этой средней статье в течение лета, когда мне было нужно что-то подобное.

в заключение

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

Ответ 2

Возврат 403 или пустого тела в неподдерживаемых методах мало что даст для вас. Да, пропускная способность будет уменьшена, но Firebase все равно выставит вам счет за запрос, злоумышленник может просто отправить миллионы запросов, и вы все равно потеряете деньги.

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

Кроме того, умный злоумышленник не просто запросит запрос, который возвращает 403. Что мешает злоумышленнику попасть в конечную точку входа в систему миллионы раз? И если он предоставит правильные учетные данные (что он и сделал бы, если бы он был умен), вы будете тратить пропускную способность, возвращая токен каждый раз, также, если вы повторно генерируете токены, вы тратите время на каждый запрос, что еще больше повредит вашему счету.

Идея здесь состоит в том, чтобы полностью заблокировать этого атакующего (прежде чем перейти к вашим функциям API). То, что я хотел бы сделать, это использовать cloudflare для прокси моих конечных точек, и в моем API я бы определил max_req_limit_per_ip и time_frame, сохранив каждый ip запроса на БД и на каждой req проверке, если ip превышал лимит для данного периода времени, если это так, вы просто используете cloudflare api, чтобы заблокировать этот ip на брандмауэре.

Совет: max_req_limit_per_ip и time_frame могут быть пользовательскими для разных запросов.

Например:

  1. ip может попасть в 403 10 раз за 1 час
  2. ip может успешно войти в систему 5 раз за 20 минут
  3. ip может ударить логин 5 раз за 1 час

Ответ 3

Существует решение этой проблемы, где вы можете проверить конечную точку https.

Только пользователи, которые передают действительный токен Firebase ID в качестве маркера Bearer в заголовке авторизации HTTP-запроса или в cookie __session, имеют право использовать эту функцию.

Проверка токена ID выполняется с помощью промежуточного программного обеспечения ExpressJ, которое также передает токен декодированного идентификатора в объекте запроса Express.

Проверьте этот образец кода от firebase.