Как предотвратить имитацию запросов?

Question

[qw1klyy]

Может ли человек, увидев js и post запросы с их url, сымитировать запрос на сервер для каких либо целей. Если да, то как это предотвратить?
К примеру, после успешной оплаты, на сервер отправляется post запрос с определенным заголовками, а человек просто имитирует такой же запрос без оплаты

Comments

[fenrir]

Если нет кода на Python не ставьте тег.

Может ли человек сымитировать запрос

Да может.

как это предотвратить?

С текущей постановкой вопроса - никак. Описывайте от каких видов атак вы собираетесь защищаться.

[qw1klyy]

fenrir, обновил

Answer 1

[Elaryks]

Да, сымитировать запрос можно. Поэтому есть правило: "Нельзя доверять данным, которые приходят с клиента". Следовательно, данные с клиента нужно проверять на сервере. Критические данные и операции нужно подписывать или хэшировать, чтобы избежать подмены. Например, для защиты от Replay Attack используют одноразовые токены — при повторном запросе токен уже не сработает.

Comments

[qw1klyy]

Есть ли какой то источник, чтобы почитать про эту тему поподробнее? Спасибо.

[Elaryks]

qw1klyy, вот пара ссылок, там вроде есть некоторая информация: первая ссылка и вторая.

В целом, суть такова: вы генерируете каким-либо образом для каждой важной операции токен, который срабатывает только один раз. Например, мы запрашиваем что-либо у сервера, тот отправляет нам данные и одноразовый токен. Далее мы совершаем какую-либо операцию, отправляя на сервер данные и тот самый токен. Если злоумышленник решит повторно отправить тот же запрос, он не сработает, поскольку токен будет уже не рабочий.

Ну и особо важные операции всё же лучше проводить сразу на сервере. Например, пользователь хочет купить что-либо в игре. Нужно не проверять на клиенте, достаточно ли средств для покупки и дальше отправлять на сервер обновлённое количество средств и данные о совершённой покупке, а нужно отправлять запрос о желании совершить покупку, а уже вся "внутренняя" логика совершается там — подальше от рук пользователя.

[Refguser]

qw1klyy, см nonce (только там неточность - вместо "пароль" читай "любые передаваемые данные") и соль.

[maksam07]

Наверное еще стоит упомянуть CSRF.

Answer 2

[mayton2019]

Здесь в вопросе - 2 разных вопроса. Мне кажется так:
1) Как защититься от любого мусора который прилетает с клиента. Скорее всего никак.
Нужно реагировать только на HTTP запросы которые имеют смысл в контексте пользовательской
сессии. Тут - как-бы бизнес логика и FSM для сессии должен все решать. Хакеры с помощью
wget, curl, python могут генерировать фаззингом миллионы самых вариативных запросов
в поиске вашего слабого места в этой части защиты.

2) Как защититься от атаки man-in-the-middle.. Это если легальный пользователь
зашел в свой клиент банк, а некто, кто физически сидит на канале может перехватывать
IP пакеты. Изменять их. Удалять. Задерживать на какое-то время или делать повторы.
Здесь коробочное решение это https (TLS/SSL) протокол по идее помогает.

Answer 3

[Олег]

не удачный пример с платежными системами.
Данные об оплате поступают от мерчанта.
В 99% процентов случаев Ваш сайт просто отправляет посетителя на сайт платежной системы так как пройти сертификацию для работы с данными карт (Payment Card Industry Data Security Standard (PCI DSS) ) большой гиморой.
Для переадресации требуется сумма платежа, идентификатор участника платежной системы в чью пользу оплата, обычно к обязательным полям добавляют возможность добавить идентификатор оплаты со стороны продавца.
Названия полей и их количество немного отличаются от платежной системе к системе.

Есть вторая схема. Предварительная регистрация платежа (бакенд дергает апи и получает ид оплаты). Редиректит пользователя на оплату конкретного счета.

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

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

Даже в этом случае (пользователь ничего не передает) верить не желательно.
Стоит перепроверить контрольную сумму. Ограничить доступ к хукам по ip.

Типовой способ защиты: расчет контрольной суммы от
секретнаястрока+поле_данных1+поледанных2+....+полеN

Но способ не подходит для JS так как строка будет видна :(