Как обезопасить сервер при получении POST?

Question

[Игорь Безлепкин]

Привет! У меня два сервер. Один шлет другому через curl файлы на загрузку.
Стоит ли слать токен что бы принимающая сторна проверяла источник, или достаточно знать что POST идет с доверенного домена?

Comments

[alex-1917]

два сервера

[freeExec]

alex-1917, в свойствах вопроса есть возможность поправить вопрос самому.

[FanatPHP]

Под "доменом" имеется в виду ip адрес? Его можно подделать.

Answer 1

[Adamos]

Обычное дело - добавляете подпись: sha256(собранные в строку данные + известный обеим сторонам ключ). И проверяете ее, отбрасывая прочие запросы.
У меня, например, хостер (Таймвеб) своими роботами регулярно щупает мои скрипты, к которым происходят внешние обращения. От платежных систем, например. При том, что ссылок на них нигде нет. То ли ботов ищут, то ли еще что. Естественно, такие запросы обрабатывать - себе дороже.

Comments

[xmoonlight]

хостер (Таймвеб) своими роботами регулярно щупает мои скрипты, к которым происходят внешние обращения

Можно по хидерам фильтровать таких роботов средствами веб-сервера (правилами): есть нужный - пропускать, нет - блочить, чтобы даже до скрипта это не доходило.

[Adamos]

xmoonlight, В скриптах-колбэках от платежных систем я предпочитаю ничего автоматически не блочить.

[xmoonlight]

Adamos, но там наличие нужных входных данных, формата запроса и подпись проверяем же (также, там можно по домену ещё проверить).

[Adamos]

xmoonlight, разбираться, что пошло не так, лучше в одном месте, чем в двух.
Если бы у меня эти запросы валились, как в Эльдорадо - имела бы смысл оптимизация.
А пока их десяток в час - оно мне надо?

[xmoonlight]

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

[Adamos]

xmoonlight, я предпочитаю подробный лог. Обычно удается обойтись дедукцией, без дебага ;)

[xmoonlight]

Adamos, Согласен: и я тоже! Однако, бывают случаи, когда сбоит там, где не ждал (и там не делал запись в лог)...

Answer 2

[xmoonlight]

Почитайте как сделать правильно REST API (для POST и не только).

• HASH - подпись с применением функций хеширования и формул конкатенации данных запроса.
  
• RANDOM - случайная строка символов или число для создания уникального запроса
  
• TIMESTAMP - контроль давности запроса на стороне сервера.
  

Кратко: нужно три дополнительных параметра (кроме параметров запроса к API): HASH, RANDOM, TIMESTAMP.
HASH - формируем по TOKEN'у (его мы получаем заранее от сервера) на основе всех данных, передаваемых при запросе к API: API-параметры, RANDOM и TIMESTAMP.
Проверяем подпись при получении запроса и сравниваем с HASH: если подпись равна HASH - исполняем запрос.
 

UPD: про домен (доп.вариант проверки):
Входные данные, которым мы хотим доверять:
1. Доменное имя клиента API: домен_ожидаемый
2. TXT-запись домена клиента API: TXT_запись_ожидаемая

Имеющиеся данные (при получении запроса к API от клиента):
3. IP клиента API: IP(1)

При инициализации новой сессии (перед формировании нового токена), можно делать 3-4 DNS-запроса к любому публичному DNS-серверу (перед непосредственной генерацией токена!):
1. reverse_lookup (IP(1) клиента API в имя домена(1)) => узнали домен(1).
2. lookup (домен(1) в IP(2) по A-записи) => узнали IP(2)
3. снова reverse_lookup (IP(2) в имя домена(2)).
4. По желанию: можно проверить наличие нужных TXT-записей (и любых других) и сравнить с ожидаемыми (т.н., "статический публичный токен").

После получения всех данных, проверяем:
Домен_ожидаемый===домен(1) && IP(1)===IP(2) && домен(1)===домен(2) && TXT_запись_ожидаемая===TXT_запись_полученная

Если выражение истинно, то выписываем токен на обратившийся клиентский IP для предоставления доступа этому клиенту для начала работы с нашим API.

Comments

[Adamos]

RANDOM и TIMESTAMP - просто защита от повторения уже известного запроса, если оно что-то меняет.
В случае, если запросы заведомо уникальны или повторение действий по такому запросу контролируется принимающим скриптом - необязательно. Например, те же платежные системы стучатся на сайт магазина, пока не получат ответ. Но один заказ не может быть оплачен дважды, за этим следит уже сам магазин.

[xmoonlight]

Adamos, не только: это помогает от выявления алгоритма хеширования, если MiTM'у удалось перехватить много запросов одного юзера с одними и теми же параметрами к API и одним токеном. Т.е., до сервера - здесь пока сам запрос и не дошёл и, соответственно, он не может предотвратить ничего, т.к. попросту не участвует в цепочке.

[Adamos]

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

[xmoonlight]

Adamos, про телескоп - помнишь?)

[Adamos]

xmoonlight, нет. Волнуюсь!

[xmoonlight]

Adamos, ну там где-то я отвечал на тостере...
Сайты типа: "Ловим инопланетян телескопом! Подключай свой комп - помоги нам в обработке данных в то время, пока вас нет за компом и работает скрин-сэвер или когда CPU простаивает. Ставь софт - участвуй в проекте планетарного масштаба!" (А мы пока пакеты с хешами подготовим для поиска ключей))))

[Adamos]

xmoonlight, ну, это дело перпендикулярное.
От такого лучше защищаться не доп. полями, а регулярной сменой ключа.

[xmoonlight]

Adamos, неа. как раз лучше доп. полями (уникализировать "тело" запроса).
Т.к. ключ - меняется раз в X-запросов или раз в течение заданного промежутка времени (или, иногда встречается в половине случаев, по требованию клиента: init-session).

А каждое обращение к API - это ОДИН запрос и он уникальный!

Простое правило: перед обработкой запроса - целиком запрос к API (не хешированный) сохраняем в таблицу как отработанный на максимальное время жизни токена!
Ключевое поле - сам этот запрос: INSERT с ошибкой - никакого исполнения запроса!

И, конечно, плюс к этому, периодическая смена ключа - нужна обязательно!

[Adamos]

xmoonlight, ну, это все-таки зависит от того, стоит ли то, что исполняется по запросу, затрат времени хотя бы на защиту, не говоря уже про взлом ;)

[xmoonlight]

Adamos, Согласен!
Ну, можно по-старинке: 2 подряд некорректных запроса к хосту => IP в перманентный бан с алертом на почту. И тупо, и просто, и (не 100%, но максимально!) надёжно! :)

[Adamos]

xmoonlight, разве сейчас блочат по IP?
Народ с мобильных толпами сидит на одних и тех же айпишниках, плюс популярные прокси. Если с адреса откровенно привалило и это какой-нибудь Китай - тогда еще можно, конечно... А если не разбираясь - можно наломать дров, как РКН с Телеграмом.

[xmoonlight]

Adamos, ну если у кого доступ пропадёт пусть пишут в ТП. А вообще, да: нужен идентификатор устройства блочить. В данном случае так: UDID = IP+[доп.данные клиента].
Если клиент никак не представился - тогда вполне можно "ломать дрова"! ;)

Answer 3

[Андрей]

Я бы шифровал данные при пересылке. Приемник расшифровывает содержимое известным ему ключом и либо получает правильные данные и их обрабатывает, либо какую-то фигню и забивает на неё.

Comments

[Игорь Безлепкин]

Интересно....

[Дмитрий]

https же

[Андрей]

Дмитрий, ну, ещё одно шифрование лишним не будет и левые запросы отсечет, особенно если сессии использовать